November 26, 2014
On Tuesday, 25 November 2014 at 23:41:51 UTC, Walter Bright wrote:
> 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.

Not really, this is the first time I read the name SiCl4. Also google SiCl4 dlang only points to the reddit post.
November 26, 2014
On Tuesday, 25 November 2014 at 23:41:51 UTC, Walter Bright wrote:
> 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.

He wants a "better C" for system level programming:

https://www.reddit.com/r/programming/comments/2n60wv/the_first_enemy_of_c_is_its_past/cmbn1n4

https://www.reddit.com/r/programming/comments/2n60wv/the_first_enemy_of_c_is_its_past/cmb4ows

And there is no doubt an open spot between C and C++ for a modernized system level language.
November 29, 2014
On Tuesday, 25 November 2014 at 14:29:12 UTC, ponce wrote:
> 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").

Things in phobos just have to sit, we already carry around too many crap modules (signals, XML, curl).

> 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.

That's a good thing because a package system can cover different needs with much more variety.

> 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.

I partly agree with this, having certain things covered by 3-rd party libraries allows for faster iteration. Something shpuld only become a Phobos module if there can be definite design which is paired with a very good implementation.
November 29, 2014
On Friday, 14 November 2014 at 21:49:09 UTC, David Nadlinger wrote:
> On Friday, 14 November 2014 at 21:46:00 UTC, Robert burner Schadek wrote:
>> You can always roll your own non locking Logger, but the default should be thread-safe.
>
> You can't, since you need to inherit from Logger, which already does the locking for you in a way that's not overridable. Also, I take it you are familiar with the fact that locks aren't the only technique for achieving cross-thread synchronization.
>

Have you guys resolved this? If we cannot implement a non-locking logger than that's a blocking issue for the library.
November 29, 2014
On Saturday, 29 November 2014 at 14:15:12 UTC, Martin Nowak wrote:
> On Friday, 14 November 2014 at 21:49:09 UTC, David Nadlinger wrote:
>> On Friday, 14 November 2014 at 21:46:00 UTC, Robert burner Schadek wrote:
>>> You can always roll your own non locking Logger, but the default should be thread-safe.
>>
>> You can't, since you need to inherit from Logger, which already does the locking for you in a way that's not overridable. Also, I take it you are familiar with the fact that locks aren't the only technique for achieving cross-thread synchronization.
>>
>
> Have you guys resolved this? If we cannot implement a non-locking logger than that's a blocking issue for the library.

Yes, there is a lock free, thread local indirection now. That can be used to build a lock free, thread local logger.

p.s. You should have taken the phun
November 29, 2014
On 11/29/2014 05:25 PM, Robert burner Schadek wrote:
>
> Yes, there is a lock free, thread local indirection now. That can be
> used to build a lock free, thread local logger.
>
> p.s. You should have taken the phun

I commented on the relevant commit.
https://github.com/burner/phobos/commit/8a3aad5df5218bd995d4679f9b59a59909969b52#diff-59d32a64bcbd4492ff85f10091d73f5fR289

Let me propose a light-weight alternative solution.

```d
abstract class Logger
{
    Object.Monitor mutex;

    this()
    {
        this.mutex = createMutex();
    }

    Object.Monitor createMutex()
    {
        import core.sync.mutex;
        return new Mutex;
    }
}
```

This allows people to override the mutex with whatever fits their bill, e.g. one that supports fiber suspension. Especially they can do this.

Object.Monitor createMutex()
{
    static class NoLock : Object.Monitor
    {
        void lock() nothrow {}
        void unlock() nothrow {}
    }
    return new NoLock;
}

November 30, 2014
On Saturday, 29 November 2014 at 19:18:01 UTC, Martin Nowak wrote:
> On 11/29/2014 05:25 PM, Robert burner Schadek wrote:
>>
>> Yes, there is a lock free, thread local indirection now. That can be
>> used to build a lock free, thread local logger.
>>
>> p.s. You should have taken the phun
>
> I commented on the relevant commit.
> https://github.com/burner/phobos/commit/8a3aad5df5218bd995d4679f9b59a59909969b52#diff-59d32a64bcbd4492ff85f10091d73f5fR289

I missed that final.

>
> Let me propose a light-weight alternative solution.
>
> ```d
> abstract class Logger
> {
>     Object.Monitor mutex;
>
>     this()
>     {
>         this.mutex = createMutex();
>     }
>
>     Object.Monitor createMutex()
>     {
>         import core.sync.mutex;
>         return new Mutex;
>     }
> }
> ```
>
> This allows people to override the mutex with whatever fits their bill, e.g. one that supports fiber suspension. Especially they can do this.
>
> Object.Monitor createMutex()
> {
>     static class NoLock : Object.Monitor
>     {
>         void lock() nothrow {}
>         void unlock() nothrow {}
>     }
>     return new NoLock;
> }

I will add this and remove the final.

Thank you
December 03, 2014
On 10/30/2014 12:11 AM, Robert burner Schadek wrote:
> That can actually be added to the current state of std.logger without
> breaking any api. The string mixin, version string matching isn't really
> pretty, but it gets the job done. Anyway IMO your approach presented
> here and my approach can go hand in hang. Yours should be propagated as
> the idiomatic way and if you really need the crowbar, which you need
> sometimes, use StdLoggerDisableXXXXX.

I just found a very compelling solution to the LogLevel disabling problem.

Basically we can declare a logLevel for each module or package and let the logger do a reverse look up.

```d
module mymod;

import logger;

// can be anything that converts to a LogLevel
// calls with lower log level can be optimized away if this is a compile time constant
// runtime values also work nicely but incur a small overhead
// if this declaration is not present, logLevel from the package is used or a default LogLevel.
enum logLevel = LogLevel.critical;

void foo()
{
    info("information from foo"); // optimized out
    fatal("error"); // works
}
```

https://gist.github.com/MartinNowak/443f11aa017d14007c35

There is a tiny gotcha, this works because the logger module imports the callee module. So we'd need to avoid module constructors in the logger module or use a workaround.
January 06, 2015
recent updates:
* Martins CT log function disabling (thanks Martin)
* new thread local indirection Logger between free standing log functions and program global Logger
* more documentation
* some @trusted have been remove (thanks Dicebot)
* local imports

please review
January 06, 2015
On 1/6/15 8:51 AM, Robert burner Schadek wrote:
> recent updates:
> * Martins CT log function disabling (thanks Martin)
> * new thread local indirection Logger between free standing log
> functions and program global Logger
> * more documentation
> * some @trusted have been remove (thanks Dicebot)
> * local imports
>
> please review

Links for the lazy.

Code:

https://github.com/D-Programming-Language/phobos/pull/1500

Dox:

http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_core.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_filelogger.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_multilogger.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_nulllogger.html


Andrei