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
> 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*
Racket Developers list: