[racket-dev] (reposted from users) Noisy compiler at PLTSTDERR=info

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