Before I saw your email, I sketched out a hypothetical successor to the current log system: ogl <https://github.com/greghendershott/ogl>
I would definitely be willing to help suggest how to change XREPL's ,log command to do some optional regexp filtering. As I mention in the README, I guess I'm confused/skeptical how this will really work upstream -- what is the "best practice" to tell people, and will they actually do it? For example it seems like with the status quo system, if people use the handy log-debug etc. wrappers to log-message, they're likely to do the wrong thing. Instead they either need to: A. Make/use a logger with a name (so that gets prepended in the log message). But in this case they can't use log-debug etc. which assume current-logger. Instead they have to restrict themselves to log-message. OR B. Prepend some facility name to all their calls. In this case they _can_ use log-debug etc. But will they always? If it's error-prone, it's likely log messages will leak. So ... I don't know. I'd love to see an approach where the easy/obvious/naive way people will tend to do it, is the preferred way. On Wed, Sep 5, 2012 at 7:02 AM, Eli Barzilay <e...@barzilay.org> wrote: > 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! ____________________ Racket Users list: http://lists.racket-lang.org/users
