[racket] 5.3's "mzc optimizer" log-debug, and log "facility" in general
I just looked at the "14.5 Logging"
<http://docs.racket-lang.org/reference/logging.html> docs for the
first time in a year or more.
So you can define multiple and hierarchical loggers. It seems like
this is the intended way to handle something like a "facility"?
I'll ponder this more and see if I can boil it down to a sort of
cookbook recommendation -- "You should define a logger for your
collection, like so ..." -- which was never obvious to me.
On Thu, Aug 30, 2012 at 10:32 AM, Greg Hendershott
<greghendershott at gmail.com> wrote:
> Thanks, Robby.
>
> Do you mean I could do something like this?
>
> (define (enable-log-output level)
> (let ([r (make-log-receiver (current-logger) level)])
> (thread
> (lambda ()
> (let loop ()
> (match (sync r)
> [(vector lvl msg v)
> (printf "; [~a] ~a\n" lvl msg)])
> (loop))))))
> (enable-log-output 'debug)
>
> If so, then:
>
> 1. I don't see what you mean re being able to do more than string
> munging. `v' is a continuation-mark-set. Is that the struct you mean?
>
> But stipulating I could filter in whatever fashion ...
>
> 2. Putting this in every source file doesn't seem practical? I'm
> talking about doing interactive development, using XREPL's ,log
> command. Open a file, evaluate it, make some changes, maybe use ,log
> to tweak the log output level, evaluate, move on to another file. That
> sort of work-flow.
>
> 3. I have to ask users of my collections to use code like this, to
> avoid getting "drowned" in my log-debug output? That doesn't sound
> good.
>
>
> ,log already does filtering on one "dimension" ("severity") without
> touching your source, which is great. It seems odd to have to use
> per-file code, in order to filter on another dimension ("facility" or
> "module").
>
>
> On Thu, Aug 30, 2012 at 8:55 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> On Thu, Aug 30, 2012 at 6:29 AM, Greg Hendershott
>> <greghendershott at gmail.com> wrote:
>>> I have some code with copious log-debug calls. Occasionally I set
>>> ",log debug" to see the output.
>>>
>>> New in 5.3, I'm seeing many dozens of outputs like the following:
>>>
>>> ; [debug] mzc optimizer: inlining: involving: core727 in: unpack728 in
>>> module: 's3 size: 149 threshold: 320
>>>
>>> These are interleaved with and badly obscuring my own debug output.
>>>
>>> I've been trying to ignore these and live with it the last couple
>>> weeks, but it's proving difficult.
>>>
>>> 1. Narrow question: Is there a way I can disable the mzc debug output,
>>> while preserving my own?
>>
>> You can set up your own log receiver and filter out the messages that
>> you want (note that you can filter based on racket data structures,
>> not just string munging as log messages have a value associated with
>> them that you can query).
>>
>> Robby