On Mon, Feb 13, 2012 at 9:12 PM, James Miller <ja...@aatch.net> wrote: > On 14 February 2012 10:17, Sönke Ludwig > <lud...@informatik.uni-luebeck.de> wrote: >> Log levels "debug" and maybe also "trace" would be useful, but I see that >> vlog(n)() is meant for that purpose. I would just prefer explicit names >> instead of just numbers. >> >> Is there a compelling reason why formatted logging is not the default? I >> find that most logging calls in practice use formatted output, and the only >> overhead would be searching once through the format string in the case of >> format placeholders. >> >> A predefined logger for OutputDebugString on Windows would be useful - or >> maybe it could be used instead of stdout at least for non-console >> applications. >> >> One kind of log writer that I have in my code is one that outputs a nicely >> formatted HTML file with built-in JavaScript to be able to filter messages >> by priority or module. Maybe this is too much for a standard library >> implementation though. >> >> Support for multiple log writers can be useful (e.g. logging to a file + >> logging to stdout or to a log control inside of the running application). Of >> course, one can also simply write a "MultiDispatchLogger"... >> >> A format option to log the thread name instead of just the ID. > > I agree that there needs to be an easy to use format-based logger, > even if its just logf template that calls format on the filter, since > writing `log!(info).format("my string %s", s);` looks bad compared to > `logf!info("my string %s", s);` > > Looking through the docs, there needs to be a better indication of > configuration in the primary example, since you don't even mention it, > I thought it might not exist. > At the top of the documentation I wanted information on how to use the module for the common developer. To me the common developer is going to write log message not configure the log module/framework.
The user that is going to configure the library can read the whole document or the Configuration classes. Thoughts? > A built-in console logger should probably be available, one that > writes to stdout at the very least, since I often need log messages > for debugging, other loggers can be build on top of the Logger > interface, separate from the library, but I imagine that many people > would want a console logger and doing it in the standard library will > prevent too much repeated work. It would also be an idea to make it > the default, but at this point I can't really separate out my > practices from what I think most people do. > The default FileLogger can do this. See --logtostderr, --alsologtostderr and --stderrthreshold. > A debug-level log would be nice, but I don't really care either way. > > A built-in MultiDispatchLogger (or similar) would be nice, but I don't > think it really matters. > Yeah. We could use a few other loggers. But we should think of this as a living module. The most important thing I think is that we can make this future improvements without breaking existing users. > Otherwise, I think it all looks good; fairly simple to use and > configure, ability to override the defaults if needed, ability to swap > out backends at runtime. The docs need work, but docs always need work > :P. > > It might not mean much, but this gets my approval. > > James Miller