LogLevel [was std.experimental.logger formal review round 3]

[via Digitalmars-d]

On Thursday, 4 December 2014 at 10:16:52 UTC, Martin Nowak wrote:
> On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg
>> hack. I have stopped following the std.log thread, could you 
>> summarize what issues you're having and trying to solve and 
>> why not a more obvious solution doesn't work?
>
> Zero overhead for statically disabled log levels.
> The current proposal uses global version identifiers to alter 
> the behavior of std.logger.
> Fine grained (at least per library) control over log levels.
> The current proposal required to use different logger wrappers 
> in each library and scoped global version identifiers, see [1] 
> in the OP.

I like the direction you are taking, but I think the better 
solution is to have:

1. A manifest/config file where you configure these and other 
settings in a uniform manner.

2. Provide support for configurations and switching between 
configurations at realtime.

3. Compiler support for the manifest file that allows library 
code to query it at compile time as well as generating bitfields 
for real time switching between configurations. (Just memcpy to 
change configuration)

4. Have logInfo(…) etc as always inlined stubs.

5. Have one bit per log level (32 should be sufficient), rather 
than a number.

6. Allow for compiler profiling so that bits in the configuration 
that are accessed together become co-located on the same word/64 
bytes cacheline.

Something like this:

<configuration name="normal">
   <module match="*">
     <logging type="info" status="off"/>
     <logging type="error" status="on" logger="file" 
href="file://var/myfile.txt"/>
   </module>
    <module match="http">
     <logging type="info" status="on" logger="remote"/>
    </module>
</configuration>

<configuration name="debug" inherit="normal">
   <module match="mylib.*[has_symbol('DEBUG')]">
     <logging type="debug" status="on" />
   </module>
</configuration>