That's a good point, Tobias. I'd actually be fine with `define-logger' acting like `define/provide-logger' -- just go ahead and provide them all.
Because I don't see opacity being such a useful option for a logger, as opposed to something like a struct? On Fri, Sep 7, 2012 at 12:21 PM, Tobias Hammer <tobias.ham...@dlr.de> wrote: > Thanks for these great new features! > > A (logger-out name) form for provide, exports all functions generated by > define-logger might be useful too. > > Tobias > > > > > On Fri, 07 Sep 2012 16:28:13 +0200, Matthew Flatt <mfl...@cs.utah.edu> > wrote: > >> Based on the discussion, plus some extra off-list discussion with Greg, >> I've made the following changes: >> >> * The `log-error', etc. forms still treat a single subexpression as a >> literal string for the log message, but now they treat multiple >> subexpressions as arguments to `format'. >> >> This change balances backward compatibility, convenience, and >> interaction with the new `racket/format' library (which I'll post >> about on the dev list). >> >> * Add `define-logger', where >> >> (define-logger zoo) >> >> binds >> >> log-zoo-error >> log-zoo-warning >> ... >> >> that write to a logger that is created a child of `(current-logger)' >> with the name 'zoo. >> >> Unlike what I suggested before, the `define-logger' form doesn't >> create a parameter and it doesn't inspect environment variables. >> Those ideas were on the wrong track --- trying to filter at the >> producer side, instead of the consumer side of logging. >> >> * Changed `make-log-receiver' to accept a sequence of level symbols >> and name symbols. For example, >> >> (make-log-receiver logger 'debug 'GC 'error) >> >> receives 'debug level events from children of `logger' that are >> named 'GC, and it receives 'error events from all other loggers >> under `logger'. >> >> The logger name in a receiver affects `log-level?' queries in the >> way that you'd expect, which avoids unnecessary work on the producer >> side while keeping consumers in control. >> >> * Changed -W, -L, PLTSTDERR, and PLTSYSLOG to allow specifications >> like "debug@GC error", which is analogous to the `make-log-receiver' >> call above. That is, a level can be suffixed with "@" and a logger >> name to restrict the level specification to apply to a logger name. >> >> Note that you can use >> "debug none@optimizer" >> to see all debug messages except those from 'optimizer, since a >> level without a name applies only to loggers that are not otherwise >> mentioned. >> >> This change is based on Neil's suggestion, but with a syntax that I >> find more suggestive and more in parallel to `make-log-receiver'. >> >> * Changed the GC to log messages to a 'GC logger, the optimizer to log >> to an 'optimizer logger, and the futures subsystem to log to a >> 'future logger. >> >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users > > > > -- > --------------------------------------------------------- > Tobias Hammer > DLR / Institute of Robotics and Mechatronics > Muenchner Str. 20, D-82234 Wessling > Tel.: 08153/28-1487 > Mail: tobias.ham...@dlr.de > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
