[racket] 5.3's "mzc optimizer" log-debug, and log "facility" in general

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  
<greghendershott at 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.hammer at 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 <mflatt at 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 at 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 at 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.hammer at 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.hammer at dlr.de