October 14, 2013
On 10/14/2013 02:51 PM, Andrea Fontana wrote:
> Just for comparison, on Android you can write something like:
> FileLogger.w(...)  instead of FileLogger.log(LogLevel.Warning...)
>
> (and there's a "wtf" loglevel for "temporary" debugging)
>
hm, I don't really like it. To me it sounds like, "I'm don't care about log level just print this". Maybe changing the LogLevel type to an int like "debug(int) { " would be an idea and than providing some immutable int Info = 1, Debug = 256, Error = 1024 ...  would be a idea.
October 14, 2013
On 14.10.2013 15:18, Robert Schadek wrote:
> On 10/14/2013 02:32 PM, Martin Drasar wrote:
>> 1) MultiLogger class that takes references to other loggers and just forwards the call to the log function.
> will be done, see the reply to Sönke's post.

Cool

>> 2) Optional string parameter that describes the desired log output (i.e. format and position of timestamp, line, file, message, ...) for different needs, e.g. machine vs. human read log.
> I thought about that, but I'm not sure if that won't the logger to complex.  IMO it is better to have some reasonable hard-coded default than a log format parser. If the user needs something else, subclassing a logger and changing the format is a 7 liner. And this is the design Idea behind the logger.

True, it would definitely make the logger more complex. Default implementation would just help developers that want this feature avoid the pitfalls of string formatting (e.g. buffers vs. allocation as was discussed in previous thread on std.logger).

>> 2.1) Allow more than one string to be logged. For example I want to add component name, task identifier, etc., but I want to let correct formatting on the logger.
> logf("name %s, taskId %s", name, taskId); already works

This was tightly coupled with the previous request, i.e. not using string format and logging one string, but passing several strings and let the target logger assemble them as it see fit.

> Thanks, keep it coming

How about being able to log only certain log level(s) and not only
greater or equal?

Martin
October 14, 2013
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
> As `std.logger` is still marked as "work in progress" this thread is less formal that typical pre-voting review. Goal is to provide as much input about desirable `std.logger` functionality and current state and let module author to use this information for preparing proposal for actual review / voting.
>
> Lets unleash the forces of constructive destruction.
>
> ===== Meta =====
>
> Code: https://github.com/D-Programming-Language/phobos/pull/1500/files
> Docs: http://burner.github.io/phobos/phobos-prerelease/std_logger.html
>
> First announcement / discussion thread : http://forum.dlang.org/post/mailman.313.1377180809.1719.digitalmars-d@puremagic.com

** System logging: syslog and windows event logging support.
* log rolling, resuming
* sink - source logging
- buffered(speed, network logging anyone?) and unbuffered(crash safe) logging
- log configuration via environment or arguments
- log once/every Nth





October 14, 2013
On 10/14/2013 03:31 PM, Martin Drasar wrote:
> On 14.10.2013 15:18, Robert Schadek wrote:
>> On 10/14/2013 02:32 PM, Martin Drasar wrote:
>>> 1) MultiLogger class that takes references to other loggers and just forwards the call to the log function.
>> will be done, see the reply to Sönke's post.
> Cool
>
Cool
>>> 2) Optional string parameter that describes the desired log output (i.e. format and position of timestamp, line, file, message, ...) for different needs, e.g. machine vs. human read log.
>> I thought about that, but I'm not sure if that won't the logger to complex.  IMO it is better to have some reasonable hard-coded default than a log format parser. If the user needs something else, subclassing a logger and changing the format is a 7 liner. And this is the design Idea behind the logger.
> True, it would definitely make the logger more complex. Default implementation would just help developers that want this feature avoid the pitfalls of string formatting (e.g. buffers vs. allocation as was discussed in previous thread on std.logger).
Yes, but you have to lookup the formatting parameter, which adds some complexity. It would also a time complexity for each logging call, because you would have to parse the format. IMO KISS.
>>> 2.1) Allow more than one string to be logged. For example I want to add component name, task identifier, etc., but I want to let correct formatting on the logger.
>> logf("name %s, taskId %s", name, taskId); already works
> This was tightly coupled with the previous request, i.e. not using string format and logging one string, but passing several strings and let the target logger assemble them as it see fit.
This plays in my hands exactly, you have properly some idea of "see fit" and I can't anticipate this and properly can't create such a flexible configuration that makes it all see fit. So write you're own logger and handle all strings our own. Just ignore the printf style formatted string at the beginning or just call logf("", string1, string2, ...) and mix string1 and friend as you see fit ;-)
>
>> Thanks, keep it coming
> How about being able to log only certain log level(s) and not only
> greater or equal?
>
> Martin
Well, Bitmasked come to mind, but I really don't want to go C-Style and I think that defeats the purpose of having levels.
October 14, 2013
On 14.10.2013 15:43, Robert Schadek wrote:
> On 10/14/2013 03:31 PM, Martin Drasar wrote:
> Yes, but you have to lookup the formatting parameter, which adds some
> complexity. It would also a time complexity for each logging call,
> because you would have to parse the format. IMO KISS.

Ok, let's have it simple.

>> This was tightly coupled with the previous request, i.e. not using string format and logging one string, but passing several strings and let the target logger assemble them as it see fit.
> This plays in my hands exactly, you have properly some idea of "see fit" and I can't anticipate this and properly can't create such a flexible configuration that makes it all see fit. So write you're own logger and handle all strings our own. Just ignore the printf style formatted string at the beginning or just call logf("", string1, string2, ...) and mix string1 and friend as you see fit ;-)

Yup, you are right. I somehow overlooked that these logf functions are best suited for what I want.

>> How about being able to log only certain log level(s) and not only
>> greater or equal?
>>
>> Martin
> Well, Bitmasked come to mind, but I really don't want to go C-Style and I think that defeats the purpose of having levels.

I am not sure how that defeats the purpose, but one way to go around this is to have the logger log also the logLevel of each message and then grep for what you need. What do you say about adding this functionality?

Martin
October 14, 2013
Am 14.10.2013 15:12, schrieb Robert Schadek:
> On 10/14/2013 02:39 PM, Sönke Ludwig wrote:
>>  - The static methods in LogManager should be made global and the class
>>    be removed. It's not for objects so it shouldn't be a class.
> LogManager also stores the global log level. Sure I can make another static global function storing this log level, but I would like to keep them together as they belong together IMO.

The same could be said about the global "log" functions, which are tightly coupled to that state. I think this is already nicely grouped together by the logger module itself, since there is not much else in it.

Basically, I just wouldn't consider this style to be particularly idiomatic D code, but of course that's just personal perception/preference (there is also some precedence using "struct" instead of "class" in Druntime). However, if it ends up like this in the final version, it should get a "@disable this();" to prevent misuse.

>>  - For me this logger is completely worthless without any debug log
>>    levels. The last std.log entry had at least anonymous verbosity
>>    levels, but I'd prefer something like I did in vibe.d [1], where
>>    each level has a defined role. This should especially improve the
>>    situation when multiple libraries are involved.
> Logger.log(LogLevel.(d|D)ebug, "Your message");

That would be my idea. Having at least two (diagnostic output for the user and debug output for the developer), but better all four debug levels can be very useful, though.

>>  - Similarly, I've never felt the need for conditional logging, but
>>    without it being lazy evaluated what's the use for it, actually?
> The conditional logging part is totally transparent.

But is there a compelling use case? It's transparent, but still increases the size/complexity of the API, not much, but there should be a reason for that IMO.

>>  - I really think there should be shortcuts for the different log
>>    levels. Typing out "LogLevel.xxx" each time looks tedious for
>>    something that is used in so many places.
> One could argue that writting logger.logDebug("...") is more tedious
> than writing,
> logger.logLevel = LogLevel.xxx;
> logger.log("...");
> logger.log("...");
> ...
> 
> This has been argued in the last logger discussion to some extend and it looked to me like this is the mostly preferred version.

The last discussion resulted (if I remember right) in something like "log.info(...)". This would be fine, too, although I think just "logInfo" is slightly preferable due to its length and the principle of least surprise.

>>  - There should be some kind of MultiLogger so that multiple log
>>    destinations can be configured (e.g. console + file). Or, instead of
>>    a single default logger, there could be a list of loggers.
> there is one default logger. I will create a MultiLogger, good point. I'm currently sure how to store the multi logger (LL or Array or ... )

I'd say a dynamic array is fine because the list of loggers will rarely change and this would be most efficient for iteration.

>>  - On the same topic, if I'm right and the default logger is stored as
>>    __gshared, it should be documented that Loggers need to be
>>    thread-safe.
> It is not stored __gshared, but If, you're right.

So the defaultLogger is per-thread? That may result in unexpected log output if you just do simple code like "spawn({ log("Hello, World!"); });" and have a custom logger set up during application initialization. Anyway, let's just say the threading behavior in general should be clearly documented here as this is critical for both log users and Logger implementors.

>>  - GC allocations for each log message _must_ be avoided at all costs.
>>    Using formattedWrite() instead of format() on either a temporary
>>    buffer that is reused, or, better, on some kind of output range
>>    interface of the Logger would solve this.
> This was proposed in the last thread. A fixed size buffer would scream bufferoverflow, a dynamic buffer not but both would raise the question of thread safety.

Something like a thread local buffer that grows when needed, or small fixed buffer + a scoped heap allocation for large messages should be fine. Using an output range interface could of course avoid buffering each message altogether. That would just open up the question of a nice API design for such.

One last thing just occurred to me, in the default logger in vibe.d I've made it so (thanks to Jordi Sayol for requesting this) that the "info" level gets output to stdout and all other levels to stderr. Either that or always outputting to stderr would be conforming to the idea of stdout/stderr and would avoid that some library with logging calls interferes with the output of an application (when piping process output in a shell script).

Thanks for bringing this forward!
October 14, 2013
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
> As `std.logger` is still marked as "work in progress" this thread is less formal that typical pre-voting review. Goal is to provide as much input about desirable `std.logger` functionality and current state and let module author to use this information for preparing proposal for actual review / voting.
>

Add e-mail logger (useful for critical errors) for example via `std.net.curl.SMTP`.
October 14, 2013
On Monday, 14 October 2013 at 13:39:10 UTC, Byron wrote:
> ** System logging: syslog and windows event logging support.

+1, add System logging, and use as default windows event logging for windows and syslog for POSIX.

And remote log support for syslog to allow send log messages via network.

Also, we should support syslog for windows, but in that case user must provide valid syslog daemon (install it for windows or spesify valid network connection).
October 14, 2013
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.

* 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.

* 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.

* 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.

* The 'critical' level seem extraneous - when would you use this instead of error or fatal?

* Easy way to create logger per module, inheriting settings from logger hierarchy.  Associated way to manage loggers and their configuration.


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 Mon, Oct 14, 2013 at 9:02 AM, ilya-stromberg < ilya-stromberg-2009@yandex.ru> wrote:

> On Monday, 14 October 2013 at 13:39:10 UTC, Byron wrote:
>
>> ** System logging: syslog and windows event logging support.
>>
>
> +1, add System logging, and use as default windows event logging for windows and syslog for POSIX.
>
> And remote log support for syslog to allow send log messages via network.
>
> Also, we should support syslog for windows, but in that case user must provide valid syslog daemon (install it for windows or spesify valid network connection).
>


October 14, 2013
Also:

* Asynchronous logging.  Log something and continue, not blocking on actual message getting written.  Can write a custom logger that works this way, but would be nice if this was supported at the base level.


On Mon, Oct 14, 2013 at 10:01 AM, Jeremy Powers <jpowers@wyrdtech.com>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.
>
> * 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.
>
> * 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.
>
> * 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.
>
> * The 'critical' level seem extraneous - when would you use this instead of error or fatal?
>
> * Easy way to create logger per module, inheriting settings from logger hierarchy.  Associated way to manage loggers and their configuration.
>
>
> 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 Mon, Oct 14, 2013 at 9:02 AM, ilya-stromberg < ilya-stromberg-2009@yandex.ru> wrote:
>
>> On Monday, 14 October 2013 at 13:39:10 UTC, Byron wrote:
>>
>>> ** System logging: syslog and windows event logging support.
>>>
>>
>> +1, add System logging, and use as default windows event logging for windows and syslog for POSIX.
>>
>> And remote log support for syslog to allow send log messages via network.
>>
>> Also, we should support syslog for windows, but in that case user must provide valid syslog daemon (install it for windows or spesify valid network connection).
>>
>
>