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

On Thursday, Robby Findler wrote:
> 
> > But stipulating I could filter in whatever fashion ...
> >
> > 2. Putting this in every source file doesn't seem practical? I'm
> > talking about doing interactive development, using XREPL's ,log
> > command. Open a file, evaluate it, make some changes, maybe use
> > ,log to tweak the log output level, evaluate, move on to another
> > file. That sort of work-flow.
> 
> IIUC, this is something you'd do instead of using ,log.  You can
> require some helper library with the function in it, or probably Eli
> has some way to add more commands or something like that.  Or maybe
> even a patch to ,log that'd let you specify a regexp in the case
> that string munging was the best option?

Regardless of the potential extensions that will come out of this
discussion, it's pretty obvious that something like the above would be
very helpful.  Greg: looks like you know where the source of the xrepl
,log command is, so if you see a nice way to extend it, then I'll be
happy to go over it and do the change.

Maybe something like this? --

  instead of

    ,log <level>

  you get

    ,log <logspec> ...₁

  where the <logspec>s are "and"-combined, and each one can be:

    <level>        same as now, for a symbol, integer, or boolean
    "prefix"       show all messages that start with "prefix"
    #rx"text"      show all messages that match the regexp

  And possibly even another one:

    (lambda ...) or (λ ...)
                   an explicit user-defined filtering function

  This is a little ugly, since it would have to be a syntactic
  function form, so another alternative is that if the <level> is not
  one of the known symbols (or a boolean, number, string, or regexp),
  then it's considered an expression.  Another alternative is to make
  the log level always be an expression, so you'll need to change your
  use of ",log something" to ",log 'something".  (Incompatible, but
  this is an interactive tool anyway, and it sounds like you're the
  most interested user of it...)

As for an extension, while it sounds fine to have the optimization
information appear in a "more hidden" way, I think that overall this
will continue to be a problem -- like you said, in cases where you add
your own logging information.  Personally, I don't think that there's
any problem with doing the filtering "mostly" at the string prefix
level, since this is a facility that is ultimately producing
information in textual form...  In addition it works nicely for unix
log files, and there's probably a bunch of tools that could work with
it too -- in contrast to dealing with Windows log events that are much
harder (IME) to deal with (unless you serialize them into strings
first...).

And BTW, tying some default log format to the module sounds good in
theory, but I think that it can often be a bad idea since modules are
smaller components than what you're usually interested in, which is
"my library".  An alternative that could be useful is to just have
some log form that prefixes the output with its source location (eg,
as the usual "/dir/file.rkt:1:2:" prefix), which you can then use with
a prefix filtering.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!