August 26, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | 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.
|
August 26, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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 |
August 26, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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) {}
}
}
--------------
|
August 26, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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.
|
August 27, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | 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 |
August 27, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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.
|
August 27, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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 |
August 27, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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. |
August 28, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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. |
August 30, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | 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. |
Copyright © 1999-2021 by the D Language Foundation