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
