On Friday, 31 October 2014 at 15:35:55 UTC, Dicebot wrote:
> On Tuesday, 28 October 2014 at 22:03:18 UTC, Martin Nowak wrote:
>> 2nd iteration of that idea.
>
> For me it looks like the cure is worse than the disease. Simply not distributing precompiled libraries with log level force-reduced (or at least not exposing it in provided .di files) feels like a more practical approach than proposed API complication.

There are no .di files in a dub package.
And for certain libraries the runtime overhead for checking log levels isn't acceptable, so we need a non-global way to configure logging of a library.

Am Sat, 15 Nov 2014 02:11:34 +0000
schrieb "Robert burner Schadek" <rburners@gmail.com>:

> On Friday, 14 November 2014 at 23:40:21 UTC, David Nadlinger wrote:
> > On Friday, 14 November 2014 at 22:18:41 UTC, Robert burner Schadek wrote:
> >> Yes, but this way allows to add structured logging in an easy way.
> >
> > What.
> 
> The actual log call is split into multiple parts so that the user can overload logMsgPart and add, for instance, structured logging. In order to not have races with the default impl locking was added.

Somehow I feel like I should be in the firing line here, hehe.
Yes, this is approach to thread-safety isn't the most efficient
imaginable. But it can guarantee thread-safety no matter how
little or much you know about the default logger internals or
what you plan to do with it. The lock also ensures that
public properties like logLevel cannot change while a logger
is working, which could result in log messages being dropped
that should have passed and - as Robert mentioned - ensures
that the 3 structural logging methods are called in order with
no other thread intervening.
I believe it will hit a sweet spot between safe extensibility
and performance.
Benchmarking... Hmm, you can take an uncontested lock
~14.000.000 times per second on Linux @ 2 Ghz with D's
synchronized(...) {} statement and you can append "The quick
brown fox jumps over the lazy dog." ~22.400.000 to an
Appender!(string[]). I begin to understand what you mean by
"noticeable". Somehow I hope that people don't log that much
or that the loggers themselves are sufficiently complex that
they take their time to process each message. But for a
thread-local logger that just appends to a list, it is quite
a bit of unnecessary overhead.

-- 
Marco

On Friday, 14 November 2014 at 23:06:22 UTC, Dicebot wrote:
> On Friday, 14 November 2014 at 22:20:17 UTC, Robert burner Schadek wrote:
>> I will test something this weekend regarding the additional indirection.
>
> Thanks! I may try hacking some sample implementation too but pessimistic about ETA

So, I added a layer of thread local indirection to the Logger. It now goes by default like:

log|trace|... -> threadLocalLogger -> globalLogger

The threadLocalLogger is just another Logger so it can be replaced with whatever you need may need. Or just keep it forwarding.

Anyone know anything about this?

https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac

On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote:
> Anyone know anything about this?
>
> https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac

You are posting to page 16 of the third iteration of a single review.

On 11/24/2014 4:51 PM, Brian Schott wrote:
> On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote:
>> Anyone know anything about this?
>>
>> https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac
>>
>
> You are posting to page 16 of the third iteration of a single review.

I know, and the reddit comment refers to this.

On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote:
> Anyone know anything about this?
>
> https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac

You mean the second part, about him leaving D because of the discussion about the logger?

On Tuesday, 25 November 2014 at 01:12:03 UTC, Walter Bright wrote:
> On 11/24/2014 4:51 PM, Brian Schott wrote:
>> On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote:
>>> Anyone know anything about this?
>>>
>>> https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac
>>>
>>
>> You are posting to page 16 of the third iteration of a single review.
>
> I know, and the reddit comment refers to this.

This discussion is indeed most unsettling to read. Third review of a much-needed module in the ecosystem, and I remember of previous attempts at logging, each time taken down because it does not satisfy the whims of top-tier D developers that would have done it differently (and of course "better").

What is accepted or not in Phobos no longer interest me. I can rely on interesting modules through DUB which has versionned dependencies, while Phobos has not.
Better XML parsers/JSON parsers/serialization/argument parsers exist outside of Phobos currently, and in my opinion maybe they didn't belong there in the first place.

On Tuesday, 25 November 2014 at 14:29:12 UTC, ponce wrote:
> Better XML parsers/JSON parsers/serialization/argument parsers exist outside of Phobos currently, and in my opinion maybe they didn't belong there in the first place.

Yes, it is often a good idea to standardize after solutions have been established.

Creating a good logger is harder than it sounds like as the logger have to used by everyone or else you have to deal with N incompatible versions in the same project due to different libraries using different loggers.

Starting with the interface with no performant proof of concept means you go for a long run. Starting with an existing performant solution and abstracting it into a cleaner interface would reach completion faster and with less risk of hitting gotchas later.

A logger that isn't good enough for just about everyone will become dead weight as people will gravitate towards an external adhoc standard solution instead (re Tango vs Phobos).

On 11/25/2014 2:26 AM, Robert burner Schadek wrote:
> On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote:
>> Anyone know anything about this?
>>
>> https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac
>>
>
> You mean the second part, about him leaving D because of the discussion about
> the logger?

Yes.