Re: Finally have cleared the leaks ...
10bxjfhf <[email protected]> Tue, 24 Mar 2020 12:31:38 -0700
| Newsgroups | gmane.comp.video.graphicsmagick.apis |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============1340499271388673181==
Content-Type: multipart/alternative;
boundary="------------6A47BAF681707B8989087421"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------6A47BAF681707B8989087421
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 2020-03-23 12:32 p.m., Bob Friesenhahn wrote:
> On Sun, 22 Mar 2020, 10bxjfhf wrote:
>>>
>>> I have not yet re-implemented the logging formatting code such that
>>> the format set by the user is used for all cases. Currently the
>>> user-specified
>
> I have now implemented consistent logging formatting code which obeys
> the user.
Good. Thank you.
>> I am wondering about the different usages of std::string and
>> std::wstring. For wxWidgets, everything is/needs to be converted to
>> wide strings and when calling the underlying Win API functions, I
>> typically need to ensure to pass wide strings. Is this handled by GM
>> * Magick++
>
> Magick++ and GraphicsMagick (being very old software started in
> perhaps 1990) do not support wide strings. The only way things work
> is if 7 or 8 bit string data is expressed in the same code-page as the
> filesystem, or if Unicode is represented in UTF-8, which then needs to
> be supported as such by the filesystem. There is an existing problem
> report that GraphicsMagick on Windows is not able to open some UTF-8
> filenames containing Chinese characters. Different operating systems
> have different capabilities and behavior when it comes to file names.
>
> Even wide-character support does not assure correct support for
> internationalization because there is no assurance that there is not a
> mis-match. ANSI C introduced wide characters in 1989 before standards
> had evolved for how internationalization should be done.
>
This wide char support is still full of unexplored corners for myself,
so I will have to put all that into my pipe & smoke it ;-)
>> For Windows app with GM code linked as DLLs, all of the
>> initialization is done when the OS first decides it needs the
>> CORE_xx_magick_.dll
>
> Remember, this is configurable. Given the problems that it is
> apparently causing, ProvideDllMain is no longer the default.
Good; now I don't have to manually edit the configuration before
generating the .sln file
>
> In the mean time, this sequence should work:
>
> InitializeMagick(NULL);
> DestroyMagick();
> [ Do some defaults configuration ]
This would only include the environment variables to be used by this
instance.
> If you put the .mgk files in the same directory as the DLL, they
> should be found. For a static build, it would be best to put the .mgk
> files in the same directory as the program. Unix-type systems work
> much differently.
For now, I have moved all of the *.mgk file to my configuration
directory and am pointingMAGICK_CONFIGURE_PATH to that path.
For InitializeMagick( static_cast<const char*>( wsExePath) ); I point it
to the current executable; for now I have only worked with the debug
DLLs; eventually I probably will try other configurations
>
>> I am considering linking the libs statically, though I am unsure
>> whether it will help. I would expect the OS to still get its turn
>> before me and the only way I see is to force a reload of the
>> libraries or the DLLs at a point of my choosing.
>
> In this case there would be no DLL initialization so the OS would not
> get its turn. You would be totally in control, but your program would
> appear much larger.
And I expect I would have to do much the same work to set things up :-)
>
>> FWIW, from here it looks as though the call to InitializeMagick from
>> within the app needs to override all data for the specific function
>> the call is expected to affect. At present, this does not happen for
>> at least SetLogDefaultFileName()
>
> See my text above.
Most of my time was spent on trying to understand what goes on behind
the scenes, because it does not work, at least not the way I understand it.
Fortunately I did remember a few lessons learned last time - and
eventually I got some insight from pushing the log info to the IDE log
output window.
Once I located the place where the logging is done, tracing through the
code showed some interesting things.
When the app starts up, between
InitializeMagick(NULL);
MagickLib::DestroyMagick();
the first 8 or 9 log events are directed at stderr and the next 10 or so
are directed at Win32EventLog
After this I set MAGICK_CONFIGURE_PATH => my confi directory with all of
the *.mgk files
with log.mgk =>
<magicklog>
<log events="blob" />
<log events="coder" />
<log events="configure" />
<log events="exception" />
<log events="Warning" />
<log events="Error" />
<log events="FatalError" />
<log output="txtfile" />
<!-- <log output="win32debug" /> -->
<log filename="NMagick-%d.log" />
<log generations="3" />
<log limit="2000" />
<log format="%t %r %u %p %m/%f/%l/%d/%s:\n %e" />
</magicklog>
and MAGICK_HOME => to the executable directory with all of the DLLs etc,
then I call again:
InitializeMagick( static_cast<const char*>( wsExePath) );
and I again trace the log events.
8 go to stderr and the next 10 or so go to the text log file.
Since I did not specify a path they end up in the parent of my debug
directory - by now I know where to look :-)
After this I try to set the new log file & path, but it does nothing and
won't do anything until a new log file needs to be created because just
assigning a new name & path does not close the current file.
Trying to set the log file path & name before the second call to
InitializeMagick() does not cause any errors but also does nothing
because the default is reset when Initialize.. gets called the second time.
Again, any issues encountered before this file can be set are lost and
unreported, hence very hard to track down - such as issues with the
log.mgk, which seems to be the only file accessed at this stage.
Also, at this time I have not yet taken the time to see what the
messages directed to stderr refer to, because I wanted to get out this
feedback ASAP. Eventually I will try to do so.
>
> Please pull the latest changes and see if you are more satisfied.
Still not familiar enough with Hg to be able to just update via a 'pull'
- being a non-command-line guy I am using TortoiseHg but it look quite
different from TortoiseGit :-(
Another leaning curve ;-)
Arnold
--------------6A47BAF681707B8989087421
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2020-03-23 12:32 p.m., Bob
Friesenhahn wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">On
Sun, 22 Mar 2020, 10bxjfhf wrote:
<br>
<blockquote type="cite">
<blockquote type="cite">
<br>
I have not yet re-implemented the logging formatting code such
that the format set by the user is used for all cases.
Currently the user-specified
<br>
</blockquote>
</blockquote>
<br>
I have now implemented consistent logging formatting code which
obeys the user.
<br>
</blockquote>
<p>Good. Thank you.<br>
</p>
<blockquote type="cite"
cite="mid:[email protected]">
<blockquote type="cite">I am wondering about the different usages
of std::string and std::wstring. For wxWidgets, everything
is/needs to be converted to wide strings and when calling the
underlying Win API functions, I typically need to ensure to pass
wide strings. Is this handled by GM * Magick++
<br>
</blockquote>
<br>
Magick++ and GraphicsMagick (being very old software started in
perhaps 1990) do not support wide strings. The only way things
work is if 7 or 8 bit string data is expressed in the same
code-page as the filesystem, or if Unicode is represented in
UTF-8, which then needs to be supported as such by the
filesystem. There is an existing problem report that
GraphicsMagick on Windows is not able to open some UTF-8 filenames
containing Chinese characters. Different operating systems have
different capabilities and behavior when it comes to file names.
<br>
<br>
Even wide-character support does not assure correct support for
internationalization because there is no assurance that there is
not a mis-match. ANSI C introduced wide characters in 1989 before
standards had evolved for how internationalization should be done.
<br>
<br>
</blockquote>
This wide char support is still full of unexplored corners for
myself, so I will have to put all that into my pipe & smoke it
;-)<br>
<blockquote type="cite"
cite="mid:[email protected]">
<blockquote type="cite">For Windows app with GM code linked as
DLLs, all of the initialization is done when the OS first
decides it needs the CORE_xx_magick_.dll
<br>
</blockquote>
<br>
Remember, this is configurable. Given the problems that it is
apparently causing, ProvideDllMain is no longer the default.
<br>
</blockquote>
Good; now I don't have to manually edit the configuration before
generating the .sln file<br>
<blockquote type="cite"
cite="mid:[email protected]">
<br>
In the mean time, this sequence should work:
<br>
<br>
InitializeMagick(NULL);
<br>
DestroyMagick();
<br>
[ Do some defaults configuration ]
<br>
</blockquote>
This would only include the environment variables to be used by
this instance.<br>
<blockquote type="cite"
cite="mid:[email protected]">If
you put the .mgk files in the same directory as the DLL, they
should be found. For a static build, it would be best to put the
.mgk files in the same directory as the program. Unix-type
systems work much differently.
<br>
</blockquote>
<p>For now, I have moved all of the *.mgk file to my configuration
directory and am pointingMAGICK_CONFIGURE_PATH to that path.</p>
<p>For InitializeMagick( static_cast<const char*>( wsExePath)
); I point it to the current executable; for now I have only
worked with the debug DLLs; eventually I probably will try other
configurations</p>
<blockquote type="cite"
cite="mid:[email protected]">
<br>
<blockquote type="cite">I am considering linking the libs
statically, though I am unsure whether it will help. I would
expect the OS to still get its turn before me and the only way I
see is to force a reload of the libraries or the DLLs at a point
of my choosing.
<br>
</blockquote>
<br>
In this case there would be no DLL initialization so the OS would
not get its turn. You would be totally in control, but your
program would appear much larger.
<br>
</blockquote>
And I expect I would have to do much the same work to set things up
:-)<br>
<blockquote type="cite"
cite="mid:[email protected]">
<br>
<blockquote type="cite">FWIW, from here it looks as though the
call to InitializeMagick from within the app needs to override
all data for the specific function the call is expected to
affect. At present, this does not happen for at least
SetLogDefaultFileName()
<br>
</blockquote>
<br>
See my text above.
<br>
</blockquote>
<p>Most of my time was spent on trying to understand what goes on
behind the scenes, because it does not work, at least not the way
I understand it.</p>
<p>Fortunately I did remember a few lessons learned last time - and
eventually I got some insight from pushing the log info to the IDE
log output window.</p>
<p>Once I located the place where the logging is done, tracing
through the code showed some interesting things.</p>
<p>When the app starts up, between <br>
</p>
<p>InitializeMagick(NULL);<br>
MagickLib::DestroyMagick(); <br>
</p>
<p>the first 8 or 9 log events are directed at stderr and the next
10 or so are directed at Win32EventLog</p>
<p>After this I set MAGICK_CONFIGURE_PATH => my confi directory
with all of the *.mgk files</p>
<p>with log.mgk =></p>
<pre><magicklog>
<log events="blob" />
<log events="coder" />
<log events="configure" />
<log events="exception" />
<log events="Warning" />
<log events="Error" />
<log events="FatalError" />
<log output="txtfile" />
<!-- <log output="win32debug" /> -->
<log filename="NMagick-%d.log" />
<log generations="3" />
<log limit="2000" />
<log format="%t %r %u %p %m/%f/%l/%d/%s:\n %e" />
</magicklog>
</pre>
<p>and MAGICK_HOME => to the executable directory with all of the
DLLs etc, then I call again:<br>
</p>
<p>InitializeMagick( static_cast<const char*>( wsExePath) );</p>
<p>and I again trace the log events.</p>
<p>8 go to stderr and the next 10 or so go to the text log file.</p>
<p>Since I did not specify a path they end up in the parent of my
debug directory - by now I know where to look :-)</p>
<p>After this I try to set the new log file & path, but it does
nothing and won't do anything until a new log file needs to be
created because just assigning a new name & path does not
close the current file.</p>
<p>Trying to set the log file path & name before the second call
to InitializeMagick() does not cause any errors but also does
nothing because the default is reset when Initialize.. gets called
the second time.</p>
<p>Again, any issues encountered before this file can be set are
lost and unreported, hence very hard to track down - such as
issues with the log.mgk, which seems to be the only file accessed
at this stage.</p>
<p>Also, at this time I have not yet taken the time to see what the
messages directed to stderr refer to, because I wanted to get out
this feedback ASAP. Eventually I will try to do so.</p>
<blockquote type="cite"
cite="mid:[email protected]">
<br>
Please pull the latest changes and see if you are more satisfied.
<br>
</blockquote>
<p>Still not familiar enough with Hg to be able to just update via a
'pull' - being a non-command-line guy I am using TortoiseHg but it
look quite different from TortoiseGit :-(</p>
<p>Another leaning curve ;-)</p>
<p>Arnold<br>
</p>
<blockquote type="cite"
cite="mid:[email protected]">
</blockquote>
</body>
</html>
--------------6A47BAF681707B8989087421--
--===============1340499271388673181==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============1340499271388673181==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Graphicsmagick-apis mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-apis
--===============1340499271388673181==--