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

I've been slow to reply because I wanted to organize my thoughts into
a nice proposal. Maybe try some ideas in code. But meanwhile, here are
some of those raw-ish thoughts.

== Emitting logs ==

- I like your idea of defining multiple loggers. But I think could be
done less explicitly.

- I think in practice the interesting "facility" scope would correlate
with entire collection libraries, or actually individual modules.

- As a result, I wonder if things like log-debug should just
automatically use a per-module name from syntax-source. As a bonus,
naive library writers automatically "do the right thing" when using
log-debug and friends. (Whether this means there is one logger? object
per module, or it's one logger? for all but with a module ID in each
log-message, I'm not sure.)

- As long as the hood is open, I'd love if a new log-xxx were `format'
style (more like `error') instead of a single string. i.e. 95% of the
time I'm typing (log-debug (format ...)).

== Consuming logs ==

- I'd want to control visibility via the REPL, more often than via env
vars (personally).

- I'd want to choose different levels for different modules. Most
commonly that would be an elevated level for a few specific modules,
and a lower level for "all other".  For example, "I want 'debug for
under-dev.rkt, and 'warning for all others".  However there could be
times when it would be helpful to supply a list of arbitrary (module
level) pairs. Such as 'debug for foo.rkt, 'info for bar.rkt, 'info for
baz.rkt, and 'warning for all other.

- I suppose it could be handy to use a path notation for this. e.g. I
want 'debug level for "racket/*" or just for "racket/xrepl".  (This
assumes the logs emit per-module, not per-"library".)

- It would be neat if submodules could somehow be used to mitigate the
"cost" of logging, as they do for tests or srcdoc. However I guess
it's apples and oranges?

On Thu, Aug 30, 2012 at 12:07 PM, Neil Van Dyke <neil at neilvandyke.org> wrote:
>
>
> Matthew Flatt wrote at 08/30/2012 11:28 AM:
>
>> At Thu, 30 Aug 2012 10:50:01 -0400, Greg Hendershott wrote:
>>
>>>
>>> So you can define multiple and hierarchical loggers. It seems like
>>> this is the intended way to handle something like a "facility"?
>>>
>>
>> It looks like we're going to add a `current-optimization-logger'
>> parameter to Racket, and the optimizer will send its messages there.
>> So, you won't see optimizer messages when you look at debug messages to
>> the main logger.
>>
>> Maybe we should also add an environment variable that causes the
>> initial optimization logger to make itself a child of the main logger.
>> Then, when you set the environment variable and look at messages to the
>> main logger, you would see optimization logging, too. (Is there a
>> better way to go than environment variables?)
>>
>>
>> Would that be a good way to externally select logging information in
>> general? I imagine a form
>>
>>   (define-logger zoo)
>>
>> that binds
>>
>>   current-zoo-logger
>>   log-zoo-error
>>   log-zoo-warning
>>
>> etc., and arranges for the initial zoo logger to be a child of the
>> current logger iff the ZOO_LOG environment variable is set.
>
>
> Will this result in an explosion of potential environment variables to maybe
> on average one per Racket library, and will this conflict with
> non-Racket-related environment variables in practice?
>
> And will "PLTSTDERR=debug" (and the analog of that in DrRacket) still work
> for getting all the messages, including "zoo" ones?
>
> I'm guessing you could make the above "define-logger" approach perform a lot
> better in some cases than the following?
>
> (log-debug 'zoo "this is my message")
>
> PLTSTDERR="error zoo=debug circus=warning"
>
> Neil V.
>
>
>
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users