February 14, 2012
On Tuesday, 14 February 2012 at 18:51:20 UTC, Jose Armando Garcia wrote:
> On Tue, Feb 14, 2012 at 4:44 PM, jdrewsen <jdrewsen@nospam.com> wrote:
>> On Tuesday, 14 February 2012 at 16:12:57 UTC, Jose Armando Garcia wrote:
>>>
>>> On Mon, Feb 13, 2012 at 1:50 PM, David Nadlinger <see@klickverbot.at>
>>> 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
>>>
>>>
>>> Updated the document an implementation to reflect every suggest for I
>>> replied to with the exception of providing a format parameter for
>>> thread name. Should have that ready later today. Let me know if I
>>> missed anything. API changes:
>>>
>>> 1. Dropped log!info("message"), etc. Use info("message), etc.
>>> 2. opCall now alias to format. Ie. info("Format %s message",
>>> Severity.info).
>>>  this means that to concatenate strings you need to
>>> info.write("Hello ", "world");
>>>
>>
>> In the introduction text the references to Configuration etc. should be made
>> into links.
>>
> I would love to do that. How do you do that with ddoc?

For example: $(LREF Configuration)

The LREF macro is defined in https://github.com/D-Programming-Language/d-programming-language.org/blob/master/std.ddoc#L293 along with other useful macros.

/Jonas

February 14, 2012
On 2012-02-14 17:19, Jose Armando Garcia wrote:
> On Tue, Feb 14, 2012 at 5:44 AM, Jacob Carlborg<doob@me.com>  wrote:
>> 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.
>>
> What do you mean by formatter? For example the default Logger
> (FileLogger) allow you to specify the format line see
> FileLogger.Configuration.lineFormat
>
> If you want to do the HTML stuff Sönke mentioned then you need to
> inherit Logger and overwrite config.logger. Mind you that the Logger
> API should be view almost like a journaling API and HTML is a document
> so the differences need to be reconciled in the implementation of
> Logger.

Yeah, I was referring to something like outputting HTML. Ok, I see.

-- 
/Jacob Carlborg
February 14, 2012
On 2012-02-14 17:27, Jose Armando Garcia wrote:
> On Tue, Feb 14, 2012 at 11:14 AM, Jacob Carlborg<doob@me.com>  wrote:
>> 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.
>>
> What do you mean by location? If you mean file system directory then:
> @property string logDirectory(string logDirectory);
> const const @property string logDirectory();
>      Specifies the directory where log files are created.
>
>      The default value for this property is the value in the
> environment variable LOGDIR. If LOGDIR is not set, then TEST_TMPDIR is
> used. If TEST_TMPDIR is not set, then it logs to the current
> directory.
>
> If you mean file name, you have 'fileNamePrefixes' and 'fileNameExtension'.
>
> If you mean syslog then for now the user needs to implement this but I
> foresee us implementing this in phobos in the near future.

I meant something like a general interface one could implement to be able to log to basically anywhere, not only files. Say that I would want to output the log in a window in a GUI application, for example.

-- 
/Jacob Carlborg
February 14, 2012
On 02/13/2012 07:50 AM, David Nadlinger wrote:
> 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)

This is somehow bad. Review a piece of library-software by using a beta compiler and beta-library.
February 15, 2012
On Tuesday, 14 February 2012 at 21:47:42 UTC, bls wrote:

> This is somehow bad. Review a piece of library-software by using a beta compiler and beta-library.

Indeed, never happened such thing in whole compiler/language development history.
February 15, 2012
On Tuesday, 14 February 2012 at 21:47:42 UTC, bls wrote:
> This is somehow bad. Review a piece of library-software by using a beta compiler and beta-library.

I don't quite see where the problem is with that. Besides, 2.058 is already out now (and was scheduled to be released on Feb 13).

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

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.

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

> 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

February 16, 2012
On Tuesday, 14 February 2012 at 01:58:50 UTC, Jose Armando Garcia wrote:
> 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.

In my applications I want my logs to be human readable by users and/or admins.
I tend to have different kinds of what you call warnings.

Say my app uploads a file by FTP. It would be something like:

info("sending file to host")
and then
case a:
info("file sent successfully - took time x")

case b:
warning("encountered some FTP problems") info("file sent successfully - took time x")

case c:
warning("encountered severe FTP problems - could not send file")

The program can handle all three cases.
But I want to clearly communicate to the user the different severity of the problems the program handled. BTW I normally call case c "error" (from the users perspective).
February 16, 2012
On 2012-02-16 10:57, Sönke Ludwig 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. 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.

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.

-- 
/Jacob Carlborg