On Tuesday, 26 August 2014 at 15:44:19 UTC, Robert burner Schadek wrote:
> BTW:
>   * move std.logger to std.experimental.logger
>   * the github project has unittests for the version statements (all pass)
>
> whats next?

I will compare changelist against list of requirements from voters this weekend and if all seems to be addressed will start a new round of review/voting.

Am Tue, 26 Aug 2014 18:23:30 +0000
schrieb "Dicebot" <public@dicebot.lv>:

> On Tuesday, 26 August 2014 at 15:44:19 UTC, Robert burner Schadek wrote:
> > BTW:
> >   * move std.logger to std.experimental.logger
> >   * the github project has unittests for the version statements
> > (all pass)
> >
> > whats next?
> 
> I will compare changelist against list of requirements from voters this weekend and if all seems to be addressed will start a new round of review/voting.

Someone else mentioned it before: Logging in destructors would be a requirement for me, too. Thanks to the GC we usually don't release memory in them, but "foreign" resources like e.g. hardware audio playback buffers would typically handled in a dtor. I see two ways which both require logging:

1) Dtor calls a C function to release the resource, which may
   return an error code, that you want to log. You keep the
   program running since if all else fails you could still
   reinitialize the audio device, thereby releasing all
   buffers.

2) If waiting for the GC to eventually call the dtor is not an
   option because the resource is very limited, you require
   the user to call some .release/.close method. If in the dtor
   the resource is still "open", you log something like
   "WARNING: Destructor called, but audio buffer still
    attached. Call .close() on the last reference."

As much as I see this as non-negotiable, (chancellor Merkel would have said "alternativlos",) I know it would currently require the whole log system to be nothrow @nogc and we may not want to wait till allocating and throwing is allowed during GC sweeps, before we get std.log.

-- 
Marco

On Tuesday, 26 August 2014 at 19:39:26 UTC, Marco Leise wrote:
>
> As much as I see this as non-negotiable, (chancellor Merkel
> would have said "alternativlos",) I know it would currently
> require the whole log system to be nothrow @nogc and we may
> not want to wait till allocating and throwing is allowed
> during GC sweeps, before we get std.log.

nothrow I get, but nothrow in dtors is a much wider topic (please open a new thread if you want to discuss this) and see my example to hack around it.

but no nogc should be no problem as long as you use a Logger that doesn't allocate for logging, as for example FileLogger. And even than, what is the problem with no nogc logging in dtors?

--------------
class Foo {
    ~this() {
        try {
            log("Foo"); // log to file
        } catch(Exception e) {}
    }
}
--------------

On Tuesday, 26 August 2014 at 18:23:31 UTC, Dicebot wrote:
>
> I will compare changelist against list of requirements from voters this weekend and if all seems to be addressed will start a new round of review/voting.

sounds good!
just to note, I will be mostly offline for a good week starting friday.

Am Tue, 26 Aug 2014 20:59:57 +0000
schrieb "Robert burner Schadek" <rburners@gmail.com>:

> nothrow I get, but nothrow in dtors is a much wider topic (please open a new thread if you want to discuss this) and see my example to hack around it.

You are right.

> but no nogc should be no problem as long as you use a Logger that doesn't allocate for logging, as for example FileLogger. And even than, what is the problem with no nogc logging in dtors?
> 
> --------------
> class Foo {
>      ~this() {
>          try {
>              log("Foo"); // log to file
>          } catch(Exception e) {}
>      }
> }
> --------------

As far as I know, exactly this is not possible with the current GC implementation. The exception you catch there has just been allocated somewhere deeper in the log function. But all GC allocations in a GC invoked dtor cause MemoryErrors and program abortion/crashes. :(

In a perfect world I'd imagine you can set up a fallback
logger. So if the disk is full an exception is thrown by e.g.
std.stdio.File, which is passed as an error level log message
to the fallback logger, which might write to stderr:
"ERROR: Could not write the following message to logXYZ:
<message>
The reason was: Disk full"

-- 
Marco

On Wednesday, 27 August 2014 at 00:09:15 UTC, Marco Leise wrote:
> As far as I know, exactly this is not possible with the
> current GC implementation. The exception you catch there has
> just been allocated somewhere deeper in the log function. But
> all GC allocations in a GC invoked dtor cause MemoryErrors and
> program abortion/crashes. :(
>
> In a perfect world I'd imagine you can set up a fallback
> logger. So if the disk is full an exception is thrown by e.g.
> std.stdio.File, which is passed as an error level log message
> to the fallback logger, which might write to stderr:
> "ERROR: Could not write the following message to logXYZ:
> <message>
> The reason was: Disk full"

I don't think it will help either. The very moment exception is allocated inside std.stdio.File your program will crash, it won't get to fallback. Only solution is to implement your logger as @nothrow thing by using only C functions internally instead of std.stdio - something that feels overly limited for a general use case. I really think this is the case where you should roll your own FileNoThrowingLogger and go with it.

In a long term this is something much better to be fixed in GC implementation than constantly hacked in stdlib modules.

Am Wed, 27 Aug 2014 01:09:21 +0000
schrieb "Dicebot" <public@dicebot.lv>:

> On Wednesday, 27 August 2014 at 00:09:15 UTC, Marco Leise wrote:
> > As far as I know, exactly this is not possible with the current GC implementation. The exception you catch there has just been allocated somewhere deeper in the log function. But all GC allocations in a GC invoked dtor cause MemoryErrors and program abortion/crashes. :(
> >
> > In a perfect world I'd imagine you can set up a fallback
> > logger. So if the disk is full an exception is thrown by e.g.
> > std.stdio.File, which is passed as an error level log message
> > to the fallback logger, which might write to stderr:
> > "ERROR: Could not write the following message to logXYZ:
> > <message>
> > The reason was: Disk full"
> 
> I don't think it will help either. The very moment exception is allocated inside std.stdio.File your program will crash, it won't get to fallback. Only solution is to implement your logger as @nothrow thing by using only C functions internally instead of std.stdio - something that feels overly limited for a general use case.

Exactly, I just needed someone else to speak it out. :)

> I really think this is the case where you should roll your own FileNoThrowingLogger and go with it.

*Me* or everyone who needs to log something in a dtor?

> In a long term this is something much better to be fixed in GC implementation than constantly hacked in stdlib modules.

Or is this maybe the other language change (besides not generating code for unused lambdas) that should be pushed with std.log, because otherwise it will never be solved ?

I don't know, but no logging in dtors is a serious
and hard to sell limitation. Not the author's fault though.

-- 
Marco

On Tuesday, 26 August 2014 at 19:39:26 UTC, Marco Leise wrote:
> Am Tue, 26 Aug 2014 18:23:30 +0000
> schrieb "Dicebot" <public@dicebot.lv>:
>
>> On Tuesday, 26 August 2014 at 15:44:19 UTC, Robert burner Schadek wrote:
>> > BTW:

> Someone else mentioned it before: Logging in destructors would
> be a requirement for me, too.

It would be a pity to have forbidden spaces for logging. I very much like the fact that use of printk() is so much ubiquitous.

On Wednesday, 27 August 2014 at 06:14:10 UTC, Marco Leise wrote:
>> I really think this is the case where you should roll your own FileNoThrowingLogger and go with it.
>
> *Me* or everyone who needs to log something in a dtor?

I really believe that necessity to log something in dtor is currently an indicator of design issues in the application. D class destructors are unreliable to the point of being almost useless, I'd be very careful about actually caring if those run at all.

>> In a long term this is something much better to be fixed in GC implementation than constantly hacked in stdlib modules.
>
> Or is this maybe the other language change (besides not
> generating code for unused lambdas) that should be pushed
> with std.log, because otherwise it will never be solved ?
>
> I don't know, but no logging in dtors is a serious
> and hard to sell limitation. Not the author's fault though.

I agree that current situation is bad but I disagree that std.log is a proper place to solve it. It is a part of much bigger issue and adding few local workarounds does not make situation much better.

On Tuesday, 26 August 2014 at 21:04:28 UTC, Robert burner Schadek wrote:
> On Tuesday, 26 August 2014 at 18:23:31 UTC, Dicebot wrote:
>>
>> I will compare changelist against list of requirements from voters this weekend and if all seems to be addressed will start a new round of review/voting.
>
> sounds good!
> just to note, I will be mostly offline for a good week starting friday.

Ok, going through the list of "No" voters.

====================================
Jakob Ovrum
====================================

"The *API* must support minimal dynamic memory allocation for
the normal execution path. However, theoretical *implementation*
changes that reduce memory allocation are not a deal-breaker."

This seems to be addressed but though it is desired to verify it via @nogc unittest block which uses stub no-op logger (to verify that nothing in between allocates). One place were GC allocations is unavoidable is core.d:1628 - it will always create FileLogger first and allow assigning custom one later. Is there any way to circumvent it?

"API must specify a strong stance on threading, whatever the
form it takes"

Does not seem to be addressed at all. At least I see no mentions of it in core.d documentation and logger instance itself is plain __gshared thing.

$ grep -R -n "shared" std/experimental/logger/
std/experimental/logger/core.d:1625:    static __gshared Logger logger;
std/experimental/logger/core.d:1635:    static __gshared LogLevel ll = LogLevel.all;

Does not seem enough for sure.

"This one might seem unnecessarily strict, but I think the fact
that Logger is a class and not an interface smells of poor
design. I might still be convinced that having it as a class is
justified, but my current stance is that it must be an interface."

Neither does seem to be addressed nor I can find any comment on why it is not going to be addressed.

====================================
Andrei Alexandrescu
====================================

"Minimal logging level must be selected statically in addition to the
current dynamic selection. Static settings preclude dynamic settings.
This is not negotiable."

Seems to be addressed.

"All logging code must be rigorously eliminated if below the static
logging level. More precisely, there must be a front-end optimization
that eliminates all code dedicated to a "lazy" variable that's not used
by a generic function. This would be a fantastic redeeming of the "lazy"
keyword, which has been of marginal utility until now. The challenge
here is cooperating with someone on the compiler team to make sure that
front-end improvement gets implemented, and writing unit tests that make
sure there's no regression later. This is not negotiable."

Seems to be addressed.

"The suffix notations must be replaced with overloads. The only
acceptable suffix is "f" for formatting. Everything else must be
achieved via overloads with the help of template constraints. Robert's
answer http://goo.gl/FehDVh suggests he didn't consider using template
constraints. We can't let that slip become a feature of the library for
millenia to come."

Seems to be addressed.

"Replace defaultLogger with theLog. "Logger" is a word, but one that
means "lumberjack" so it doesn't have the appropriate semantics. The use
is generally acceptable as a nice play on words and as a disambiguator
between the verb "to log" and the noun "log". When we actually want to
talk about the current log in an application, we should, however, call
it "the log". This is negotiable."

Addressed with a name of "stdlog".

"I'm still hoping for RefCounted as the storage for the class backend.
I realize users can do their own management but log objects are unlikely
to contain cycles and other liabilities for reference counting, and at
some point if we want to use reference counting where appropriate we got
to start somewhere with a few solid precedents. This is negotiable, but
I plan to fight for it."

Can't see any traces of RefCounted in sources though I may have missed change of mind in PR discussion (sorry it is too huge to pay regular attention)

====================================
Casey
====================================

"However, I wanted to address the suffix notation as
I suggested it.  What I was going for was consistency with the
write/writef method signatures to keep things consistent.  I felt
it would be good to make the two similar since they do similar
things."

Obsolete with overload-based resolution

====================================
Francesco Cattoglio
====================================

"As far as I undestood, there's no way right now to do logging
without using the GC. And that means it is currently impossible
to log inside destructor calls. That is a blocker in my book."

First part partially addressed - missing @nogc @nothrow logger implementation out of the box. Considering this request does not go very well with current language implementation it may be ignored for now but official stance about it must be clearly documented.

====================================
Byron Heads
====================================

"We need to hammer out how this will work inside libraries.  If my app is
using multiple libraries I need to know I have full control of how they
log and where (), and if I write libraries I need to include logging that
will not affect performance or added dependencies.

I like the idea of a standard interface for D logging.  Other logging
implementations should be able to plug into the interface without having
to inherit from std.log.Logger (single inheritance issue).

I would like to see conditional logging as part of the interface, or in
the documentation show how we can achieve that with stdlib in a clean and
simple way."

Addressed.

"Logger should include a shared Logger, or include it in the interface for
outside libraries to handle the implementation.  There will be libraries
that thread internally and will need to support shared logging."

Is not addressed.