On Thu, 26 Aug 2010 21:34:43 -0400, Walter Bright
<[email protected]> wrote:
Andrei Alexandrescu wrote:
At my workplace we're using Google's logging library glog
(http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
more I use it, the more I like it. It's simple, to the point, and
effective.
I was thinking it would be great to adapt a similar design into
Phobos. There will be differences such as use of regular argument lists
instead of << etc., but the spirit will be similar. What do you think?
Ok, I'm going to get flamed for this, but,
I don't get it
I do logging all the time. It's usually customized to the particular
problem I'm trying to solve, so it involves uncommenting the right
printf's and then running it. Voila. Done.
The logging libraries I've seen usually required more time spent
installing the package, getting it to compile, reading the
documentation, finding out it doesn't work, rereading the documentation,
etc., etc., than just putting in a #...@$%^ printf, and Bang, it works, cut
& print.
Even worse, the logging libraries are loaded with a grab bag of trivial
features to try and puff it up into looking impressive. They always
seemed to me to be a solution in search of a problem.
Shields up! what am I missing about this?
Logging libraries are useful because they are configured at runtime, that
means you can not only configure them without recompiling, but you can
reconfigure them while actually running the code. This can be
indispensable if you have a system that's acting funny. Just augment the
log level and all of a sudden you get all the data you need, where as if
you had to recompile and restart, the problem goes away. They
traditionally are also not invasive, so if you configure them to not print
something, the code isn't significantly lower performing.
They are also useful not only in debug mode, but also for normal usage. I
can't tell you how many times I had a technician tell me he didn't do
something, and I can point at the log which recorded that he did. There's
no argument, no goose-chasing some possible bug because some tech didn't
want to admit he fucked up. It can also give you extremely valuable
information of what happened leading up to a bug, in time-ordered fashion,
so you can get an exact picture of what happens. This is important for
those once-a-month bugs that you don't know when they are going to pop up.
I had a server-client system that used tftp to download boot images to
hundreds of computers. Because of the nature of the product I had to
write my own tftp server. On the surface, it's not hard to implement, but
when you have to start dealing with all the nuances of tftp *client*
implementations that are sometimes part of a BIOS boot ROM, you find
things that aren't in the RFC :) By changing one file, I can output every
single tftp packet received and transmitted (and *only* that, another
feature of logging -- levels can be selected per named log instance) and
see exactly where the problem is.
The second half of a logging library is the output part. Most log
libraries provide a wealth of means to output logging data, from text
files to network logging, to sticking things in the Windows event log.
This is not trivial to implement, and is not easy to do with fprintf.
I'll say that logging is mostly for applications that have an extended
lifetime -- not ones that perform a specific task and exit. Compilers
fall into that latter category, so maybe you haven't had the experience of
how valuable logging can be. But you can still use them in such
applications. Think of how valuable it is to just re-run the compiler
with -v instead of recompiling the compiler with debug mode turned on.
Especially true if you don't control the system where the compiler is
running (gotta go build it, then copy it to the system, then run it, etc.)
-Steve
