Re: Windows MAGICK_CONFIGURE_PATH options

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-1289814090-1583716863=:19783
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Sun, 8 Mar 2020, 10bxjfhf wrote:

> On 2020-03-08 8:57 a.m., Bob Friesenhahn wrote:
>> 
>> Some or all of your log.c concerns should be addressed by Mercurial 
>> changeset 16263:c0424b73d57e.  This will of course cause a merge conflict 
>> with whatever local changes you have made.
>
> Thank you, Bob.
>
> As I have no experience at all with Mercurial - and am just getting sort of 
> started with Git - I had to install TortoiseHG just now. My first try did not 
> get me what I expected, so I simply downloaded the current snapshot.
>
> Looking through log.c, I see the latest changes. It seems the the output to 
> the callback will be in addition to, not in place of the old text file 
> output?

That appears to be the original intention.  I imagine that setting 
'output="none"' in the log.mgk would disable duplicate information. 
It appears that the logging events setting will still filter reporting 
so if no events are requested, then this callback will not be called 
either.

Note that it appears that SetLogEventMask(), SetLogFormat(), and 
SetLogMethod() can't be called until after InitializeMagick() has 
returned because the logging setting are in a structure which is 
allocated by InitializeMagick() rather than being statically 
allocated.  More important than that is that the log.mgk file will not 
be searched for and parsed until InitializeMagick() is called.

It seems reasonable to add more log settings functions.

> Because I had been eying SetLogFormat(), I also noticed that not all log 
> methods seem to be using the format passed in by this function (and stored in 
> log_info->format) and in particular the format used by the method to handle 
> the special log call back is hard-wired. Any particular reason?

I am not aware of a reason other than that Bill Radcliff designed this 
part of the code and while I have made significant changes to the 
implementation over the years, it was not with the intent to change 
behavior.

The current implementation will support almost arbitrary long output 
sizes when it is using the format set by log.mgk because it is using 
file I/O rather than writing into a fixed size buffer.

> These changes go a long ways to give me the feedback I would like.
>
> While there are some initialization events which only show up in the text 
> file, now that I know where to look for some of these things, it is much more 
> workable.

The chicken and egg problem is still not solved.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt
---559023410-1289814090-1583716863=:19783
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


---559023410-1289814090-1583716863=:19783
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

---559023410-1289814090-1583716863=:19783--