On Mon, Mar 5, 2012 at 5:32 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Tuesday, March 06, 2012 02:22:05 so wrote:
>> That is not a counter-argument to something related to this
>> library but everything that lies in global namespace.
>> At its first state both severity levels and the "log" was in
>> global namespace. Now only severity levels.
>>
>> You are also overlooking one crucial fact that this library will be part of phobos, standard library. Which requires everyone to adopt. When you see codes like this (below), you don't blame standard library designers do you?
>>
>> using namespace std;
>> int cout;
>
> Except that cout is not exactly something that would be considered a normal variable name. Something like info _is_. This logging module is taking incredibly common names and shoving them as far into the global namespace as anything can go in D which isn't a compiler built-in. _Not_ a good idea IMHO - not without good reason. And I really don't think that this merits it. log!info(msg) would work just fine and would be _far_ better.

using namesapce std;

matrix vector = new Matrix(...)

The variable vector conflicts with std::vector. Honestly, I can sit here and come up with 10s or 100s of example where you want to use a symbol that is expose by another module. You don't have to go far just look at druntime and phobos. This the exact reason why modules and namespace exist and one of the reason why people hate C's preprocessor macros. D solved this problem years ago.

>
> - Jonathan M Davis

On Mon, Mar 5, 2012 at 5:30 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Mon, 05 Mar 2012 20:22:05 -0500, so <so@so.so> wrote:
>
>> On Monday, 5 March 2012 at 23:51:29 UTC, Steven Schveighoffer wrote:
>>>
>>> On Mon, 05 Mar 2012 18:30:03 -0500, David Nadlinger <see@klickverbot.at> wrote:
>>>
>>>> On Monday, 5 March 2012 at 21:55:08 UTC, Steven Schveighoffer wrote:
>>>>>
>>>>> The log aliases use names that are too common.  I think log.info is a better symbol for logging than just 'info', which could be a symbol in a myriad of places.  Given that D's symbol lookup rules allow shadowing of global symbols, this does not work out very well.
>>>>
>>>>
>>>> Originally, the code used log!info and so on, but it was changed to the current design right after review begin, the rationale being that you could always use »import log = std.log« if you want the extra namespace.
>>>
>>>
>>> That doesn't help.  Software isn't static.
>>>
>>> import std.log;
>>> import other; // defines B
>>>
>>> class A : B
>>> {
>>>   void foo()
>>>   {
>>>      info("some info message"); // error! int isn't a function!
>>>   }
>>> }
>>>
>>> other.d:
>>>
>>> class B
>>> {
>>>   int info; // added later
>>> }
>>
>>
>> That is not a counter-argument to something related to this library but
>> everything that lies in global namespace.
>> At its first state both severity levels and the "log" was in global
>> namespace. Now only severity levels.
>>
>> You are also overlooking one crucial fact that this library will be part of phobos, standard library. Which requires everyone to adopt. When you see codes like this (below), you don't blame standard library designers do you?
>>
>> using namespace std;
>> int cout;
>
>
> Except 'info', 'error', 'warning' are all common names, likely to be a very attractive name for something that has nothing to do with (or cares about) logging.  cout is not a common name or even an english word, so it's unlikely someone has or wants to create a cout member.
>
Actually, I see this more as argument as to why cout is a horrible name for a symbol in std.stdio. I suspect that the only reason that it is there is to keep C developer migrating to D happy. It should probably just be "out" like Java (System.out) and C# (Console.Out).

> Couple this with the fact that all of these are nouns -- likely candidates for fields.
>
> Your argument has some merit, but I would add that my argument is only against *common* global namespace names.
>
> Another solution besides using a namespace is to make the names less common, like linfo instead of just info.
>
> -Steve

On Mon, Mar 5, 2012 at 7:11 PM, Robert Jacques <sandford@jhu.edu> wrote:
> On Mon, 05 Mar 2012 19:22:05 -0600, so <so@so.so> wrote:
>>
>> On Monday, 5 March 2012 at 23:51:29 UTC, Steven Schveighoffer wrote:
>>>
>>> On Mon, 05 Mar 2012 18:30:03 -0500, David Nadlinger <see@klickverbot.at> wrote:
>>>
>>>> On Monday, 5 March 2012 at 21:55:08 UTC, Steven Schveighoffer wrote:
>>>>>
>>>>> The log aliases use names that are too common.  I think log.info is a better symbol for logging than just 'info', which could be a symbol in a myriad of places.  Given that D's symbol lookup rules allow shadowing of global symbols, this does not work out very well.
>>>>
>>>>
>>>> Originally, the code used log!info and so on, but it was changed to the current design right after review begin, the rationale being that you could always use »import log = std.log« if you want the extra namespace.
>>>
>>>
>>> That doesn't help.  Software isn't static.
>>>
>>> import std.log;
>>> import other; // defines B
>>>
>>> class A : B
>>> {
>>>   void foo()
>>>   {
>>>      info("some info message"); // error! int isn't a function!
>>>   }
>>> }
>>>
>>> other.d:
>>>
>>> class B
>>> {
>>>   int info; // added later
>>> }
>>
>>
>> That is not a counter-argument to something related to this
>> library but everything that lies in global namespace.
>> At its first state both severity levels and the "log" was in
>> global namespace. Now only severity levels.
>>
>> You are also overlooking one crucial fact that this library will be part of phobos, standard library. Which requires everyone to adopt.
>
>
> Please don't forget that you are _submitting_ a library into Phobos and the D ecosystem at large. Yes, new code can be expected to avoid these names, but all existing code has to be retrofitted and fixed.

Not is doesn't. First, it will only break your code if you import std.log. If you are now importing std.log that means you are already modifying the code. If you don't want to modify existing code when adding your changes just:

import someSymboleThatDoesntCollide = std.log;

Pick your poison.

Thanks,
-Jose

On Tue, Mar 6, 2012 at 12:25 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Tuesday, March 06, 2012 09:14:16 so wrote:
>> On Tuesday, 6 March 2012 at 07:46:14 UTC, Jacob Carlborg wrote:
>> > On 2012-03-06 02:32, Jonathan M Davis wrote:
>> >
>> > The user can then alias "log!info" to "info" if he/she wants to.
>>
>> Again, you are now forcing 2 common names instead of one as it is
>> now.
>> When you instantiate log!info where do you get "info" from?
>
> Yes. My mistake - probably because the time stuff typicall takes such a template argument as string, which would make this log!"info"(msg). However, adding _log_ isn't necessarily bad, given that this is std.log that we're talking about. It's info and the rest that are the problem.
>
Seriously everyone. What are we spending some much effort on this? What is wrong with:

import log = std.log;
log.info("cool");

Thanks,
-Jose

> - Jonathan M Davis

On Tue, Mar 6, 2012 at 10:11 AM, Robert Jacques <sandford@jhu.edu> wrote:
> On Tue, 06 Mar 2012 11:44:13 -0600, Jose Armando Garcia <jsancio@gmail.com> wrote:
>>
>> On Tue, Mar 6, 2012 at 9:32 AM, Robert Jacques <sandford@jhu.edu> wrote:
>>>
>>> On Tue, 06 Mar 2012 11:01:19 -0600, Jose Armando Garcia
>>> <jsancio@gmail.com>
>>> wrote:
>>>
>>>> On Wed, Feb 29, 2012 at 4:13 PM, Richard van Scheijen <dlang@mesadu.net> wrote:
>>>>>
>>>>>
>>>>> When logging the severity level should convey a certain insight that
>>>>> the
>>>>> developer has about the code. This can be done with a 3 bit field.
>>>>> These
>>>>> are: known-cause, known-effect and breaks-flow.
>>>>>
>>>>> This creates the following matrix:
>>>>>
>>>>> KC KE BF Severity
>>>>> =================
>>>>> 1  1  0  Trace
>>>>> 0  1  0  Info
>>>>> 1  0  0  Notice
>>>>> 0  0  0  Warning
>>>>> 1  1  1  Error
>>>>> 0  1  1  Critical
>>>>> 1  0  1  Severe
>>>>> 0  0  1  Fatal
>>>>>
>>>>> A known cause is when the developer knows why a log event is made.
>>>>> e.g.:
>>>>> if
>>>>> you cannot open a file, you do not know why.
>>>>> A known effect is when he/she knows what happens after. Basically, you
>>>>> can
>>>>> tell if it is a catch-all by this flag.
>>>>>
>>>>> When a severity should only be handled by a debugger, the normal debug statement should be used. This is in essence a 4th bit.
>>>>>
>>>>> I hope this helpful in the search for a good level system.
>>>>>
>>>>
>>>> Interesting observation on logging. I like your theoretical observation and explanation. To me the most important thing is usability and unfortunately people are used to log levels as a order concept. Meaning error is higher severity than info so if I am logging info events I should probably also log error events.
>>>>
>>>> If we go with a mechanism like the one you describe above there is no order so the configuration is a little more complicated or verbose I should say. Instead of saying we should log everything "greater" than warning the user needs to say that they want to log known-cause, known-effect, breaks-flow events. This mean that there are 27 (= 3^3) configuration combinations. To implement this we need 3 configuration nobs with 3 values (on, off, both).
>>>>
>>>> Thoughts?
>>>> -Jose
>>>
>>>
>>>
>>> There are only 8 possible configurations and they are nicely ordered in
>>> terms of severity. So I don't see this as a problem. Also, if you went
>>> with
>>> a combinatorial approach, shouldn't it be 2^8 = 256, not 3^3 = 27 values?
>>
>>
>> Yes. If you want to enable and disable each individual "level" then you need 8 configuration options which leads to 2^8.
>>
>> I suggested 3^3 as a more reasonable options that matches how the developer is logging but doesn't give you as much expressiveness as the 2^8 option.
>
>
> In practice, all you'd need to take is a flag with the desired levels. i.e.
>
> // Automatically set logging levels using the standard severity ordering config.minSeverity(Severity.Warning);
>
> // Manually set the logging levels
> config.setSeverities(Severity.Warning|
>                     Severity.Error|
>                     Severity.Critical|
>                     Severity.Severe|
>                     Severity.Fatal);
>
> I don't see the problem with including both methods and a large advantage to having a standardized severity framework.

Interesting. If you find this useful, I think we can add this in a future release as it shouldn't break existing modules that maybe using the library.

On 3/6/12 11:39 AM, Jose Armando Garcia wrote:
> Seriously everyone. What are we spending some much effort on this?
> What is wrong with:
>
> import log = std.log;
> log.info("cool");

Indeed I think that should be fine.


Thanks,

Andrei

On 3/6/12 11:36 AM, Jose Armando Garcia wrote:
> import someSymboleThatDoesntCollide = std.log;

I think this works better:

static import log = std.log;


Andrei

On Tuesday, 6 March 2012 at 19:47:50 UTC, Andrei Alexandrescu wrote:
> On 3/6/12 11:36 AM, Jose Armando Garcia wrote:
>> import someSymboleThatDoesntCollide = std.log;
>
> I think this works better:
>
> static import log = std.log;

Isn't this just another case of DMD silently accepting superfluous attributes/modifiers?

David

On Tue, Mar 06, 2012 at 11:45:47AM -0800, Andrei Alexandrescu wrote:
> On 3/6/12 11:39 AM, Jose Armando Garcia wrote:
> >Seriously everyone. What are we spending some much effort on this? What is wrong with:
> >
> >import log = std.log;
> >log.info("cool");
> 
> Indeed I think that should be fine.
[...]

+1. I think std.log is ready to merge, as is.


T

-- 
Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.

On Mon, Feb 13, 2012 at 7:50 AM, 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.
>

Hi everyone,

I have been tracking all the changes we need to make immediately and things we can add in the future without break backward compatibility if have access to trello go here: https://trello.com/card/std-log/4f33d3c6542c156960533efb/1#

Exporting things form trello looks like a pain but here it is:

Future:

1. Allowing filtering of regular log messages (like info, warning,
etc) based on the module. Similar to how vlog works.
2. Add support for custom line formatters
3. Talk about adding config.setSeverity(...) which is a union of all
the severity specified. The logical OR operator is not going to work
because internally the values are 0,1, etc. and we use them to index
into an array. One solution is to pass an array to
config.setSeverity(...)

Fix now:

1. Add thread name attribute to the default logger
2. Check that the example compile
3. Come up with a better name for Rich and rich template
4. Add @safe pure nothrow const to as many methods as possible
5. Remove check when setting Configuration.logger

Note: There were a few other things that were suggested here that I have already fixed. Need to look at my commits for this.

Thanks,
-Jose

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