[Haskell-cafe] hslogger bugs or features - patches
jgoerzen at complete.org
Tue Feb 3 10:37:50 EST 2009
Marc Weber wrote:
> I've written some patches increasing speed by 30%. See the benchmark.
Patches are always great to see! Where is this benchmark?
Can you separate out your speed changes (which I take it have no impact
on functionality or API) from your other changes? I am not certain that
I would want to apply the other changes.
> You can get them by cloning git://mawercer.de/hslogger;
> (branch hslogger_updates)
> I've replaced the internal representation (Map name Logger) by a tree.
> Only logging to a logger does no longer add a new node (which cloned the
> priority level in the past causing issue 1)
As I said, I'm not really convinced this is a real issue. I'm still
open to it though -- but I'm unconvinced that the change in API is worth
it at this point.
> Also I've removed the standard setup logging to stderr. There is a
> setupLogging function instead..
I'm not sure what you mean the "standard setup logging to stderr". Do
you mean the default root handler?
> Why? I can think of some use cases where logging to stderr doesn't make
> sense and it took me too much time figuring out how to remve the old
> stderr logger (I didn't find a nice solution without changing the
> exposed API)
You didn't notice setHandlers?
-- | Set the 'Logger'\'s list of handlers to the list supplied.
-- All existing handlers are removed first.
setHandlers :: LogHandler a => [a] -> Logger -> Logger
It is perfectly valid to set the root logger's handlers to  if you
want it to do nothing at all.
> I don't want to start using my "personal" copy of hslogger. That's why
> I'd like to ask you wether you consider these changes beeing
> improvements although they break existing code (You'll have do add that
> initialization line)
At this point, I'm not convinced that the API changes are actual
improvements. But I'm not saying "never".
> I also wonder wether it's worth using Bytestrings instead of Strings?
To what end? The only reason I can think of is UTF-8 output.
(does putStr output UTF-8 these days, or still truncate the 24 bits
above the low 8 like it used to? I haven't checked.)
More information about the Haskell-Cafe