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

Right, I'm not saying these log messages are bad. Because if they're
bad, then I'm being evil.

My http and aws collections are loaded with log-debug, at a detail of
every HTTP request and response header line. Being able to do this was
critical to getting it working, and keeping it there to keeping it
working (bug fixes).

So what if a user of my collection set ,log debug to see her own logs?
 Good luck. They're doing to drown in mine.  What is the best practice
here, what should I do?

As for Racket's, before 5.3, the GC logs were relatively infrequent
and not too difficult to ignore. With 5.3, the optimization logs are
much more voluminous. That's what got me thinking, if these are
annoying, how much more of an annoyance am I causing?

Which is why I'm asking what's best practice here.  From my point of
view my question is sort of 10% about Racket 5.3, and 90% for my own
collections. But it seems like for both there's got to be the same
answer, and a better answer than "comment out the log-debug call
sites".

On Thu, Aug 30, 2012 at 11:05 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> On Thu, Aug 30, 2012 at 10:49 AM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
>>
>> I conjecture that the log messages you are seeing are
>> intended for the optimization coach only. It is worth
>> our while to check into making these messages 'private'.
>
> These messages were indeed added for the optimization coach, but
> they're general information, just like the GC info.
>
> One other solution is to just compile the files first, using 'raco
> make', and then you won't see any of the optimizer messages.
>
> Sam
>
>> On Aug 30, 2012, at 10:32 AM, Greg Hendershott 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
>>> ____________________
>>>  Racket Users list:
>>>  http://lists.racket-lang.org/users
>>
>>
>> ____________________
>>   Racket Users list:
>>   http://lists.racket-lang.org/users
>>
>
>
>
> --
> sam th
> samth at ccs.neu.edu