On Monday, 14 October 2013 at 20:49:19 UTC, Robert Schadek wrote:
>
> I disagree on having a simple email layer among the default  logger,
> because I feel that having this "special" logger in would water  the
> design of the logging module. Maybe you are happy with a simple  string
> message mail with fixed subject and sender, the next guy will  not. And
> he will be asking for it and (we || I ) have to tell him, why  the simple
> one is in and his version is not. I would rather have a minimal
> std(io|err), file logger version which is pure and easy to mod.

Yes.  The really important thing about getting tools like this into the standard library is so libraries can build on the same framework that a user application is likely to use.  So now instead of hooking differently formatted callbacks into every D library I use so I can get log output, I can rely on them logging directly to the standard log device.

Different projects will have different specialized logger requirements, so trying to find a common back-end seems like a largely pointless effort anyway.  Though specialized loggers might be a good Dub project...

On 10/14/2013 09:59 PM, ponce wrote:
> Thanks for taking care of that.
> My logger class logs warning in yellow and errors in red ;),
colors are awesome I now, but hard to do across all shells and even worse when you want to pipe the messages in a file afterwards. So I suggest you implement your own custom logger. Btw. thanks for good example, that people have differend ideas of what a logger should do.
> but honestly I will take _anything_ since the lack of std.logger is a
> big problem right now for library writers.
> I cannot write a nice wrapper for a C library without forcing my pet
> logger implementation [that no one wants].
my motivation

On 10/14/2013 11:01 PM, Sean Kelly wrote:
> On Monday, 14 October 2013 at 20:49:19 UTC, Robert Schadek wrote:
>>
>> I disagree on having a simple email layer among the default  logger,
>> because I feel that having this "special" logger in would water  the
>> design of the logging module. Maybe you are happy with a simple  string
>> message mail with fixed subject and sender, the next guy will  not. And
>> he will be asking for it and (we || I ) have to tell him, why  the
>> simple
>> one is in and his version is not. I would rather have a minimal
>> std(io|err), file logger version which is pure and easy to mod.
>
> Yes.  The really important thing about getting tools like this into the standard library is so libraries can build on the same framework that a user application is likely to use.  So now instead of hooking differently formatted callbacks into every D library I use so I can get log output, I can rely on them logging directly to the standard log device.
>
> Different projects will have different specialized logger requirements, so trying to find a common back-end seems like a largely pointless effort anyway.  Though specialized loggers might be a good Dub project...
I think you got, at least, my point ;-)

The Dub part is a good at least from my perspective

On Monday, 14 October 2013 at 20:06:52 UTC, Jeremy Powers wrote:
> Take a look at the way log4j does it, with logger hierarchy:
> http://logging.apache.org/log4j/1.2/manual.html
>
> This is incredibly useful.

It is useful but it's also a pain to configure. I used logback ( http://logback.qos.ch/ ) which is a bit nicer but still... We should definitely step away from XML's configuration mess.

On 10/14/2013 07:01 PM, Jeremy Powers wrote:
> Some comments from the peanut gallery:
>
> * Mentioned already: configurable log output.  Configure style/contents of log output based on output location.  More options for included info (thread id, etc).  Allow custom info to be inserted based on logger context.
I don't think that this is a good way to good, complexity and speed wise.
>
> * Also mentioned: Configurable log rotation for file logger.
>
> * Pass an exception to logger directly, have it output in message depending on configuration.  Pretty vs. short vs. all-one-line for automated log parsing.
I think format("%s", someException) already calls toString on
someException (I need to this.)
>
> * Support multiple output locations.  Code calls log.whatever(), be able to have that spit out to various places (stdout, syslog, file, etc) depending on configuration. Be able to configure different logging levels for each output.
MultiLogger will come.
>
> * Should be able to change log levels via configuration, for debugging of existing code (during dev or production).  That is, be able to change each logger level without recompiling.
Debug Level are runtime only, You can disable all logging via a version switch
>
> * The 'critical' level seem extraneous - when would you use this instead of error or fatal?
The system has tripped bad. Maybe some config file is not there, but some system env might to the trick.
>
> * Easy way to create logger per module, inheriting settings from logger hierarchy.  Associated way to manage loggers and their configuration.
>
module myModule;
Logger myModuleLogger;
static this() {
    myModuleLogger = new StdIOLogger();
}
>
> Basically, things I've found useful after using log4j heavily.  Most of them seem fancy and extraneous, until you are dealing with long-running production software you have to fix at three in the morning...

On Monday, 14 October 2013 at 19:47:19 UTC, Jacob Carlborg wrote:
> On 2013-10-14 20:24, Robert Schadek wrote:
>
>> At least jmdavis had a very strong argument against it. Something like
>> function should be verbs ... Maybe something like logCritical, logInfo
>> would be a compromise, but I think everybody here has a different idea
>> of what is correct.
>
> If "log.info" is used it minimizes the module level functions.

If we need to care about that, D module system is a failure.
But I don't think it is a valid concern.

> It is useful but it's also a pain to configure. I used logback ( http://logback.qos.ch/ ) which is a bit nicer but still... We should definitely step away from XML's configuration mess.
>

Yeah, there's a reason I linked to the old docs and not the newer xml-centric stuff.  The important bit is to have a well-defined hierarchy of loggers, and be able to configure each level as needed.  Indispensable for any large software product.

Haven't actually used logback yet myself, but it provides a great set of functionality to shoot for.

On 10/14/2013 11:10 PM, Guillaume Chatelet wrote:
>
> It is useful but it's also a pain to configure. I used logback ( http://logback.qos.ch/ ) which is a bit nicer but still... We should definitely step away from XML's configuration mess.
Did somebody say XML, I first cast a stone. ;-) But seriously, XML does not come to my mind when I think a flexible KISS logging library.

On Monday, 14 October 2013 at 21:22:51 UTC, Robert Schadek wrote:
> module myModule;
> Logger myModuleLogger;
> static this() {
>     myModuleLogger = new StdIOLogger();
> }

I'd like to have module-specific logging _without_ creating local module instance. And without referring to specific logger at all. As I have mentioned, something like:
```
import log = std.logger;
log.local.info(...); // uses special default logger that inspects __MODULE__
log.global.error(...); // uses normal default logger

```

Comments on comments.  And to be clear, this is just me wanting everything to be amazing - I'm incredibly glad to have any logging framework at all, and will use what I can get.

 >> Allow custom info to be inserted based on logger context.
 > don't think that this is a good way to good, complexity and speed wise.

Configurable/custom logging output is required for (most) complicated
systems.  Aside from having to fit into a pre-existing log format, think
logging a request id for every action that happens within the context of a
request.  You can manually plum in the info everywhere and pass it to the
logger, but it is much easier/cleaner to be able to set info on a logger
context.  For some cases this is the only reasonable option.
Like: http://logback.qos.ch/manual/mdc.html

>> * Pass an exception to logger directly, have it output in message depending on configuration.  Pretty vs. short vs. all-one-line for automated log parsing.
> I think format("%s", someException) already calls toString on
someException (I need to this.)

I'm thinking of cases where the standard exception toString may not be
appropriate, like when you need every log statement to occur only on one
line for log parsing, perhaps with a shortened stack trace.  But still want
to be able to run the same code in development and be able to look at logs
without eyes bleeding.  It might be useful to include the API to take an
exception directly, even if it doesn't actually do anything special without
a custom logger implementation.
Like:
http://logback.qos.ch/apidocs/ch/qos/logback/classic/Logger.html#error(java.lang.String,
java.lang.Throwable)


> MultiLogger will come.

Excellent.
Obligatory logback link: http://logback.qos.ch/manual/appenders.html


>> * The 'critical' level seem extraneous - when would you use this instead
of error or fatal?
 > The system has tripped bad. Maybe some config file is not there, but
some system env might to the trick.

If you have encountered a problem, is an error.  If you can't recover, is a fatal.  I can't think of a time when I would want to use critical where an error or fatal wouldn't be appropriate... personally, I'd rather have an explicit debug/trace level instead.

>> * Easy way to create logger per module, inheriting settings from logger
hierarchy.
>> Associated way to manage loggers and their configuration.
>
>module myModule;
>Logger myModuleLogger;
>static this() {
>    myModuleLogger = new StdIOLogger();
>}

Yes, but.  Should be able to create a logger per module, and have it automatically fit into log hierarchy for configuration.  Example:

module foo -> has logger foolog
module foo.bar -> has looger barlog, child of foolog

Want to be able to configure log levels on foolog and have barlog inherit.
 Useful for turning on/off log levels for my code but not changing log
output from code I pull from elsewhere.  I'd say this is one of the most
critical parts of an effective logging framework.  Making it easy/default
gains a lot.
Like: http://logback.qos.ch/manual/architecture.html


Also:
I like log.error(foo) better than log(error, foo).  And the shed should be
blue.