Re: [Haskell-cafe] hslogger bugs or features - patches
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. Which type to assign to [] ? Right now I'm using instance HL.LogHandler () where -- doh! find a better way to pass an empty list below setLevel = error should never be rearched getLevel = error should never be rearched emit = error should never be rearched close = error should never be rearched HL.updateGlobalLogger (HL.addHandler fh . HL.setHandlers ([] :: [()]) ) ... But I'm not satisfied with that. But I couldn't find a better solution either. Eg I've tried [] :: [SyslogHandler] (SyslogHandler is not exported, is it?) [] :: [GenericHandler ()] (GenericHandler isn't exported either?) Sincerly Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features - patches
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features - patches
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features - patches
Hi Marc, I have pushed to my hslogger repo the optional priority for a logger support that we talked about, which is the Haskell version of Python's NOTSET. It is currently untested and represents only a minor API change. Please take a look and let me know your thoughts. It adds one new function to the API (clearLevel) and changes the return type of getLevel. Other than that, the changes are pretty much hidden from the public interface. I looked at your git repo, but I'm not going to pull anything from it right this minute. I would consider your performance change, but it was wrapped up with half a dozen other things in a single commit so I couldn't extract just it. If you would split up your changes into small bite-sized diffs, where each one makes exactly one change and is documented, I would be happy to take another look. As it is, each patch is touching too many unrelated areas for me to really bring them in. (I don't want API changes just for a performance improvement.) hslogger is used by a bunch of code all over the place, so I want to be very careful about what I do to it to avoid causing a lot of hassle for a lot of people. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features - patches
On Tue, Feb 03, 2009 at 02:55:15PM -0600, John Goerzen wrote: I looked at your git repo, but I'm not going to pull anything from it right this minute. I would consider your performance change, but it was wrapped up with half a dozen other things in a single commit so I couldn't extract just it. Also, there is *no way* I will apply any patch that removes my copyright notices, as your git branch does. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features - patches
== issue 1 That's not the most awkward thing: When logging to A.B.C hslogger does add 3 loggers to the global logger Map: A A.B A.B.C all three inheriting the default priority level of the default rootLogger A test application illustrating this (feature ?) module Main where -- packages: hslogger import System.Log.Logger as HL import System.Log.Handler.Simple as HL main = do -- the default logger logs to stderr level WARNING -- that's why the following message should be shown -- a) logM A.B.C HL.ALERT ALERT test, should be shown and should create the sublogger -- b) updateGlobalLogger rootLoggerName (setLevel EMERGENCY) logM A.B.C HL.ALERT ALERT test, should not be shown cause we have changed to EMERGENCY which prints: tmp %./test1 /tmp nixos ALERT test, should be shown and should create the sublogger ALERT test, should not be shown cause we have changed to EMERGENCY I've written some patches increasing speed by 30%. See the benchmark. 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) The basic interface updateLogger name (set priority or add handlers) and logM is still the same. The logM is based on MonadIO now. So you no longer have to call liftIO yourself.. Also I've removed the standard setup logging to stderr. There is a setupLogging function instead.. 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) 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) I also wonder wether it's worth using Bytestrings instead of Strings? I've not spend to much time on updating all the documentation yet.. If you'd like to ensure that a use case sill works add another test case please. You can also push to that git repository. Sincerly Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features?
On 2009 Jan 31, at 20:28, Marc Weber wrote: tmp %./test1 /tmp nixos ALERT test, should be shown and should create the sublogger ALERT test, should not be shown cause we have changed to EMERGENCY which is quite confusing because I haven't told hslogger explicitely to use a log level printing ALERTs on A.B.C. so I'd expect that only the first message is shown. This behaviour is explained by the inheritance of the loglevel when hslogger creates them (without attaching handlers) automatically. I don't want the logging behaviour depend on wether a log line has been emitted before or not. Do you agree? Have I missed something? At least some of what you've missed is that this is inherited from the C syslog library; possibly this should be using withSysLog (options) $ ... to bracket a use of syslog with appropriate openlog()/closelog() and changing top level options should only be attempted in the openlog() call. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hslogger bugs or features?
Following the advice on the hslogger wiki
(http://software.complete.org/software/wiki/hslogger)
I'm posting my thoughts about hslogger here:
What is wired?
This piece of code (src/System/Log/Logger.hs):
parentHandlers name =
let pname = (head . drop 1 . reverse . componentsOfName) name
in do
[...]
next - parentHandlers pname
return ((handlers parent) ++ next)
Why?
Because when logging to A.B.C it splits the String once to get
[A,B,C], then it drops the last part and runs the same again for
A.B and so on..
So A string is split 3 times for one logging action. I think this is a
waste of cpu cycles.. I'm going to improve this. While reading the code
i noticed two issues:
==
issue 1
That's not the most awkward thing:
When logging to A.B.C hslogger does add 3 loggers to the global
logger Map:
A
A.B
A.B.C
all three inheriting the default priority level of the default
rootLogger
A test application illustrating this (feature ?)
module Main where
-- packages: hslogger
import System.Log.Logger as HL
import System.Log.Handler.Simple as HL
main = do
-- the default logger logs to stderr level WARNING
-- that's why the following message should be shown
-- a)
logM A.B.C HL.ALERT ALERT test, should be shown and should create the
sublogger
-- b)
updateGlobalLogger rootLoggerName (setLevel EMERGENCY)
logM A.B.C HL.ALERT ALERT test, should not be shown cause we have
changed to EMERGENCY
which prints:
tmp %./test1
/tmp nixos
ALERT test, should be shown and should create the sublogger
ALERT test, should not be shown cause we have changed to EMERGENCY
which is quite confusing because I haven't told hslogger explicitely
to use a log level printing ALERTs on A.B.C. so I'd expect that only
the first message is shown. This behaviour is explained by the
inheritance of the loglevel when hslogger creates them (without
attaching handlers) automatically.
I don't want the logging behaviour depend on wether a log line has been
emitted before or not.
Do you agree? Have I missed something?
solution:
replacing
data Logger = Logger { level :: Priority,
handlers :: [HandlerT],
name :: String}
type LogTree = Map.Map String Logger
by a real log tree:
data LogTree = LogTree {
level :: Priority, -- level only applies to handlers, not to subLoggers
handlers :: [HandlerT],
subLoggers :: Map.Map String LogTree
}
==
issue 2
The second ineresting point is (bug or feature?) that you can make the
root logger shut up by setting different log levels to sub loggers:
this sample does illustrate it:
module Main where
-- packages: hslogger
import System.Log.Logger as HL
import System.Log.Handler.Simple as HL
main = do
updateGlobalLogger (setLevel DEBUG)
updateGlobalLogger A (setLevel EMERGENCY)
logM A HL.ALERT ALERT test, should not be shown cause we have
changed to EMERGENCY
It doesn't print anything although the default log handler on root (=)
is set to loglever DEBUG. So there is no way to get all logmessages
without removing all all setLevel calls to subloggers?
Is this desirable?
==
my conclusion:
About issue 1 I think its a bug
About issue 2 I don't know. I think there should be a way to get all log
messages. So I feel this is a bug as well.
I neither have checkeg the logcxx nor log4j nor the reference
implementation in python.
Thoughts?
Sincerly
Marc Weber
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
