mORMot Open Source

But I still have to change every single reference to each function that you redeclare so that it says "SysUtils.SomeFunc" instead of "SomeFunc". That's a lot of code changes. And none of them relate to the logging functionality that I actually want. It reflects a "my way or the highway" approach on your part, where your users are expected to wholeheartedly embrace your whole framework and change everything to work with it. I can't do that. I have to put an explanatory comment next to the include just so my co-workers don't re-order it to match our coding standard and break the build. I was getting away with it as a "I'm just trying this to see if it works", but that's not a long-term solution. I do like the TSynLog.Enter trick, but it's much easier to add that to another logger than force your logger into our code.

You've had to make code changes to fix basic things, there is at least one severe bug, and there are things that don't work. I accept that it works for you, and that's great. But I don't think your logger is a useful shareable utility as it is. It's more of an internal part of your Synopse project. I am assuming that the rest of the Synopse code works much better than this internal part does, but I'm open to correction on that.

For comparison, I used OmniThreadLibrary quite a lot and found only one or two minor bugs, despite using it in ways that Primoz had not done. I found him responsive to requests and willing to accept criticism (also quite willing to criticise himself rather than always claiming that his code is wonderful). His code also works well with other peoples code, rather than everything having to change to use it everywhere. I can mix Delphi threads with OTL threads with no problems (great for incrementally changing over, in either direction).

Your code? Not so much. About half of the changes I'd like to make to your code relate to "does not play well with others". For example, adding to the sll... enum is easy. But it's declared in SynCommons. So I have to redo that change every time I get a new version. I'd like to move that and the matching const to a new unit that just has the two declarations. That's not hard. Hard is making SynCommons compatible with our existing code. The redefinitions of standard RTL functions problem is a big obstacle to me. You seem reluctant to extract the logging code from SynCommons, but I'm equally reluctant to make the huge changes to our code that the existing structure requires. And writing a wrapper for a logger impacts performance in a nasty way, especially in the geriatric Delphi 2006 I use at work that doesn't have good inline support.

I appreciate that open source is not "free as in beer", but at the same time I don't have unlimited spare time to contribute to FOSS projects, nor will my boss pay me to do that. So when I try to extract a minor part of your FOSS project and it doesn't do what I want, I don't expect you to make that one aspect your main focus, I accept that your requirements are not the same as mine and look elsewhere.

OK, I give up. I've just ripped all evidence of SynCommons out of my code and the ugly AV I've been chasing all day has gone away.

The problem is that it's a low level AV - the exception is in the kernal with a truncated call stack, so it's pretty much impossible to debug. I can't step to it because it happens in a DLL during the unload process (as far as I can tell). But I can't afford to spend more time debugging a log tool, sorry.

Oh, and thanks for the quick update with the dll name. I'm still not seeing mab files for the dlls or any identifier in the trace logs. For now I'm using that to detect dll usage in the "monolithic" debug executable. Is this something you think you'll be able to bring in in the next month or so?

Sorry, a couple more questions. I am logging within a dll and the profiler is not picking up method info:

20120223 09003447  +    
20120223 09003447 debug 	Loaded DLL
20120223 09003508  +    		
20120223 09003508  +    			
20120223 09003522  -    			 00.229.427

Even a pointer value here would be more useful than an empty space. The code to set up logging is a copy of the executable code:

library MyLib;
...
begin
   {$IFDEF DEBUG}
   TTextWriter.Create(nil,1024*1024); 
   // LOG_VERBOSE is everything, LOG_ALL_BUT_TRACE is less
   with TSynLog.Family do begin Level := LOG_VERBOSE; PerThreadLog := true;  end;
   TSynLog.Enter.Log(sllDebug, 'Loaded DLL');
   {$ENDIF}
end.

There's a map file, but no mab file being created.

Also, two log files. Is it possible to get instances to all write to the same file as I'm manually merging now and when I start doing that with 20-odd files from testing the packaged version of the executable it's going to be ugly. Ditto if I get a customer to turn on logging on site "please send me all the .log files". I have a request in for MadExcept which will solve that to some extent but don't know how long it will take to get it.

Also, when I get a log created by the dll the header still references the executable that loaded the dll. I haven't seen a dll referenced in the header yet.

When I'm working on a couple of nasty AV bugs I've got it'd be nice to be able to set AutoFlushTimeOut to less than 1s or the 4kB buffer to something more aggressive, even at the cost of overall performance. Getting every log entry when it's sent would be ideal. I'm using an SSD so even if Windows buffering doesn't work the drive is nice and quick.

Thanks for the logger. And the quick fix! Using an interfaced type to do trace logging is very cunning. BTW, our app is split into dll's for distribution but for development it's monolithic (and huge). Part of the size is because the packaging has not been well controlled so there is a lot of code included multiple times. But I'm working through Peganza reports to clean some of that up.

To deal with our existing really primitive log that's used in too many places I've replaced the internals of the class with this:

type TMyLogger = class
   private
      fLogWriter: TTextWriter;
      fLog:ISynLog;
...
constructor TMyLogger.Create;
begin
   fLogWriter := TTextWriter.Create(nil, 1024 * 1024); // but never free it - it's a magic self-garbage-collecting object
   TSynLog.Family.Level := LOG_VERBOSE;
   TSynLog.Family.PerThreadLog := True;
   fLog := TSynLog.Enter();
end;

procedure TMyLogger.Output(const Text: string);
begin
         //AV: fLogWriter.AddLine(AsText);
         //no log file: TSynLog.Enter().Log(sllCustom1, AsText);
         fLog.Log(sllCustom1,Text);
end;

Is that a reasonable way to do it? Would you do it a different way?

thanks again
Moz