On Wed, Mar 7, 2012 at 6:39 AM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Wed, 07 Mar 2012 07:09:17 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>> On Tue, 06 Mar 2012 14:39:28 -0500, Jose Armando Garcia <jsancio@gmail.com> wrote:
>>
>>> 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?
>>
>>
>> Because naming is important.  It's very difficult to change names once something is released.  I seriously could care less about implementation (didn't even look at it).  That can be fixed.  Naming can't.
>>
>>> What is wrong with:
>>>
>>> import log = std.log;
>>> log.info("cool");
>>
>>
>> What is wrong with
>>
>> import std.log;
>> log.info("cool");
>
>
> alternatively:
>
> log_info("cool");
> linfo("cool");
> lginfo("cool");
>
> There are so many choices besides just "info."  We should use something else.
>

Lets flip the question. Why are you against:

import log = std.log;

Thanks,
-Jose

> -Steve

On Mar 11, 2012, at 10:26 PM, Jose Armando Garcia <jsancio@gmail.com> wrote:

> On Wed, Mar 7, 2012 at 6:39 AM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> 
>> 
>> alternatively:
>> 
>> log_info("cool");
>> linfo("cool");
>> lginfo("cool");
>> 
>> There are so many choices besides just "info."  We should use something else.
>> 
> 
> Lets flip the question. Why are you against:
> 
> import log = std.log;

Which is the more common case?

On Mon, 12 Mar 2012 01:26:54 -0400, Jose Armando Garcia <jsancio@gmail.com> wrote:

> On Wed, Mar 7, 2012 at 6:39 AM, Steven Schveighoffer
> <schveiguy@yahoo.com> wrote:
>> On Wed, 07 Mar 2012 07:09:17 -0500, Steven Schveighoffer
>> <schveiguy@yahoo.com> wrote:
>>>
>>> What is wrong with
>>>
>>> import std.log;
>>> log.info("cool");
>>
>>
>> alternatively:
>>
>> log_info("cool");
>> linfo("cool");
>> lginfo("cool");
>>
>> There are so many choices besides just "info."  We should use something
>> else.
>>
>
> Lets flip the question. Why are you against:
>
> import log = std.log;

I'm against having a requirement (or at least a strong suggestion) to import std.log in a certain way other than import std.log.  There are a couple problems with this:

1. Almost all code examples in modules use import modulename;  They don't have some documentation that says "you should probably import modulename by import modulename = modulename".  For an example of this, see http://www.dsource.org/projects/tango/docs/stable/tango.io.Path.html
2. With no guarantees that everyone will use "log" as the symbol (or even use the symbol), you potentially have several files using std.log under different symbols.  For example, someone might prefer "logger" or "lg".  This just makes things more confusing than is necessary.

I'm not actually against using this technique, I'm just against making it standard practice.  I feel using a naming scheme which eliminates having to use this trick to be able to keep your existing names and/or use these common names as members would foster more uniform code and usage.  That's all.

Yes, this is a form of bikeshedding, but it's one of those things that will be difficult to change later.  Even just changing the names of the functions which log to something less common, like I stated above, could be worth a lot.

I won't vote against the lib if this is my only objection, but I do think it's important.  If others don't, well, I guess we'll see what happens.  I likely will be using import log = std.log whenever I use it.

-Steve

On Mon, 12 Mar 2012 01:05:33 -0400, Jose Armando Garcia <jsancio@gmail.com> wrote:

> On Sun, Mar 11, 2012 at 3:28 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>
>> I thought more about the point made about mixing throwing and logging
>> levels. I agree that it's awkward to e.g. log to critical without throwing
>> etc. I personally think in that case you really want the error log, but hey,
>> point taken.
>>
>
> I thought about this a lot too and right now I think that if we want
> to remove asserting from fatal and remove throwing from critical then
> we should just remove those log levels completely. To me they don't
> add any additional value. The whole point of having them in the first
> place was because of their assert and throw semantic.

This is fine, since we can always add more levels later if a need arises.

-Steve

On Mar 12, 2012, at 7:28 AM, Andrei Alexandrescu wrote:

> On 3/11/12 4:49 PM, David Nadlinger wrote:
>> Unfortunately, the discussion has ground to a halt again, so consider this a friendly reminder that there is still one day left until the end of the review period.
>> 
>> David
> 
> I thought more about the point made about mixing throwing and logging levels. I agree that it's awkward to e.g. log to critical without throwing etc. I personally think in that case you really want the error log, but hey, point taken.
> 
> Here's a suggestion:
> 
> * Don't throw from the critical log and don't abort from the fatal log.
> 
> * Define the logging functions such that logging an exception will log its toString() and then throw the exception.
> 
> * Regarding static import log = std.log, I suggest we keep course.
> 
> Works?


+1

(I particularly like the idea of logging an exception rather than logging a message and a separate exception to throw, which may contain a different message.)


Geoff

On Mon, 12 Mar 2012 00:15:14 -0500, Jose Armando Garcia <jsancio@gmail.com> wrote:
> On Wed, Mar 7, 2012 at 7:16 AM, Robert Jacques <sandford@jhu.edu> wrote:
>> On Tue, 06 Mar 2012 21:22:21 -0600, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On 3/6/12 6:05 PM, Geoffrey Biggs wrote:
>>>>
>>>> That approach means that if I actually do have a fatal error, I can't
>>>> mark it as such.
>>>
>>>
>>> Use log.fatal for those.
>>>
>>> Andrei
>>
>>
>> But fatal "Logs a fatal severity message. Fatal log messages terminate the
>> application after the message is persisted. Fatal log message cannot be
>> disable at compile time or at run time." The point is that he want to log a
>> fatal message and then terminate in a custom manner. I don't see a problem
>> with convince functions that log and error and then throw, but not having
>> the option to not throw is an unnecessary limitation.
>
> Okay. Let me say this one last time. If you don't want to assert or
> throw don't use fatal and critical. I think we are done beating a dead
> horse. Maybe it is not clear from the documentation but the only
> reason why fatal and critical exist is because of their assert and
> throw semantic. This is also the reason why you can't disable them.
>
> I understand that to a person that has not read the documentation is
> may not be clear to them that fatal("message") asserts and
> critical("message") throws. Knowing this observation maybe we can
> remove these severities and make the behavior more obvious by adding
> the tempalte logAndThrow.
>
> Thanks,
> -Jose

There is a strong impression that a 'fatal' error and an 'error' will appear differently in the log file. So long as fatal is anything more than log an error, flush and throw, there will be people wanting to separate the fatal log level from fatal log and throw command. I think the logAndThrow will clear up this confusion.

On Mon, Mar 12, 2012 at 1:11 PM, Robert Jacques <sandford@jhu.edu> wrote:
> On Mon, 12 Mar 2012 00:15:14 -0500, Jose Armando Garcia <jsancio@gmail.com> wrote:
>>
>> On Wed, Mar 7, 2012 at 7:16 AM, Robert Jacques <sandford@jhu.edu> wrote:
>>>
>>> On Tue, 06 Mar 2012 21:22:21 -0600, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> On 3/6/12 6:05 PM, Geoffrey Biggs wrote:
>>>>>
>>>>>
>>>>> That approach means that if I actually do have a fatal error, I can't mark it as such.
>>>>
>>>>
>>>>
>>>> Use log.fatal for those.
>>>>
>>>> Andrei
>>>
>>>
>>>
>>> But fatal "Logs a fatal severity message. Fatal log messages terminate
>>> the
>>> application after the message is persisted. Fatal log message cannot be
>>> disable at compile time or at run time." The point is that he want to log
>>> a
>>> fatal message and then terminate in a custom manner. I don't see a
>>> problem
>>> with convince functions that log and error and then throw, but not having
>>> the option to not throw is an unnecessary limitation.
>>
>>
>> Okay. Let me say this one last time. If you don't want to assert or throw don't use fatal and critical. I think we are done beating a dead horse. Maybe it is not clear from the documentation but the only reason why fatal and critical exist is because of their assert and throw semantic. This is also the reason why you can't disable them.
>>
>> I understand that to a person that has not read the documentation is may not be clear to them that fatal("message") asserts and critical("message") throws. Knowing this observation maybe we can remove these severities and make the behavior more obvious by adding the tempalte logAndThrow.
>>
>> Thanks,
>> -Jose
>
>
> There is a strong impression that a 'fatal' error and an 'error' will appear differently in the log file. So long as fatal is anything more than log an error, flush and throw, there will be people wanting to separate the fatal log level from fatal log and throw command. I think the logAndThrow will clear up this confusion.

Okay. Let me try to wipe something up soonish but it may take me some time given my current schedule.

On Monday, 12 March 2012 at 05:05:43 UTC, Jose Armando Garcia wrote:
> I think there is currently too much disagreement on std.log. I am
> honestly too busy juggling family, friends, school and work. I am
> currently leaning towards removing std.log from the review queue and
> spending some time ironing out the details pointed in this thread. I
> would like to experiment with some things before making any real
> suggestions but I would really like to have a logging library that I
> use throw/assert for me as it would simplify my code.

Okay, so let's remove std.log from the review queue without a vote for now. Be sure to let everybody know when you had a chance to work on it and you think it's time for resuming the review, even if this should already be next week; std.log will re-enter the queue then.

Thanks to everyone,
David

On 3/12/12 5:35 PM, David Nadlinger wrote:
> On Monday, 12 March 2012 at 05:05:43 UTC, Jose Armando Garcia wrote:
>> I think there is currently too much disagreement on std.log. I am
>> honestly too busy juggling family, friends, school and work. I am
>> currently leaning towards removing std.log from the review queue and
>> spending some time ironing out the details pointed in this thread. I
>> would like to experiment with some things before making any real
>> suggestions but I would really like to have a logging library that I
>> use throw/assert for me as it would simplify my code.
>
> Okay, so let's remove std.log from the review queue without a vote for
> now. Be sure to let everybody know when you had a chance to work on it
> and you think it's time for resuming the review, even if this should
> already be next week; std.log will re-enter the queue then.
>
> Thanks to everyone,
> David

I think that's a wise decision, thanks Jose and David.

One possibility is that Jose transfers the code to someone else who takes it through the review process and makes the appropriate amends. Jose would of course keep authoring credits, to which the new submitter would be added. Is anyone interested?


Thanks,

Andrei

On Mon, Mar 12, 2012 at 4:01 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 3/12/12 5:35 PM, David Nadlinger wrote:
>>
>> On Monday, 12 March 2012 at 05:05:43 UTC, Jose Armando Garcia wrote:
>>>
>>> I think there is currently too much disagreement on std.log. I am honestly too busy juggling family, friends, school and work. I am currently leaning towards removing std.log from the review queue and spending some time ironing out the details pointed in this thread. I would like to experiment with some things before making any real suggestions but I would really like to have a logging library that I use throw/assert for me as it would simplify my code.
>>
>>
>> Okay, so let's remove std.log from the review queue without a vote for now. Be sure to let everybody know when you had a chance to work on it and you think it's time for resuming the review, even if this should already be next week; std.log will re-enter the queue then.
>>
>> Thanks to everyone,
>> David
>
>
> I think that's a wise decision, thanks Jose and David.
>
> One possibility is that Jose transfers the code to someone else who takes it through the review process and makes the appropriate amends. Jose would of course keep authoring credits, to which the new submitter would be added. Is anyone interested?
>

I have tried to document every major modification that the community has requested in Trello. I'll continue to work on std.log but if anyone thinks they can complete this faster than me, please go ahead and take over. Just let know.

Thanks David and everyone else for your commitment to the the review process.

-Jose

>
> Thanks,
>
> Andrei