On Saturday, 30 August 2014 at 02:11:49 UTC, Dicebot wrote:
On Tuesday, 26 August 2014 at 21:04:28 UTC, Robert burner
Schadek wrote:
====================================
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.
I working on this
"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.
Every Logger has to have a LogLevel, interfaces won't work there
====================================
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.
at least for logf nothrow will not work because of a wrong
formatting string or args. log can not be nothrow because custom
toString for structs and class are allowed.
nogc is not possible because of custom toString
that won't fix, but for default types it is nogc.
====================================
Byron Heads
====================================
"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.
See Jakob Ovrun
