I just pushed a new version to dub and the PR.

Highlights:

* LogManager is gone. ( s/LogManager\.//g should fix all user code)
* The codegen was replaced by some format token strings
* log(lcf) and trace(cf) now present documentation
  * trace(cf) stands as an example for info, warning ... and so forth
* StdIOLogger is now thread safe
* StdIOLogger docu tells you that it is thread safe

I also updated the html documents so you don't have to read through the source, but you are of course welcome to do so.

Pros
----
The lighning talk about the std.logger proposal at DConf 2014 had a positive impact.
We were able to change the "Current D Use" entry of our company from
    "Uses D2 / Phobos, Tango (log, xml)"
to
    "Uses D2 / Phobos, Tango (xml)".
(We got rid of tango.util.log; we still rely on the fast tango.text.xml.)

Cons
----
1. I am not happy with the (reverse) hungarian-style naming

At least in the code of our company, logging a formatted string is the basic use case.
The function for the basic use case should not require a suffix letter.
The consistency argument, that 'infof' is like 'writef', does not fully apply:
neither 'infoln' nor 'infofln' make sense.
(In my opinion, "half consistent" is inconsistent.)

Currently, suffix 'c' is used for conditional logging.
But, how will future extensions like glog's LOG_EVERY_N or LOG_FIRST_N be named?
With suffix 'e'? Suffix 'f' is already assigned!
The suffix letter sequence seems to be the road to confusion.

I would prefer the explicit naming of the previous std.log proposal:
    log.when(condition)(...)
However, there is only a small advantage over
    if (condition) log(...)

2. No support for 24/7 (server) applications

In my opinion, I really need logging for applications that possibly run forever.
With the FileLogger, the file will grow forever.
That's why most other frameworks provide something like a RollingFileLogger or some "logrotate-aware" FileLogger.

By the way: Instead of what I really need, I get a NullLogger.
I have no clue, why I never ever missed such an oddity.

3. Implementation is hidden behind 'mixin' expressions

When I tried to look at the implementation, I found long sequences of lines like this:
    mixin(buildLogFunction(true, false, false, LogLevel.info));

Nowadays, this changed into:
    mixin(freeLog.format(
        "info", "info", "info", "info",
        "info", "info", "info", "info",
        "info", "info", "info", "info",
        "info", "info", "info", "info"));

This is much better, but I still think, it's a complicated solution for a simple problem.
And it would be a shame for D, if there is no simple solution.

Small stuff
-----------
4. FileLogger needs flush

It's annoying when the events that caused a crash have been logged, but they never have been written to the file.

5. Suspect use of '__gshared'

The FileLogger has a field
    private __gshared File file_;

In this case, "__gshared is equivalent to static".
This means that all FileLogger instances share the same file!

6. Bad naming of "StdIOLogger"

Like 'std.stdio.StdioException', the 'io' should be lower case.
If the 'StdIOLogger' logs to 'stdout', 'StdoutLogger' would be preferable.

7. No need for StdIOLogger

'stdout' (and 'stderr') are Files, so a FileLogger should be able to handle them.
A second constructor should do the trick.

8. Log levels

Many frameworks mix the types "log level" and "set of log levels" (for filtering).
While 'trace', ..., 'fatal' are log levels, 'all' and 'off' (better: 'none'?) are sets of log levels.
(I have no idea about the type of 'unspecific'.)

A clean separation would avoid confusion:
why is there 'info(...)' but not 'all(...)'?

Also, it would be easier to log for example 'trace' and 'info' to 'stdout'.

9. Bad naming of "std.logger"

The focus of this proposal is on the log/logging API; the loggers are only examples.

The recommended use should be
    import log = std.logger;

Then, the name "std.log" (of the previous proposal) would be more appropriate.

Counter Proposal
----------------
As a consequence of these issues, I once decided to spend a weekend to prepare a counter proposal:

http://code.dlang.org/packages/log

The design goal was simplicity. So:
- conditional logging is not supported
- no suffix letter sequences
- there is no NullLogger
- there is no MultiLogger (this functionality is implicit)
- there is no need to provide a name for a logger

I prefer 'alias' over 'mixin':
'info' is just an alias for 'log(arg)' as well as for 'log(fmt, args)' at log level 'info'.

Sets of log levels are implemented as (bit) sets of log levels.
A helper function lets you select the traditional >= filtering:
    LogLevel.info.orHigher

For convenience, 'stdoutLogger' and 'stderrLogger' are factory functions that create 'FileLogger' instances.

Of course, a RollingFileLogger as well a a "RotatingFileLogger" (that reopens the log file on SIGHUP) are provided.

By now, this simple solution is in use in tens of thousands lines of commercial code.
(Where it outperforms the previously used tango.util.log implementation.)

On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
> Pros
> ----
> The lighning talk about the std.logger proposal at DConf 2014 had a positive impact.
> We were able to change the "Current D Use" entry of our company from
>     "Uses D2 / Phobos, Tango (log, xml)"
> to
>     "Uses D2 / Phobos, Tango (xml)".
> (We got rid of tango.util.log; we still rely on the fast tango.text.xml.)

I didn't expect to hear from you about this, after you did not reply to my email about this topic.

If xml is problem for you, where is the PR?

>
> Cons
> ----
> 1. I am not happy with the (reverse) hungarian-style naming
>
> At least in the code of our company, logging a formatted string is the basic use case.
> The function for the basic use case should not require a suffix letter.
> The consistency argument, that 'infof' is like 'writef', does not fully apply:
> neither 'infoln' nor 'infofln' make sense.
> (In my opinion, "half consistent" is inconsistent.)

so we have gone full circle now ....

>
> Currently, suffix 'c' is used for conditional logging.
> But, how will future extensions like glog's LOG_EVERY_N or LOG_FIRST_N be named?

That's an easy one.

```
auto a = LOG_FIRST_N(1337);

logc(a, "Hello world");

auto b = WHAT_EVERY_THE(....);
logc(b, "Hello world again");
```

> With suffix 'e'? Suffix 'f' is already assigned!

what is 'e'?

> The suffix letter sequence seems to be the road to confusion.
>
> I would prefer the explicit naming of the previous std.log proposal:
>     log.when(condition)(...)
> However, there is only a small advantage over
>     if (condition) log(...)

...

>
> 2. No support for 24/7 (server) applications
>
> In my opinion, I really need logging for applications that possibly run forever.
> With the FileLogger, the file will grow forever.
> That's why most other frameworks provide something like a RollingFileLogger or some "logrotate-aware" FileLogger.
>
> By the way: Instead of what I really need, I get a NullLogger.
> I have no clue, why I never ever missed such an oddity.

That was a user request, through github. Where I asked you to submit PRs and issues.

Have you tried subclassing Logger? I asked for PRs in the email I wrote to you at least twice.

>
> 3. Implementation is hidden behind 'mixin' expressions
>
> When I tried to look at the implementation, I found long sequences of lines like this:
>     mixin(buildLogFunction(true, false, false, LogLevel.info));
>
> Nowadays, this changed into:
>     mixin(freeLog.format(
>         "info", "info", "info", "info",
>         "info", "info", "info", "info",
>         "info", "info", "info", "info",
>         "info", "info", "info", "info"));
>
> This is much better, but I still think, it's a complicated solution for a simple problem.
> And it would be a shame for D, if there is no simple solution.

Yes please, suggestions?

>
> Small stuff
> -----------
> 4. FileLogger needs flush
>
> It's annoying when the events that caused a crash have been logged, but they never have been written to the file.

I will fix that in the next session.

>
> 5. Suspect use of '__gshared'
>
> The FileLogger has a field
>     private __gshared File file_;
>
> In this case, "__gshared is equivalent to static".
> This means that all FileLogger instances share the same file!

I missed that, thank you

>
> 6. Bad naming of "StdIOLogger"
>
> Like 'std.stdio.StdioException', the 'io' should be lower case.
> If the 'StdIOLogger' logs to 'stdout', 'StdoutLogger' would be preferable.

easy fix

>
> 7. No need for StdIOLogger
>
> 'stdout' (and 'stderr') are Files, so a FileLogger should be able to handle them.
> A second constructor should do the trick.

It is a special file, I wanted to have that clear. two different classes does the trick for me.

>
> 8. Log levels
>
> Many frameworks mix the types "log level" and "set of log levels" (for filtering).
> While 'trace', ..., 'fatal' are log levels, 'all' and 'off' (better: 'none'?) are sets of log levels.
> (I have no idea about the type of 'unspecific'.)
>
> A clean separation would avoid confusion:
> why is there 'info(...)' but not 'all(...)'?

unspecific is about to be removed, all and off are pretty easy to understand but than ....

>
> Also, it would be easier to log for example 'trace' and 'info' to 'stdout'.

not if you want to have that logged somewhere else.

>
> 9. Bad naming of "std.logger"
>
> The focus of this proposal is on the log/logging API; the loggers are only examples.
>
> The recommended use should be
>     import log = std.logger;

you got that wrong, you can do it like that, nobody will force you and properly people will do it different.
You can also create a module wide global logger and use that

Again, std.logger is not the solution that works for every special case anybody comes up with out of the box. It is a set of ideas that enable you to have the logging tailored to your needs easily. On top of that, it allows you very fast access to basic logging that can be extend later on easily and seamlessly.

>
> Then, the name "std.log" (of the previous proposal) would be more appropriate.
>
> Counter Proposal
> ----------------
> As a consequence of these issues, I once decided to spend a weekend to prepare a counter proposal:
>
> http://code.dlang.org/packages/log
>
> The design goal was simplicity. So:
> - conditional logging is not supported
> - no suffix letter sequences

So you deleted code and functionality, hm?

> - there is no NullLogger

Same point

> - there is no MultiLogger (this functionality is implicit)

It is not, you can't remove Loggers individual and you can't build trees.

> - there is no need to provide a name for a logger

Because, you have no MultiLogger

>
> I prefer 'alias' over 'mixin':
> 'info' is just an alias for 'log(arg)' as well as for 'log(fmt, args)' at log level 'info'.
>
> Sets of log levels are implemented as (bit) sets of log levels.
> A helper function lets you select the traditional >= filtering:
>     LogLevel.info.orHigher

So I need nine LogLevels, how do I add one between info and warn?

>
> For convenience, 'stdoutLogger' and 'stderrLogger' are factory functions that create 'FileLogger' instances.

Object.factory

>
> Of course, a RollingFileLogger as well a a "RotatingFileLogger" (that reopens the log file on SIGHUP) are provided.

Subclassing Logger should get the job done in under 30 lines.

>
> By now, this simple solution is in use in tens of thousands lines of commercial code.
> (Where it outperforms the previously used tango.util.log implementation.)

So what are the numbers for std.logger and where is the benchmark file to test it?

From the source it looks like you kept parts of the design of std.logger and pulled out everything you didn't agree with. Also you only have global logging, to cite Brian: "Why?"

You added the parts, that you described are missing in std.logger. Of course your counter proposal will meet your needs then. I mean what would be the point of coding it up anyway else?

On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
> At least in the code of our company, logging a formatted string is the basic use case.
> The function for the basic use case should not require a suffix letter.

I'm in 100% disagreement. If you don't add the f suffix, users will write:

info(<user provided string that could contain format>);

This is a crash if the user provided string happens to contains "%s".
I wouldn't use such an API which makes format bugs hard to find.



> 2. No support for 24/7 (server) applications
>
> In my opinion, I really need logging for applications that possibly run forever.
> With the FileLogger, the file will grow forever.
> That's why most other frameworks provide something like a RollingFileLogger or some "logrotate-aware" FileLogger.

Do you realize rolling loggers are not there because they are supposed to be in another layer as subclasses of Logger?


> By the way: Instead of what I really need, I get a NullLogger.
> I have no clue, why I never ever missed such an oddity.

I asked for it. And I use it, because I write libraries that log warnings but don't forcefully require the users to provide a Logger if they don't want to.
And that way, I can still write "logger.warningf" without "if" everywhere.

>
> I'm in 100% disagreement. If you don't add the f suffix, users will write:
>
> info(<user provided string that could contain format>);
>
> This is a crash if the user provided string happens to contains "%s".
> I wouldn't use such an API which makes format bugs hard to find.
>

It does the right thing... there is an overload: without additional arguments, the first argument (not necessary a string) is not a format string.

>
>
>> 2. No support for 24/7 (server) applications
>>
>> In my opinion, I really need logging for applications that possibly run forever.
>> With the FileLogger, the file will grow forever.
>> That's why most other frameworks provide something like a RollingFileLogger or some "logrotate-aware" FileLogger.
>
> Do you realize rolling loggers are not there because they are supposed to be in another layer as subclasses of Logger?
>

Contrary to the NullLogger, writing a rolling logger is a non-trivial task.

>
>> By the way: Instead of what I really need, I get a NullLogger.
>> I have no clue, why I never ever missed such an oddity.
>
> I asked for it. And I use it, because I write libraries that log warnings but don't forcefully require the users to provide a Logger if they don't want to.
> And that way, I can still write "logger.warningf" without "if" everywhere.

On Tuesday, 22 July 2014 at 07:55:04 UTC, Dragos Carp wrote:

> Contrary to the NullLogger, writing a rolling logger is a non-trivial task.
>

It is an easy ten line function and one additional if.

On Tuesday, 22 July 2014 at 07:27:38 UTC, ponce wrote:
> On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
>> By the way: Instead of what I really need, I get a NullLogger.
>> I have no clue, why I never ever missed such an oddity.
>
> I asked for it. And I use it, because I write libraries that log warnings but don't forcefully require the users to provide a Logger if they don't want to.
> And that way, I can still write "logger.warningf" without "if" everywhere.

But then it's better to provide no logger (or at least no logger for level warning) than an artificial NullLogger.

On Tuesday, 22 July 2014 at 07:55:04 UTC, Dragos Carp wrote:
>>
>> I'm in 100% disagreement. If you don't add the f suffix, users will write:
>>
>> info(<user provided string that could contain format>);
>>
>> This is a crash if the user provided string happens to contains "%s".
>> I wouldn't use such an API which makes format bugs hard to find.
>>
>
> It does the right thing... there is an overload: without additional arguments, the first argument (not necessary a string) is not a format string.
>

Now if write a bug:
warning("there was an error because the file %s is missing!");

and I forgot the argument, no problem, it will run without errrors despite I made one. This is not an improvement over writef.

(this particular bug came up in DUB among others, and my last example was a real case too in production software where the users would call things with "%" in the names)

Two different operations conceptually => two names.

>>
>>
>>> 2. No support for 24/7 (server) applications
>>>
>>> In my opinion, I really need logging for applications that possibly run forever.
>>> With the FileLogger, the file will grow forever.
>>> That's why most other frameworks provide something like a RollingFileLogger or some "logrotate-aware" FileLogger.
>>
>> Do you realize rolling loggers are not there because they are supposed to be in another layer as subclasses of Logger?
>>
>
> Contrary to the NullLogger, writing a rolling logger is a non-trivial task.

NullLogger is there precisely because it's trivial and needed.
Of course a rolling logger is not that trivial, but std.logger is there to be orthogonal and a foundation not providing everything non-trivial.

On Tuesday, 22 July 2014 at 08:44:06 UTC, linkrope wrote:
> On Tuesday, 22 July 2014 at 07:27:38 UTC, ponce wrote:
>> On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
>>> By the way: Instead of what I really need, I get a NullLogger.
>>> I have no clue, why I never ever missed such an oddity.
>>
>> I asked for it. And I use it, because I write libraries that log warnings but don't forcefully require the users to provide a Logger if they don't want to.
>> And that way, I can still write "logger.warningf" without "if" everywhere.
>
> But then it's better to provide no logger (or at least no logger for level warning) than an artificial NullLogger.

My need is not "artificial", at least in my view.
Your opinion is different from mine. That's fine.
That's why we need someone to try to reconcile the many, many opinions about this.

On Tuesday, 22 July 2014 at 09:51:24 UTC, ponce wrote:
> On Tuesday, 22 July 2014 at 08:44:06 UTC, linkrope wrote:
>> On Tuesday, 22 July 2014 at 07:27:38 UTC, ponce wrote:
>>> On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
>>>> By the way: Instead of what I really need, I get a NullLogger.
>>>> I have no clue, why I never ever missed such an oddity.
>>>
>>> I asked for it. And I use it, because I write libraries that log warnings but don't forcefully require the users to provide a Logger if they don't want to.
>>> And that way, I can still write "logger.warningf" without "if" everywhere.
>>
>> But then it's better to provide no logger (or at least no logger for level warning) than an artificial NullLogger.
>
> My need is not "artificial", at least in my view.
> Your opinion is different from mine. That's fine.
> That's why we need someone to try to reconcile the many, many opinions about this.

Not the need is artificial. For example, I have the need to measure the performance of an application with and without logging.

I think, the solution is artificial. The obvious solution would be to register no logger at all.