From: Darren Cook (darren_at_[hidden])
Date: 2005-05-20 04:11:40
> In order to make the Logging lib as usable as it can be, I'd like to
> know what is *your* scenario, when using a Logging lib.
I hope I'm allowed more than one... Actually all the use cases I can
think of are variations of one of the following two scenarios. If you
can make a logging library that can handle both scenarios *and* is still
easy to learn and use, I'm going to be impressed :-).
SCENARIO A: socket server
I define ERROR, WARN and INFO and all go in the same big log file.
Timestamp automatically prefixed. Three tab-separated fields (i.e.
timestamp, level, message).
It is always there in production code.
How it needs to be improved:
1. Be able to hide info, or info and warn lines when viewing the log
file. Alternatively write each level to its own log file, and have a
viewer that is able to combine the three files (I.e. typical usage is I
want to see what INFO/WARN messages led to an ERROR message). Any viewer
must work on Windows and linux.
2. Daily log rotation, with YYYYMMDD style datestamp going into the
filename. If hourly log rotation then YYYYMMDD_HHMMSS style datestamp in
(I also want logs older than N days to be gzipped, and log older than
a certain date to be deleted; but I'm happy - in fact happier - for
these tasks to be done by cron job not a logging library, as it is a
system administrators decision not a programmers decision)
3. Be able to start/stop a DEBUG level while the program is running.
4. Email me when an ERROR message occurs. Different levels of error
could go to different email addresses (i.e. more serious ones need to go
to a mobile email address).
SCENARIO B: debugging game tree search
Currently I use a simple LOG macro that writes to a log file. I then use
SMART_ASSERT() to stop when a problem is hit.
What I need to be able to see is when something asserts where it has
been recently. In certain cases this has generated 2+GB of log file
before hitting the assert, and taken over an hour.
I log board positions, i.e. two-dimensions. Or in other words my log
messages have carriage-returns in and I want formatting preserved.
I want certain information always written to the log: search depth,
total nodes so far, filename, line in the file, current function, etc.
But I'm fine that I have to write a custom macro that passes this data
on to the logging library macro.
I don't need or want timestamps in the log.
I don't need any threading support.
The LOG macro must be able to be compiled out completely. This is code
that once debugged and compiled in release mode should take a fraction
of a second to run.
What I want that I don't have: Instead of writing to a log file, I want
to write to a memory buffer, that only stores the last 2MB, or the last
100 messages, for instance.
Then when I have an assert I want to be able to output the contents of
that buffer. E.g.
can it be thinking to search so deeply?");
In-memory is important as writing to a disk file is a major performance
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk