Am Sat, 11 Oct 2014 12:23:10 +0000
schrieb "Robert burner Schadek" <rburners@gmail.com>:

> On Saturday, 11 October 2014 at 04:31:17 UTC, Jakob Ovrum wrote:
> > The implementation of `Logger` has several performance problems. `Logger` provides default behaviour that allocates GC memory multiple times for even the simplest log messages through the `Appender`. I don't think this behaviour should be encouraged by putting it in the root logger class, and besides, it can be made much more intelligent than just using a new appender for each message.
> 
> Well, to have ultra simple thread-safe sub classing (which is an important part of the design), this was the price. This being said. Doing it nogc yourself if you know the output is very easy as shown in FileLogger.

I had the same feeling as Jakob about an `Appender` already
in the base class and would have expected a bare bones
abstract class + a batteries included version using `Appender`.
(A bit like Java's …Listener and …Adapter classes.)
That seems more clean to me in a representational fashion.
Technically we can just ignore the extra field...
It also seems legit to reduce pressure on the GC, by resetting
the `Appender` instead of nulling it.

-- 
Marco

On 2014-10-11 15:34, Robert burner Schadek wrote:

>> - Why do loggers have to be classes?
> As answered multiply times before, to build log hierarchies.

What's stopping an interface or class to implement a logging concept?

-- 
/Jacob Carlborg

On Sunday, 12 October 2014 at 09:07:37 UTC, Jacob Carlborg wrote:
> On 2014-10-11 15:34, Robert burner Schadek wrote:
>
>>> - Why do loggers have to be classes?
>> As answered multiply times before, to build log hierarchies.
>
> What's stopping an interface or class to implement a logging concept?

Same as last time:
Logger[], Logger without a LogLevel not real useful IMO, (new) no thread safety by default

On Saturday, 11 October 2014 at 23:37:42 UTC, Marco Leise wrote:
>
> I had the same feeling as Jakob about an `Appender` already
> in the base class and would have expected a bare bones
> abstract class + a batteries included version using `Appender`.
> (A bit like Java's …Listener and …Adapter classes.)
> That seems more clean to me in a representational fashion.
> Technically we can just ignore the extra field...
> It also seems legit to reduce pressure on the GC, by resetting
> the `Appender` instead of nulling it.

What if a Logger down the chain keeps the string around and you overwrite it?

Am Sun, 12 Oct 2014 12:07:55 +0000
schrieb "Robert burner Schadek" <rburners@gmail.com>:

> On Saturday, 11 October 2014 at 23:37:42 UTC, Marco Leise wrote:
> >
> > I had the same feeling as Jakob about an `Appender` already
> > in the base class and would have expected a bare bones
> > abstract class + a batteries included version using `Appender`.
> > (A bit like Java's …Listener and …Adapter classes.)
> > That seems more clean to me in a representational fashion.
> > Technically we can just ignore the extra field...
> > It also seems legit to reduce pressure on the GC, by resetting
> > the `Appender` instead of nulling it.
> 
> What if a Logger down the chain keeps the string around and you overwrite it?

That would be bad.

-- 
Marco

As there was quite some last moment feedback I am giving some more time for me to research issues a bit and Robert to address them :)

On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote:
> As there was quite some last moment feedback I am giving some more time for me to research issues a bit and Robert to address them :)

The Pareto Principle could be worth mentioning here. We were 80% of the way to a quality interface a long time ago, but the last 20% is taking a disproportionate amount of time to iron out. I think all this criticism is indicative that we're holding this module to a high standard rather than the code being bad, which I think is a very good thing. Thankfully Marco stepped up and provided a solution to the threading problem, so I don't think it's that far off.

Apropos threading though, I'm not sure how to consolidate the fact that we're using shared memory without using `shared`. It seems like a failure to have such an intricately designed memory model, then as soon as we do threading in Phobos, we ignore it.

I still intend to go through all the documentation and fix things I can spot as soon as the interface is finalized.

On Wednesday, 15 October 2014 at 03:45:12 UTC, Jakob Ovrum wrote:
> On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote:
>
> Apropos threading though, I'm not sure how to consolidate the fact that we're using shared memory without using `shared`. It seems like a failure to have such an intricately designed memory model, then as soon as we do threading in Phobos, we ignore it.

I've written several times that having the TDPL Concurrency chapter as a free link in the main page it's some sort of horrible masochism, granted the current state of the implementation of what it's described there...

But well ;-/
---
/Paolo

On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote:
> As there was quite some last moment feedback I am giving some more time for me to research issues a bit and Robert to address them :)

No need, I fixed the MultiLogger last weekend.

On Wednesday, 15 October 2014 at 09:25:07 UTC, Robert burner Schadek wrote:
> On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote:
>> As there was quite some last moment feedback I am giving some more time for me to research issues a bit and Robert to address them :)
>
> No need, I fixed the MultiLogger last weekend.

"Fixed" by simply removing the attempt at logarithmic time operations, and still not conforming to the Phobos container interface...