Review: std.logger

Paolo Invernizzi via Digitalmars-d digitalmars-d at puremagic.com
Sat Jul 26 03:39:59 PDT 2014


On Thursday, 24 July 2014 at 18:51:03 UTC, Andrei Alexandrescu 
wrote:
>
> 0. There's no way to set the minimal logging level statically, 
> except for an on/off switch. There must be a way to define e.g. 
> -version=logLevel=trace that sets the minimum logging level 
> actually performed. Any logging below that level is a no-op. 
> Which segues into the next problem:

Internally in SRLabs we are using a logging library with static 
logging level and static tagging of the log lines, something like:

   logdbg!(GL, SUR, REND, DBG_AA)("initialising the surface and 
the texture data");

Where 'logdbg' is just an helper for having the right log level 
template params.
The tags are defined and reserved in a common module in a tuple, 
and commented/decommented by the single developer by needs (well, 
actually we are mixing an external not committed file):

   ...
   CAVS,  /// cavs machinery.
   //GL,      /// flavour OpenGL.
   //PAR,    /// descriptors parser.
   REND, /// global renderer threaded loop.
   //SUR,    /// generic mixed library HL surface handlers.

   // ... reserved to developers ...
   //DBG_AA, /// Aaron is interested in that for his debugging 
purpose.
   DBG_PI,  /// Paolo is interested in that for his debugging 
purpose.


So, we have a very nice granularity and a compile-time 
guillotine, and we can cherry-pick log emissions in a very 
pragmatic way in different context (bugs hunting, production, 
test environ, etc).

The tag approach is strange, and for what I know, it's something 
that I've never seen around, but everyone here is liking it a lot.

> 1. There's a bunch of code still generated even with logging 
> statically disabled (per http://d.godbolt.org). I could not 
> find a way to completely eliminate generated code. Unused lazy 
> parameters MUST generate no code at the front end level. This 
> is a performance bug in the D front end that blocks acceptance 
> of this proposal.

That's the big problem: we were able to completely obliterated 
log lines that don't use lazy parameters, but the lazy is just 
unavoidable in a log library: I'm very interested in a solution 
for this issue.

---
Paolo



More information about the Digitalmars-d mailing list