Previous review thread : http://forum.dlang.org/post/zhvmkbahrqtgkptdlcvh@forum.dlang.org

Previous voting thread (also contains discussion in the end) : http://forum.dlang.org/post/vbotavcclttrgvzcjjia@forum.dlang.org

Code : https://github.com/D-Programming-Language/phobos/pull/1500

Important changes since last review:
- new approach for compile-time log level filtering
- thread-safe API (by Marco Leise, commits 3b32618..e71f317)
- documentation enhancements all over the place
- more @nogc annotations
- "raw" log overload that expects pre-formatted message and all metadata (file/line/function) as run-time function arguments

(anything I have missed Robert?)

Usual process : 2 weeks for checking out if there are any critical issues that are likely to prevent successful voting, write a comment if you need more time for review, focus on API issues.

On Sunday, 28 September 2014 at 12:24:23 UTC, Dicebot wrote:
> Previous review thread : http://forum.dlang.org/post/zhvmkbahrqtgkptdlcvh@forum.dlang.org
>
> Previous voting thread (also contains discussion in the end) : http://forum.dlang.org/post/vbotavcclttrgvzcjjia@forum.dlang.org
>
> Code : https://github.com/D-Programming-Language/phobos/pull/1500
>
> Important changes since last review:
> - new approach for compile-time log level filtering
> - thread-safe API (by Marco Leise, commits 3b32618..e71f317)
> - documentation enhancements all over the place
> - more @nogc annotations
> - "raw" log overload that expects pre-formatted message and all metadata (file/line/function) as run-time function arguments
>
> (anything I have missed Robert?)

I added more unittests, but unfortunately didn't find any bugs.
The "raw" log overload is actually a template function that has one template parameter, the value you want to log.

That's all, I think

This module is going to be the go-to logging in D.
Every other D logging library will extend on it, and libraries
will pass their messages through std.logger's `stdlog`.

It is very important that all of you who plan on using logging in D or know about specific logger implementations take their time and see if what they have in mind can be implemented on the API foundations that std.logger provides. Our community lacks a real logging guru and needs the collective experience.

If you don't have time to experiment, but believe that some use case must be covered just describe it in a few words. (Especially effects on API design, performance or threading.)

On Monday, 29 September 2014 at 10:30:21 UTC, Marco Leise wrote:
> If you don't have time to experiment, but believe that some
> use case must be covered just describe it in a few words.

Two things:

1. Timestamps with millisecond precision or better?

2. Creating one log file per day? I.e. built-in logrotate. If it's not built-in, would it be difficult to add on top?

The thread-safety changes in short: Every Logger is now taking a lock when a public method is invoked and then calls the user overridable methods with the lock taken.

* When you implement a new logger, thread-safety is already
  taken care of.
* Taking a lock in a single-threaded context is practically
  free compared to the actual logging. (So don't worry.)
* It is not possible to enter a Logger with multiple threads
  and provide more fine-grained thread synchronization. In
  particular only one thread at a time can call a global log
  function like `debug(...)` or `error(...)`.

Note: This is different from the original intention to have Loggers implement thread safety if they need it and a stopgap measure looking for use cases that need modifications.

--
Marco

On Monday, 29 September 2014 at 10:41:06 UTC, Vladimir Panteleev wrote:
> On Monday, 29 September 2014 at 10:30:21 UTC, Marco Leise wrote:
>> If you don't have time to experiment, but believe that some
>> use case must be covered just describe it in a few words.
>
> Two things:
>
> 1. Timestamps with millisecond precision or better?

You have all that is in Datetime.

> 2. Creating one log file per day? I.e. built-in logrotate. If it's not built-in, would it be difficult to add on top?

No, as said in the last review thread there are to many solution on different platforms. But you can build the one you need easily.

Am Mon, 29 Sep 2014 10:41:05 +0000
schrieb "Vladimir Panteleev" <vladimir@thecybershadow.net>:

> Two things:
> 
> 1. Timestamps with millisecond precision or better?
> 
> 2. Creating one log file per day? I.e. built-in logrotate. If it's not built-in, would it be difficult to add on top?

Basically your logger gets passed all the basic information (file, line, function, module, log level, Tid, timestamp as `SysTime` (up to hnsecs precision), message and the original logger). You decide how to handle it, whether you pass it on to another logger, open a file or keep it in memory.

-- 
Marco

On Monday, 29 September 2014 at 10:41:06 UTC, Vladimir Panteleev wrote:
> 2. Creating one log file per day? I.e. built-in logrotate. If it's not built-in, would it be difficult to add on top?

I see logger customization explained in top-level docs of https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d
Do you feel something needs to be added there?

On Sunday, 28 September 2014 at 12:24:23 UTC, Dicebot wrote:
> Previous review thread : http://forum.dlang.org/post/zhvmkbahrqtgkptdlcvh@forum.dlang.org
>
> Previous voting thread (also contains discussion in the end) : http://forum.dlang.org/post/vbotavcclttrgvzcjjia@forum.dlang.org
>
> Code : https://github.com/D-Programming-Language/phobos/pull/1500
>
> Important changes since last review:
> - new approach for compile-time log level filtering
> - thread-safe API (by Marco Leise, commits 3b32618..e71f317)
> - documentation enhancements all over the place
> - more @nogc annotations
> - "raw" log overload that expects pre-formatted message and all metadata (file/line/function) as run-time function arguments
>
> (anything I have missed Robert?)
>
> Usual process : 2 weeks for checking out if there are any critical issues that are likely to prevent successful voting, write a comment if you need more time for review, focus on API issues.

It has been mentioned in the comment already, but log4j like
approach seems better. Also, it is sad that output range are not
leveraged to format/sample/filter/select output of the logger.

On Sunday, 28 September 2014 at 12:24:23 UTC, Dicebot wrote:
> Previous review thread : http://forum.dlang.org/post/zhvmkbahrqtgkptdlcvh@forum.dlang.org
>
> Previous voting thread (also contains discussion in the end) : http://forum.dlang.org/post/vbotavcclttrgvzcjjia@forum.dlang.org
>
> Code : https://github.com/D-Programming-Language/phobos/pull/1500
>
> Important changes since last review:
> - new approach for compile-time log level filtering
> - thread-safe API (by Marco Leise, commits 3b32618..e71f317)
> - documentation enhancements all over the place
> - more @nogc annotations
> - "raw" log overload that expects pre-formatted message and all metadata (file/line/function) as run-time function arguments
>
> (anything I have missed Robert?)
>
> Usual process : 2 weeks for checking out if there are any critical issues that are likely to prevent successful voting, write a comment if you need more time for review, focus on API issues.

Upgraded my logger to 0.3.0. I like that I don't have to make them thread-safe myself.
I vote 'yes' again.