On 2011-05-16 01:27, Jonathan M Davis wrote:
On 2011-05-15 16:01, Andrei Alexandrescu wrote:
On 05/15/2011 10:26 AM, Jacob Carlborg wrote:
On 2011-05-15 00:33, Andrei Alexandrescu wrote:
On 05/14/2011 05:17 PM, Jonathan M Davis wrote:
On 2011-05-14 14:56, Michel Fortin wrote:
On 2011-05-14 17:31:30 -0400, Jonathan M Davis<jmdavisp...@gmx.com>
said:
So, I do think that knowing which thread is logging what could be
very important for some programs, but I don't think that separating
the log files is necessarily a good idea. If you did, you'd lose
timing information (unless the time is at the beginning of every log
line (which could also be useful), but then you'd have to read the
times and
compare them to see what happened before what). So, I'd be all for
some
options and extra information which could be added to each log line
which would help debugging, but I don't think that thread-local
logs is
a great idea.
I'd even go further and question whether it makes sense to have info,
warning, and errors be written to separate files.
I'd definitely vote for them all to be in the same file, but I don't
generally
see much benefit in having multiple log files. I like having them all
in one
place where you can see what happened in what order. Having them in
separate
log files is just going to make it harder to figure out what happened,
and I
think that it would become tempting (for me at least) to just log
everything
at exactly the same level so that they ended up in the same file.
The info log contains log messages for all levels.
Generally I'd want to stray from glog's major design decision as little
as possible. It's an approach validated by years of experience in
heavy-duty applications. Also, people coming from glog and used to its
features would find it unpleasant that we decided to do things a
different way without solid reasons.
Andrei
Why not? It doesn't say anywhere in the documentation, as far as I can
see, that it's based on glog.
That's beside the point as the documentation could and should be
changed. I've said repeatedly it's based on glog, and I think it's a
good thing.
I think that, in general, that is a poor
argument: "Because library A does it like that we also have to do it
like that". What about all people coming from library B, C, D and so on,
it will be unpleasant for those as well because we didn't follow their
particular library design.
It's a good argument if library A is considered better by the person
making the argument than B, C, and D. One thing is that glog has most
desirable qualities I am looking for in a logging library: allows
compile-time and run-time enabling/disabling, it's relatively small,
it's simple, it's effective, and is widely used. I'm sure there are
other libraries that score better on either dimension, but not on all.
There are two departures I chose to make from glog: (a) I added the
critical log which throws an exceptions (Google wouldn't need one
because they don't use exceptions), and (b) I replaced the clunky
LOG_IF_EVERY_N etc. with the flexible when(), every(), after() etc. I
think these are well justified choices.
I think that it makes good sense to start with an API based on an existing API
which is known and heavily used and then adjust it as appropriate to our
needs. In doing so, we might as well leave it the same as the original where
we don't need to change it, since there is some gain for those familiar with
the original. However, the real question then is where it does and doesn't
make sense to change it. If enough people agree with Andrei on those
decisions, then it will likely become std.log. However, if there's enough
disagreement, and we can't reach an appropriate compromise on such changes,
then it likely won't become std.log.
Hopefully we can come a solid design based on glog with whatever changes we
actually need without having to drastically change what it does in comparison
to glog. That would be ideal. However, I also think that if it really looks
like the general consensus is against something about how glog does things, we
shouldn't be married to how glog works. So, overall, I agree with Andrei. The
devil is the details, however.
- Jonathan M Davis
I agree with Jonathan, if glog is good enough we can follow its design
but if it isn't, we shouldn't hesitate to make some design changes.
The approach I take when designing an API for a library I'm writing I
look at the API of several other libraries that does the same thing.
Then I try to take the best parts and the parts I like of each library
and combine them into something that make sense.
--
/Jacob Carlborg
