Using glog's design for Phobos?

[Steven Schveighoffer]

On Thu, 26 Aug 2010 21:34:43 -0400, Walter Bright  
<newshound2 at digitalmars.com> 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