> I think this is way too many levels. Why not just define few levels (around three) and let the user define new levels when needed.

I agree this is too many level, though I think letting the user define their own levels is a needless complication.
>From experience, I would recommend:
 - CRIT - the application cannot continue
 - ERROR - the application cannot carry out the requested task
 - WARN - the requested task cannot be completed normally, but we can
work around it
 - INFO - FYI. Things sysadmins would like to know.
 - DEBUG - For developers debugging.
 - TRACE (maybe) - also sometimes called fine or verbose - for
developers debugging.

If an application needs separate channels of logging, I would using a separate logger instance for different logging categories.

On Thu, Feb 16, 2012 at 06:49:41PM -0700, Jonathan Stephens wrote:
> > I think this is way too many levels. Why not just define few levels (around three) and let the user define new levels when needed.
> 
> I agree this is too many level, though I think letting the user define their own levels is a needless complication.
> >From experience, I would recommend:
>  - CRIT - the application cannot continue
>  - ERROR - the application cannot carry out the requested task
>  - WARN - the requested task cannot be completed normally, but we can
> work around it
>  - INFO - FYI. Things sysadmins would like to know.
>  - DEBUG - For developers debugging.
>  - TRACE (maybe) - also sometimes called fine or verbose - for
> developers debugging.
[...]

>From my experience, such a proliferation of log levels is rarely used
correctly. Most people, sadly to say, can't be bothered to read the definitions of what each level is supposed to be, and will just copy-n-paste the first instance they find. Of course, copying CRIT or ERROR will quickly get a high-priority bug filed against it, but besides CRIT and ERROR, the rest of the levels are rarely used properly.

I've seen people use WARN just because they think it's appropriate for "warning" the developer that a certain condition has happened that might trigger the bug they're hunting for. Then afterwards they forget to turn that off, and the log fills up with irrelevant messages.

Similarly, INFO tends to be interpreted as "garbage dump for anything I might want to know while writing this code, who cares what happens to those messages afterwards". DEBUG and TRACE are rarely ever used after 4 or 5 developers have had their hands on it, because turning those on will usually flood the logs with reams and reams of irrelevant messages from unrelated modules, so most people would stop using it after the first time.

Bottomline: reduce the number of channels, and let the programmer define their own channels if they need to. Module-specific channels are the best, so that you don't get reams of messages from completely unrelated code. But only the user knows what modules they have, so let them make that decision.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

Am 17.02.2012 02:49, schrieb Jonathan Stephens:
>> I think this is way too many levels. Why not just define few levels (around three) and let the user define new levels when needed.
>
> I agree this is too many level, though I think letting the user define
> their own levels is a needless complication.
>> From experience, I would recommend:
>   - CRIT - the application cannot continue
>   - ERROR - the application cannot carry out the requested task
>   - WARN - the requested task cannot be completed normally, but we can
> work around it
>   - INFO - FYI. Things sysadmins would like to know.
>   - DEBUG - For developers debugging.
>   - TRACE (maybe) - also sometimes called fine or verbose - for
> developers debugging.
>

Thats also exactly my experience (and what I use).

On Thu, Feb 16, 2012 at 7:21 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Monday, February 13, 2012 16:50:04 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!
>
> Why does vlog even exist? It's a needless complication IMHO. Let the log levels manage what does and doesn't get logged. I see no reason to add the concept of verbosity on top of that. It's a needless complication.
>

Needless? Man, you really make some "strange" comments. I believe that this is better served by you asking for the motivation for vlog instead of make a useless comment like the one above. The reason why vlog exist is to provide users with the ability to enable/disable logging at a package or module level. Lets say that for a particular load you are seeing that module X is not behaving correctly. The next time you run your application (or you can do this at runtime if you have coded your application correctly) you can enable verbose logging in this module by using the --v and --vmodule command line options. I have tried to explain this in the properties Configuration.maxVerboseLevel and Configuration.verboseFilter. Let me know if it still no clear and if I should expand the documentation.

> Also, _please_ add a debug level. Personally, I'd argue for simply copying syslog's levels and matching them, since ideally any logging on Linux would be going to syslog anyway. But there are good reasons to have messages beyond info. I sure wouldn't want _all_ messages which don't indicate a problem in the app to be marked as info. For instance, what if I want to have info displayed in release mode but want greater verbosity in debug mode?

debug info("More information in debug mode");

I think it is very helpful that instead of just suggestion more level we try to see how we can use this module and the power of D to do what you want. If we find that it is not possible or clunky then we can talk about adding more functionality.

> I'd need
> another log level which isn't there. Using the concept of verbosity to try and
> handle this is a needless complication. syslog has
>
> #define LOG_EMERG       0       /* system is unusable */
> #define LOG_ALERT       1       /* action must be taken immediately */
> #define LOG_CRIT        2       /* critical conditions */
> #define LOG_ERR         3       /* error conditions */
> #define LOG_WARNING     4       /* warning conditions */
> #define LOG_NOTICE      5       /* normal but significant condition */
> #define LOG_INFO        6       /* informational */
> #define LOG_DEBUG       7       /* debug-level messages */
>
> And I'd like to at least see notice and debug added.
>
> While we're at it, what's the point of dfatal? Why on earth would a _fatal_ condition not be fatal if it were in release mode if it were fatal in debug mode? Is it fatal or not? It seems to me like another needless complication.
>

Barely a complication. dfatal looks as follow:

debug alias log!(Severity.fatal) dfatal; /// ditto
else alias log!(Severity.critical) dfatal; /// ditto

> If you're going to have write, then have writef, not format. Then it's actually consistent with our normal I/O functions.

Good suggestion. Will do.

> Also, do writef and format
> automatically append a newline? If so, then they should be writeln and
> writefln.
>

Technically, no. The module was abstracted with a frontend and a backend. At a very high-level the front does filtering based on compile time and run time configuration options. The backend is basically responsible for persisting messages. It just happens that the only backend implementation that we have writes to a human consumable file hence the newline but it is possible that users are going to want to store this data in persistent storage where each logging event is not separated by a newline.

> Rich is a horrible name IMHO. It says nothing about what it actually is or does. I'm not sure what a good name would be (BoolMessage?, LogResult?), but Rich by itself is very confusing and utterly uninformative.
>
Yeah. I don't like Rich. Let me think about a better name. Thanks for the suggestions!

> And why does Configuration's logger property throw if you set it after a logging call has been made. Is it really that inconceivable that someone would swap out loggers at runtime? Or is the idea that you'd swap out the Configuration?
>
The idea is not to swap out the Configuration but to instead be able to reset each property. There is no technical reason why you can't replace the Logger. I just didn't think this is something the users would want to do in practice. Again this goes beyond technical reason is more of the operational consequence if you allow this. For example:

1. You started logging to /tmp/application/...log...
2. You swapped the logger at runtime to start logging to syslog

You have a bunch of important data in /tmp/application/...log... what are you going to do with it? Think of this like a stream flowing into a lake and at some point you want to route the stream to the ocean. What is the state of the lake after the routing change?

I would also like to add that this is a restriction that we can remove in the future. I am honestly a little hesitant to remove it now without giving it a little bit of more thought. Thoughts?

Thanks!
-Jose

> - Jonathan M Davis

On Thu, Feb 16, 2012 at 7:57 AM, Sönke Ludwig <ludwig@informatik.uni-luebeck.de> wrote:
> Am 16.02.2012 10:21, schrieb Jonathan M Davis:
>>
>> On Monday, February 13, 2012 16:50:04 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!
>>
>>
>> Why does vlog even exist? It's a needless complication IMHO. Let the log levels manage what does and doesn't get logged. I see no reason to add the concept of verbosity on top of that. It's a needless complication.
>>
>> Also, _please_ add a debug level. Personally, I'd argue for simply copying
>> syslog's levels and matching them, since ideally any logging on Linux
>> would be
>> going to syslog anyway. But there are good reasons to have messages beyond
>> info. I sure wouldn't want _all_ messages which don't indicate a problem
>> in
>> the app to be marked as info. For instance, what if I want to have info
>> displayed in release mode but want greater verbosity in debug mode? I'd
>> need
>> another log level which isn't there. Using the concept of verbosity to try
>> and
>> handle this is a needless complication. syslog has
>>
>> #define LOG_EMERG       0       /* system is unusable */
>> #define LOG_ALERT       1       /* action must be taken immediately */
>> #define LOG_CRIT        2       /* critical conditions */
>> #define LOG_ERR         3       /* error conditions */
>> #define LOG_WARNING     4       /* warning conditions */
>> #define LOG_NOTICE      5       /* normal but significant condition */
>> #define LOG_INFO        6       /* informational */
>> #define LOG_DEBUG       7       /* debug-level messages */
>>
>> And I'd like to at least see notice and debug added.
>>
>
> Well in addition to Debug I would also like to see Trace but it's f. ex. hard for me to tell the difference between Info and Notice and their names do not imply that certain severity order IMO.

Yes. I would really like to avoid adding more severities because it complicates the decision the developer needs to make when deciding at which log level to log. This reminds of a situation that came up at a previous employer. A bunch of smart people tried to come up with a policy for deciding at which log level to log a particular message. Let just say that the discussion lasted days and no decision was made. I believe that the only reason why this subject even came up at my previous job is because most logging framework provide hard-coded levels that don't have any semantic difference between them. Interesting talk on the subject: http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html

> So I see a point in the
> argument that vlog() allows everyone to be happy without endless numbers of
> predefined log levels.. however I'm also not quite convinced.
>
>
>> While we're at it, what's the point of dfatal? Why on earth would a
>> _fatal_
>> condition not be fatal if it were in release mode if it were fatal in
>> debug
>> mode? Is it fatal or not? It seems to me like another needless
>> complication.
>>
>> If you're going to have write, then have writef, not format. Then it's
>> actually consistent with our normal I/O functions. Also, do writef and
>> format
>> automatically append a newline? If so, then they should be writeln and
>> writefln.
>>
>
> I think the names should be as short as possible for the common 99% case. As this is not a general purpose stream, I think it is fine to drop the 'ln'. And the current version that defines info("") as the version that can format and info.write("") as the plain string version seems to be quite optimal in this regard.
>
> In my optinion, more descriptive names would just impair readability here instead of helping. They will be written endless number of times but do not influence the program flow and should immediately understandable by anyone who sees them. But something like log.warn/logf.warn or log.warn/log.warnf might also work if you really want the consistency...
>
As of right now (or in the immediate future) we have:
info("%s message", Severity.info);
info.write(Severity.info, " message);
info.writef("%s message", Severity.info);

Thanks!
-Jose

>
>> Rich is a horrible name IMHO. It says nothing about what it actually is or
>> does. I'm not sure what a good name would be (BoolMessage?, LogResult?),
>> but
>> Rich by itself is very confusing and utterly uninformative.
>>
>> And why does Configuration's logger property throw if you set it after a
>> logging call has been made. Is it really that inconceivable that someone
>> would
>> swap out loggers at runtime? Or is the idea that you'd swap out the
>> Configuration?
>>
>> - Jonathan M Davis
>
>

On 2/17/12 12:06 PM, Jose Armando Garcia wrote:
> info("%s message", Severity.info);

I think defaulting to formatted stuff may be confusing.

Andrei

On 2/13/2012 7: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!

This is a general comment, not specific to std.log:

All new library submissions need to be reviewed for applicability of:

@safe
const
pure
nothrow

for all user-facing API functions.

On Fri, Feb 17, 2012 at 6:48 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 2/17/12 12:06 PM, Jose Armando Garcia wrote:
>>
>> info("%s message", Severity.info);
>
>
> I think defaulting to formatted stuff may be confusing.
>
Even if we document this? I mean:

info("Info message");

Just works. The one place where is wont just work is with:

info("This is an ", Severity.info, " message);

But do we think users will do with this without reading one bit of the documentation? And even then we can say RTFM ;).

I don't have a strong argument or preference for one over the other.
>From my experience I tend to write or log using a format string mainly
because it is more readable to me and plays nicer with localization frameworks like gettext.

Thoughts?
-Jose

> Andrei

On Fri, Feb 17, 2012 at 7:12 PM, Walter Bright <newshound2@digitalmars.com> wrote:
> On 2/13/2012 7: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!
>
>
> This is a general comment, not specific to std.log:
>
> All new library submissions need to be reviewed for applicability of:
>
> @safe
> const
> pure
> nothrow
>
> for all user-facing API functions.

Yep. I have been following that thread and your commits. I have a TODO for this.

Thanks.
-Jose

On Friday, 17 February 2012 at 06:39:29 UTC, H. S. Teoh wrote:
> […] DEBUG and TRACE are rarely ever used after 4
> or 5 developers have had their hands on it, because turning those on
> will usually flood the logs with reams and reams of irrelevant messages
> from unrelated modules, so most people would stop using it after the
> first time.

I think avoiding this problem is one of the major benefits of the proposed std.log design (because vlog output can be filtered on a per-module basis).

David