Add component support to Logger

[Nil Geisweiller]

As we're moving towards a more integrated and synergistic system, we really need to add some multi-component support in the logger.

I suggest a simple mechanism:

1. Derive a logger from the factory logger and specifying a certain
   component name [Note: derive is used in metaphorical sense, not necessarily a C++ sense]. This derived logger, when used would insert this component name between the log level and the log message. For instance, if the component name is ForwardChainer the following call of the derived logger fc_log
c++ fc_log.debug("%u rule to be searched", n_rules);
   would write in the log file
   [2016-01-22 13:59:32:832] [DEBUG] [ForwardChainer] 1 rules to be searched
2. Code some scripts to grep all the log messages pertaining to a certain component. Note that this script will have to account for multi-line messages, that may not contain any logger prefixes.

[Nil Geisweiller]

I guess the derived logger could also modify the log level just for that component and it's lifetime, using the factory log level as default. Likewise for most logger attributes I guess.

[Linas Vepštas]

I'd like to enable/disable logging at compile time, on a per-module basis.

By default, the logger should NOT print the timestamp.

Right now, the logging infrastructure is .. too hard to use. Its hard to figure out who logged what, or why. As a result, I never use it; using printf's is significantly easier than using the logger. Logging should be easy; the current logger is too difficult to use, and thus mostly just serves to get in the way.

Also: log files need to be cleaned up. Currently, they appear in various random directories, and mostly just eat up disk space. It reminds me of the old unix crash behavior: when some program crashed, it left some random core file in some random directory. After a while you would have hundreds of core files scattered through-out the file-system. Eventually, the kenel developers came to thier snses, and stopped writing core files by default.

Same with the logger: right now, I have hundreds of opencog.log files in all sorts of strange directories, and some of these are huge, hundreds of megabytes. I never ever look at them.

By default, we should disable the creation of log files entirely. Those people who use them can then turn them on. Otherwise, they serve no purpose.

[Nil Geisweiller]

I'd like to enable/disable logging at compile time, on a per-module basis.

Now you can (I mean at least with the forward chainer). Well, the logger
won't exactly be disabled at compile time but if you use the LAZY macros
when necessary it shouldn't create any significant overhead.

To enable that for each module we just need to use the per component
logging scheme that I've used for the forward chainer. It's not
difficult have a look at FCLogger.{h,cc}.

By default, the logger should NOT print the timestamp.

I tried 2 loggers, Python's logging module and C++ boost.log. By default
Python's logging doesn't print timestamps, but boost.log does.

In our case, I don't mind setting no timestamps by default, I agree that
we don't need them more often than we do.

What do others think?

Right now, the logging infrastructure is .. too hard to use. Its hard to
figure out who logged what, or why. As a result, I never use it; using

This PR fixes that.

printf's is significantly easier than using the logger. Logging should
be easy; the current logger is too difficult to use, and thus mostly
just serves to get in the way.

I don't think it's difficult to use. How would you make it simpler?

Also: log files need to be cleaned up. Currently, they appear in various
random directories, and mostly just eat up disk space. It reminds me of
the old unix crash behavior: when some program crashed, it left some
random core file in some random directory. After a while you would have
hundreds of core files scattered through-out the file-system.
Eventually, the kenel developers came to thier snses, and stopped
writing core files by default.

Same with the logger: right now, I have hundreds of opencog.log files in
all sorts of strange directories, and some of these are huge, hundreds
of megabytes. I never ever look at them.

By default, we should disable the creation of log files entirely. Those
people who use them can then turn them on. Otherwise, they serve no purpose.

No logging by default, I could go with that.

What do others think?

[Cassio Pennachin]

In our case, I don't mind setting no timestamps by default, I agree that we don't need them more often > than we do.

What do others think?

No logging by default, I could go with that.

I agree with both. Ideally changing either of these defaults as well as logging level would be just a config file change. If that's not possible, then the "Release" build profile should enable timestamps and some level of logging.

We should also try to log to a sane standard location, so in a production scenario it's easy to rotate logs and get rid of old ones, etc.