Yes, you are right. define/provide-logger seems like the best way to go.
But a logger-out may still be useful to explicitly re-provide the names,
e.g. if the logger was defined in a 'private' file.
On Sat, 08 Sep 2012 01:48:18 +0200, Greg Hendershott
<greghendersh...@gmail.com> wrote:
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
--
---------------------------------------------------------
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
