February 14, 2012
On Tuesday, February 14, 2012 01:16:29 Jose Armando Garcia wrote:
> On Tue, Feb 14, 2012 at 12:02 AM, Jonathan M Davis <jmdavisProg@gmx.com>
wrote:
> > On Monday, February 13, 2012 23:58:38 Jose Armando Garcia wrote:
> >> On Mon, Feb 13, 2012 at 4:19 PM, Jonathan M Davis <jmdavisProg@gmx.com>
> > 
> > wrote:
> >> > On Monday, February 13, 2012 17:49:49 David Nadlinger wrote:
> >> >> You define the Severity enum members starting with fatal as 0. Why not the other way round – so that severityA < severityB would do what you (or at least I) would expect?
> >> > 
> >> > syslog defines 0 (LOG_EMERG) as the strongest and 7 (LOG_DEBUG) as the weakest. The greater the number, the more logging output, you're going to see. So, he's following syslog in that respect, though he doesn't have as many log levels. He should probably add at least debug. He also aliases them to module-level symbols for some reason, which is a big no-no IMHO.
> >> 
> >> I am trying to minimize the number of predefined log levels. One of the big problems I see with having too many log levels is that the programmer never knows which one to use. I think std.log makes this very clear:
> >> 
> >> 1. Log at fatal if you want the application to assert
> >> 2. Log at critical if you want the thread to throw
> >> 3. Log at error if you detect a programming bug (invariant violation)
> >> but you wish to continue and cross your finger
> >> 4. Log at warning if you detected peculiar condition yet the program
> >> was coded to handle it.
> >> 5. Log at info if you want to document an action/state.
> >> 6. verbose log for trace/debugging specific parts of a program.
> >> 
> >> I think it would help me that instead of suggesting another level we instead state what we think the user would like to do or log but the framework as defined doesn't let the user do.
> > 
> > Personally, I'd just copy what syslog does in terms of log levels. Then std.log can use syslog and everything maps wonderfully.
> 
> Do you think that our users will really want to send "debug" message to syslog? Either way I don't think that is a reason to add debug level. If we used the common denominator to determine the set of features  that set would be quite large. The implementation of the Logger interface can do its best to map the severity from std.log to something syslog likes.
> 
> This is exactly what SLF4J does with Log4J, java.util.logger, syslog, etc.

Where I work, we log debug messages to syslog all the time when the product is under development. It's incredibly useful. And on Linux, syslog is _the_ logging facility. It's where all log messages should go. Then syslog can be configured to split up log files per program or log level or whatever else you want to do on that particular system. But regardless, all logging goes to syslog. That's what it's for.

- Jonathan M Davis
February 14, 2012
On 2/13/12 9:50 AM, David Nadlinger wrote:
> Please post all feedback in this thread, and remember: Although
> comprehensive reviews are obviously appreciated, short comments are very
> welcome as well!

Thanks Jose and David. I made a pass, here are a few thoughts:

* "different verbose level" -> "different verbosity levels"

* "functionality to disabled and enabled" -> "functionality to disable and enable"

* "enviroment variables, and their meaning see" -> "enviroment variables and their meaning, see"

* In code example: "Every nine" -> "Write every 9 passes"

* In code example: unbraced try statement is odd. We should use our own conventions in examples.

* In code example: plant an assert(false, "Never reached") after log!fatal.

* first() and every() are quite useful. I'm thinking of complementing them with after(). "Once" is first(1).

* "Descripton of the supported severities." -> "Description of supported severities." (notice the typo too)

* vlog should take uint, not int.

* When passing multiple parameters to log, they must be stringized automatically. So

log!error("Log an ", to!string(Severity.error), " message!");

becomes

log!error("Log an ", Severity.error, " message!");

* The examples right inside LogFilter don't mention it at all. I assume log!xyz has type LogFilter or something. That must be stated in writing.

* log!info.when(first())("Only log this the first time in the loop") should really be log!info.when(first())("Only log this one time per application run").

* No examples include durations.

* There might be a better name for Rich.

* assert(value == true); => assert(value);


Andrei
February 14, 2012
On 2012-02-13 22:17, Sönke Ludwig wrote:
> Log levels "debug" and maybe also "trace" would be useful, but I see
> that vlog(n)() is meant for that purpose. I would just prefer explicit
> names instead of just numbers.
>
> Is there a compelling reason why formatted logging is not the default? I
> find that most logging calls in practice use formatted output, and the
> only overhead would be searching once through the format string in the
> case of format placeholders.
>
> A predefined logger for OutputDebugString on Windows would be useful -
> or maybe it could be used instead of stdout at least for non-console
> applications.
>
> One kind of log writer that I have in my code is one that outputs a
> nicely formatted HTML file with built-in JavaScript to be able to filter
> messages by priority or module. Maybe this is too much for a standard
> library implementation though.

It would be nice to be able to plug in different formatters.

> Support for multiple log writers can be useful (e.g. logging to a file +
> logging to stdout or to a log control inside of the running
> application). Of course, one can also simply write a
> "MultiDispatchLogger"...
>
> A format option to log the thread name instead of just the ID.


-- 
/Jacob Carlborg
February 14, 2012
On 2012-02-14 00:37, so wrote:
> On Monday, 13 February 2012 at 15:50:05 UTC, David Nadlinger wrote:
>> There are several modules in the review queue right now, and to get
>> things going, I have volunteered to manage the review of Jose's
>> std.log proposal. Barring any objections, the review period starts now
>> and ends in three weeks, on March 6th, followed by a week of voting.
>>
>> ---
>> Code:
>> https://github.com/jsancio/phobos/commit/d114420e0791c704f6899d81a0293cbd3cc8e6f5
>>
>> Docs: http://jsancio.github.com/phobos/phobos/std_log.html
>>
>> Known remaining issues:
>> - Proof-reading of the docs is required.
>> - Not yet fully tested on Windows.
>>
>> Depends on:
>> https://github.com/D-Programming-Language/druntime/pull/141 (will be
>> part of 2.058)
>> ---
>>
>> Earlier drafts of this library were discussed last year, just search
>> the NG and ML archives for "std.log".
>>
>> I think getting this right is vitally important so that we can avoid
>> an abundance of partly incompatible logging libraries like in Java.
>> Thus, I'd warmly encourage everyone to actively try out the module or
>> compare it with any logging solution you might already be using in
>> your project.
>>
>> Please post all feedback in this thread, and remember: Although
>> comprehensive reviews are obviously appreciated, short comments are
>> very welcome as well!
>>
>> David
>
> Good work.
>
> One suggestion. Instantiating a template for each log rather verbose for
> such common thing. I suggest:
>
> (Just to demonstrate)
> alias global_logger!sev_info info;
> alias global_logger!sev_warning warning;
> alias global_logger!sev_error error;
> alias global_logger!sev_critical critical;
> alias global_logger!sev_dfatal dfatal;
> alias global_logger!sev_fatal fatal;
>
> As we are pulling severity levels to global namespace anyway, this will
> save us some verbosity and the keyword "log".

It would then be possible to use renamed imports to have something like this:

import log = std.log;

log.info("foo");

Which looks quite nice I think.

-- 
/Jacob Carlborg
February 14, 2012
Am Mon, 13 Feb 2012 19:22:54 -0800
schrieb Jonathan M Davis <jmdavisProg@gmx.com>:
> Where I work, we log debug messages to syslog all the time when the product is under development. It's incredibly useful. And on Linux, syslog is _the_ logging facility.

Right now. But once systemd took over the world: https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs&pli=1


February 14, 2012
On Tuesday, 14 February 2012 at 02:28:11 UTC, Jose Armando Garcia wrote:
> On Mon, Feb 13, 2012 at 6:44 PM, jdrewsen <jdrewsen@nospam.com> wrote:
>> A first quick observation:
>>
>> I vote for a debug severity level. Then make that default to the template
>> parameter for log:
>>
>> template log(Severity severity = Severity.debug)
>>
>> That would make it nice for good old print debugging.
>>
>> log("This is a dbg message");
>>
>
> I like the idea of having a default. Not sure about adding debug. What
> are you trying to do with default that log!info and vlog(#) doesn't
> let you do?

As Sean mentioned the vlog function may be the one I want. Maybe it is okey not to have a debug severity but then a default on the vlog level parameter would be nice. That would make quick debug prints a tad simpler

vlog("This is a dbg message");

I know this is a small thing... but to prevent death by a 1000 cuts.

/Jonas



February 14, 2012
On Monday, 13 February 2012 at 15:50:05 UTC, David Nadlinger wrote:
> There are several modules in the review queue right now, and to get things going, I have volunteered to manage the review of Jose's std.log proposal. Barring any objections, the review period starts now and ends in three weeks, on March 6th, followed by a week of voting.
>
> ---
> Code: https://github.com/jsancio/phobos/commit/d114420e0791c704f6899d81a0293cbd3cc8e6f5
> Docs: http://jsancio.github.com/phobos/phobos/std_log.html
>
> Known remaining issues:
> - Proof-reading of the docs is required.
> - Not yet fully tested on Windows.
>
> Depends on: https://github.com/D-Programming-Language/druntime/pull/141 (will be part of 2.058)
> ---
>
> Earlier drafts of this library were discussed last year, just search the NG and ML archives for "std.log".
>
> I think getting this right is vitally important so that we can avoid an abundance of partly incompatible logging libraries like in Java. Thus, I'd warmly encourage everyone to actively try out the module or compare it with any logging solution you might already be using in your project.
>
> Please post all feedback in this thread, and remember: Although comprehensive reviews are obviously appreciated, short comments are very welcome as well!
>
> David

Updated wiki: http://prowiki.org/wiki4d/wiki.cgi?ReviewQueue

/Jonas
February 14, 2012
On 2012-02-13 16:50, David Nadlinger wrote:
> There are several modules in the review queue right now, and to get
> things going, I have volunteered to manage the review of Jose's std.log
> proposal. Barring any objections, the review period starts now and ends
> in three weeks, on March 6th, followed by a week of voting.
>
> ---
> Code:
> https://github.com/jsancio/phobos/commit/d114420e0791c704f6899d81a0293cbd3cc8e6f5
>
> Docs: http://jsancio.github.com/phobos/phobos/std_log.html
>
> Known remaining issues:
> - Proof-reading of the docs is required.
> - Not yet fully tested on Windows.
>
> Depends on: https://github.com/D-Programming-Language/druntime/pull/141
> (will be part of 2.058)
> ---
>
> Earlier drafts of this library were discussed last year, just search the
> NG and ML archives for "std.log".
>
> I think getting this right is vitally important so that we can avoid an
> abundance of partly incompatible logging libraries like in Java. Thus,
> I'd warmly encourage everyone to actively try out the module or compare
> it with any logging solution you might already be using in your project.
>
> Please post all feedback in this thread, and remember: Although
> comprehensive reviews are obviously appreciated, short comments are very
> welcome as well!
>
> David

Is it possible to log to other locations, i.e. to the standard location for the given platform.

-- 
/Jacob Carlborg
February 14, 2012
On 2/14/12 2:14 PM, Jacob Carlborg wrote:
> Is it possible to log to other locations, i.e. to the standard location
> for the given platform.

While the current proposal only includes a file backend, my understanding is that this could easily be added by providing an appropriate implementation of the Logger interface. Generally useful implementations (e.g. syslog, …) would probably be a good candidate for inclusion into Phobos.

David
February 14, 2012
On 2012-02-14 14:24, David Nadlinger wrote:
> On 2/14/12 2:14 PM, Jacob Carlborg wrote:
>> Is it possible to log to other locations, i.e. to the standard location
>> for the given platform.
>
> While the current proposal only includes a file backend, my
> understanding is that this could easily be added by providing an
> appropriate implementation of the Logger interface. Generally useful
> implementations (e.g. syslog, …) would probably be a good candidate for
> inclusion into Phobos.
>
> David

Ok, I see. I don't think it would be necessary with different backends, as long as there's an interface available, at least not at the first stage.

-- 
/Jacob Carlborg