September 28, 2014 std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
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. |
September 28, 2014 Re: std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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
|
September 29, 2014 Re: std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | 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.) |
September 29, 2014 Re: std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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?
|
September 29, 2014 Re: std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | 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 |
September 29, 2014 Re: std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | 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. |
September 29, 2014 Re: std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | 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 |
September 29, 2014 Re: std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | 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? |
September 30, 2014 Re: std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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.
|
September 30, 2014 Re: std.experimental.logger formal review round 3 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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.
|
Copyright © 1999-2021 by the D Language Foundation