Hi Matthew, Thanks for those thoughts.
On 01/22/2015 09:11 AM, Matthew Flatt wrote: > On 1 above: I've been uncertain of the best way to organize logging > from the start, but the idea of grouping topics hierarchically (such as > a "compilation" topic group) doesn't sound promising. I agree. Better perhaps would be a more relational approach. There are all sorts of cross-cutting ways one might like to filter log messages: - by package author ("all the messages in code I wrote") - by package - by collection - by module - by specific subroutine? - by level (debug, info, warning etc) - by phase - by place - by predicate (e.g. regexp) on log message or log datum I don't know how to do this yet. Certainly not with the efficiency of the current logging system! > I guess there's > often a mismatch between the producer's original idea of organization > the and consumer's eventual idea. Yes, that's a very good point. > On 2 above: I'm not sure why compilation or phase 1 is special. As more > and more libraries use logging, it seems like they will generate noise > (from your perspective) at run time, too. On reflection, I agree with you. Phase is just one of the many axes listed above. > In this sense, the "info" label is ambiguous. [...] > My only idea, then, is that we're missing a level somewhere between > "debug" and "warning". To me it feels like there is one major divison when it comes to levels: that between errors/warnings and informational messages. Within each grouping, less important subdivisions exist. If I can turn on and off the informational messages as a group, for individual *subsystems*, I think I'm happy. So my current "workaround" works OK for me. Adding an extra gradation between info and debug wouldn't add much in this example. I think I'm after finer control of selecting messages on axes *other* than level/severity. -- Tony _________________________ Racket Developers list: http://lists.racket-lang.org/dev