[Haskell-cafe] hslogger bugs or features - patches

[John Goerzen]

Marc Weber wrote:
> 
> I've written some patches increasing speed by 30%. See the benchmark.

Hi Marc,

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.)

-- John