Voting: std.logger

[Andrei Alexandrescu via Digitalmars-d]

On 7/29/14, 4:09 PM, Robert burner Schadek wrote:
> I'm not sure how you except log(LogLevel.xxxx, "Hello world") to be
> disabled at compile time if LogLevel.xxxx is a runtime value? Or do I
> misunderstood you?
>
> you can choose to disable name based logging like trace("Hello trace")
> at CT with the current release

In all likelihood I misunderstood you! Whenever a LogLevel is passed 
explicitly there's no static complete elimination possible as you mentioned.

I now see a bunch of versions: DisableXxx (5 total) and DisableBelowXxx 
(5 total). That's fine if a bit out of character with the simplicity of 
the rest of the library.

> If you disabled one on the names logging functions at CT other
> prototypes will be used that have no lazy in it. You said that empty
> functions with lazy parameter are not optimized away. So there are no
> empty functions with lazy parameter if you disable these functions. As
> soon as the compiler can kill empty functions with lazy arguments this
> branching can be removed without any user code adjustment.

No, they should stay lazy. The code of the lambdas is still generated, 
that's the main problem.

As a matter of policy I'd rather push std.log and the compiler 
improvement together. Otherwise we push std.log and then nobody fixes 
the compiler, ever. We must put pressure on the compiler folks.

> Overloads are implemented in the current version. They behave as you
> described.

Awesome!

>> 5. I was hoping for a resolution on throttling. However, now I realize
>> that conditional logging plus throttling functions that return true
>> once in a while should work acceptably well. Higher-order functions
>> taking lambdas that log would also be a nice possibility. So... no
>> request here.
>
> Creating a std.logger.conditions module is on my todo,
> std.logger.(stderr,stdout) will be cut because of being to noisy. I'm
> thinking of
> * anyN
> * anyNmillisec
> * firstN
> * ...

Prolly these are good outside of logger, they have wider applicability.

>> 6. I'm still hoping for RefCounted as the storage for the class
>> backend. I realize users can do their own management but log objects
>> are unlikely to contain cycles and other liabilities for reference
>> counting, and at some point if we want to use reference counting where
>> appropriate we got to start somewhere with a few solid precedents.
>> This is negotiable, but I plan to fight for it.
>
> IMO something is wrong in the users code if the GC working on Logger
> instances is slowing the code done. The Logger instances properly stay
> around for the length of the programs execution. If you create Logger in
> a tight loop RC will properly slow you down as well.

Agreed. I'm just saying... well what I said: RC should be an obvious 
default to reach for unless true GC is needed.


Andrei