Hi John, 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 it. 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. Conclusions: 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. Sincerly Marc Weber