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 <n...@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 ____________________ Racket Users list: http://lists.racket-lang.org/users
