February 14, 2012
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.

Thanks,
-Jose

> - Jonathan M Davis
February 14, 2012
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.

- Jonathan M Davis
February 14, 2012
On Mon, Feb 13, 2012 at 5:06 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> I'd like to see a simple example of how to specify the filename of the log file.

Fair enough...
February 14, 2012
On Mon, Feb 13, 2012 at 6:47 PM, Sean Kelly <sean@invisibleduck.org> wrote:
> On Feb 13, 2012, at 12:44 PM, jdrewsen 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.
>
>
> I think that's what vlog is for, it just isn't particularly well documented.

I agree. Let me know how I can improve this...
February 14, 2012
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?

> /Jonas
>
February 14, 2012
On Mon, Feb 13, 2012 at 7:17 PM, Sönke Ludwig <ludwig@informatik.uni-luebeck.de> 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.
>
No, no reason. I guess making the opCall an alias to format is better. That means the concatenate call will be:

log!info.write(...)

Not that great looking. Suggestions?

> 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.
>
Never used OutputDebugString. Do you mind sending a patch if std.log gets commit to phobos? Thanks.

> 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.
>
What I would really like is to eventually write a backend logger that sends the message to elasticsearch. That would make this usable in a data center environment. For that I first need to extend the LogMessage class.

> 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"...
>
FileLogger can write to a set of files and/or stderr.

> A format option to log the thread name instead of just the ID.
Good idea.
February 14, 2012
On Mon, Feb 13, 2012 at 9:12 PM, James Miller <james@aatch.net> wrote:
> On 14 February 2012 10:17, Sönke Ludwig <ludwig@informatik.uni-luebeck.de> 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.
>>
>> 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.
>
> I agree that there needs to be an easy to use format-based logger,
> even if its just logf template that calls format on the filter, since
> writing `log!(info).format("my string %s", s);` looks bad compared to
> `logf!info("my string %s", s);`
>
> Looking through the docs, there needs to be a better indication of configuration in the primary example, since you don't even mention it, I thought it might not exist.
>
At the top of the documentation I wanted information on how to use the module for the common developer. To me the common developer is going to write log message not configure the log module/framework.

The user that is going to configure the library can read the whole document or the Configuration classes.

Thoughts?

> A built-in console logger should probably be available, one that writes to stdout at the very least, since I often need log messages for debugging, other loggers can be build on top of the Logger interface, separate from the library, but I imagine that many people would want a console logger and doing it in the standard library will prevent too much repeated work. It would also be an idea to make it the default, but at this point I can't really separate out my practices from what I think most people do.
>
The default FileLogger can do this. See --logtostderr, --alsologtostderr and --stderrthreshold.

> A debug-level log would be nice, but I don't really care either way.
>
> A built-in MultiDispatchLogger (or similar) would be nice, but I don't
> think it really matters.
>
Yeah. We could use a few other loggers. But we should think of this as a living module. The most important thing I think is that we can make this future improvements without breaking existing users.

> Otherwise, I think it all looks good; fairly simple to use and configure, ability to override the defaults if needed, ability to swap out backends at runtime. The docs need work, but docs always need work :P.
>
> It might not mean much, but this gets my approval.
>
> James Miller
February 14, 2012
On Mon, Feb 13, 2012 at 9:37 PM, so <so@so.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".

I like it! I think I tried this before but I thought "compiled time" instantiation of the templates was not working properly with alias. Let me try it again and report back...
February 14, 2012
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.

> - Jonathan M Davis
February 14, 2012
On 2/13/12 8:28 PM, 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?

Let's not forget we could always do

  debug log(stuff);


Andrei