[Haskell-cafe] hslogger bugs or features - patches
marco-oweber at gmx.de
Tue Feb 3 12:40:55 EST 2009
Yes, a NotSet corresponds to my new "Nothing" setting.
Proably you're right that adding that would have been enogh.
API changes: Probably you're talking about the introduction of those
classes? The idea was to not have to split that String over and over
again. This way I thought you could pass over the logger path
(LoggerName ["A","B","C"]) directly..
> Where do I find the benchmark?
Look it up in tests/Benchmark.hs and the .cabal file.
I've added the benchmark first before having done most updates so that
it's easier to compare the results.
About the Bytestring thing I won't bother you until I'm sure it's worth
You're right: in a ready to go application you always keep the default
logger. But I want to use hslogger also to verify that my application
does what I think it should be doing ..
And while learning about hslogger you will do things in different order.
Maybe its just that the most important parts about hslogger didn't came
through to my mind.
Maybe one can shorten that all to this. At least that's how my change
are supposed to work:
The logging sytem is based on a tree. To each tree node you can attach
handlers. When a loogging action is performed the tree is traversed from
the logger name up to the root. The first node having attached an
logging priority will be used to decide wether the message gets logged
at all. If its logged all the handlers having been attached to the
visited nodes will be called.
having this setup:
"A.B.C" log priority EMERGENCY
"" log priority DEBUG
the handlers atteched to "" won't get debug messages send to the "A.B.C"
logger. So there is no way to trace all messages without knowing about
all sub logger level settings.
Something like this would have been enough give me an idea what the
library really does.
Anyway the least thing I need is the NOTSET logger level setting.
Wether we call it Nothing or NOTSET doesn't matter.
More information about the Haskell-Cafe