Re: Finally have cleared the leaks ...

On Wed, 25 Mar 2020, 10bxjfhf wrote:
>> 
>> There is not currently a way to request that a log.mgk not be loaded and to 
>> use only the default values.
>
> As I understand things now, it seems you are saying the if I set up a call 
> back, I can send the info to any log target I chose to implement the code 
> for.

Yes.

> That then seems to imply that I should not need anything but to set the call 
> back; any other log.mgk would be ignored and I really would not need the 
> dummy calls to Initialize & DestroyMagick at all?

As I recall, the problem you were solving was that the DLL was calling 
InitializeMagick() and you desire to obtain configuration tracing 
using your own rules.

It is starting to seem like we need yet another function which says to 
use the logging defaults as is or to skip searching for log.mgk.

Of course you could just delete log.mgk, or deliver an empty log.mgk, 
or remove settings from log.mkg that you don't like.  The settings 
from log.mgk would be merged with the existing defaults (including 
those you set via the API) when logging is fully initialized.

> If I could/can also set up the log events and format, I suppose that would 
> work.
>
> Still, if that is needed to setup the static log data struct, a lot of work 
> is done just for that.

I don't understand "a lot of work".  If you implement a logging 
callback then there is more work for you since then you need to do 
something with the data.  In any case, make sure that your logging 
callback does not block (for long) since it would also block further 
operations by the thread which produced the log, and would block other 
threads which might want to produce a log.

> My Hg workflow still needs refining.
>
> I clone the GM repos and then work in it; that seems to make it impossible to 
> later update or pull from the main repo.

It should not be so hard.  When you pull changes, it does not update 
files, but if you are also using Mercurial for change control, then it 
would produce a new "head" (a fork) which needs to be merged with your 
changes and then submitted to remove the new "head".  Mercurial 
normally automatically merges changes which appear not to conflict but 
then brings up a merge tool which the changes might conflict and 
require user intervention.

While Mercurial supports proper branches, within any given branch, 
there may only be one or two "heads" (your own "head" and a head from 
the other repository).  If there is a second head, that means that 
someone else made changes which need to be integrated and commited so 
you can see them.

The easiest way to avoid the double-headed problem is to pull remote 
changes before you do a commit.

> Would I have to clone the main repo and then clone a second copy for me to 
> work in?
>
> or is the simplest way to start over with a new cloned work dir?

Normally there should never be a reason to have to re-clone the 
repository in order to use it.  The only times I have done this is 
when I realized that I did something really bad (before pushing to 
another repository) and it seemed easier to re-clone than to repair 
the harm which was caused.

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