Tim is correct. The log macro is what you want to use when you're really just wanting to log something; in that case the message expression won't get evaluated unless the particular logging level is enabled.
The debug function is for when you want to execute an expression regardless, but would also like to have the expression and its result logged. In this way it is analogous to the time function. I agree the naming isn't very self-descriptive (trying to keep things short), but I welcome any suggestions. Also note that the log levels are like commons-logging/log4j: trace, debug, info, warn, error, fatal. I've submitted the code to assembla, but once it's up in git, I plan on adding support for levels that correspond to java.util.logging. On Jul 23, 4:19 am, Laurent PETIT <laurent.pe...@gmail.com> wrote: > Thanks for the explanation, that makes sense. > > 2009/7/23 Timothy Pratley <timothyprat...@gmail.com> > > > > > > > Hi Laurent, > > > I believe using > > (log :fine (expensive-calc)) > > will do precisely what you describe (not do anything unless > > level :fine is enabled, and return nil) > > > (debug (some-expr)) is intended when you want to leave the logic > > precisely as is but display part of the calculation; > > (+ a b (- c d)) > > ; I can easily examine part of the equation that I think might be > > wrong: > > (+ a b (debug (- c d))) > > > This produces the same output and logic as the original statement, but > > if the logging level is :fine then it will additionally log the > > intermediate part. I find both forms useful. Unfortunately the naming > > gives no clue as to the differences between them. > > > Regards, > > Tim. > > > On Jul 23, 7:27 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote: > > > Hello, > > > > 2009/7/23 ataggart <alex.tagg...@gmail.com> > > > > > Ok, I've updated the code with some of Tim's code: > > > >http://paste.lisp.org/display/84053 > > > > > The "public" functions/macros are: > > > > > enabled? [level] [level log-name] > > > > true/false whether that level is enabled for the current namespace > > > > or log-name > > > > > log [level message ...] > > > > logs the message either directly or via an agent. The selection > > > > logic defaults to agent, unless the *allow-direct-logging* flag is set > > > > to true and the log is not being called from within a running > > > > transaction. > > > > > debug [expr] > > > > Evaluates and returns the expr. If debug is enabled logs the form > > > > and its result. > > > > One of the problems with logging in traditional java is that you have to > > > encapsulate your call to debug with an isDebugEnabled (for example) call > > > before doing a potentially heavy computation for expr : > > > > if (log.isDebugEnabled()) { > > > String message = <potentially heavy computation>; > > > log.debug(message); > > > > } > > > > In clojure, with macros, it is easy to get rid of this verbose pattern: > > > (debug <potentially heavy computation>) => the macro can generate the > > > boilerplate for us. > > > > But I see your debug function/macro always returns the result, so the > > > problem we had in java remains intact ? > > > What about just making debug return nil (so that it's clear that its > > primary > > > use implies a side effect) and generate the code to only evaluate the > > > expression generating the message if necessary ? > > > > I know that it would make you change a lot of your library, but I think > > this > > > functionality is important. > > > > Regards, > > > > -- > > > Laurent --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
