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