November 03, 2014
I will remove the trusted later this week
November 03, 2014
On Monday, 3 November 2014 at 20:41:14 UTC, Robert burner Schadek wrote:
> I will remove the trusted later this week

After few tweaks (to allows @system toString()) in my branch you should be able to just merge it directly to your PR branch if you are ok with proposed changes.
November 09, 2014
And back to the frontpage.

Martin / Robert, have you managed to come to an agreement on conditional level thing?
November 10, 2014
On Sunday, 9 November 2014 at 21:42:09 UTC, Dicebot wrote:
> And back to the frontpage.
>
> Martin / Robert, have you managed to come to an agreement on conditional level thing?

After your last reply we haven't done anything else.

I would merge his idea, but there is pushback from your side. Anyway, this idea would not break the api. So I don't think it is a blocking change, IMO.
November 10, 2014
On Monday, 10 November 2014 at 11:46:34 UTC, Robert burner Schadek wrote:
> After your last reply we haven't done anything else.
>
> I would merge his idea, but there is pushback from your side. Anyway, this idea would not break the api. So I don't think it is a blocking change, IMO.

kk, I'll try contacting him via e-mail if Martin does not return to this thread soon enough :) This proposal may not break API directly but it greatly affects how derivative libraries are supposed to be designed and distributed so I'd prefer to nail it down immediately.

There are also some more @safe changes need, I hope to provide another branch with those soon enough (~tomorrow)
November 10, 2014
On Monday, 10 November 2014 at 17:03:31 UTC, Dicebot wrote:
> On Monday, 10 November 2014 at 11:46:34 UTC, Robert burner Schadek wrote:
>> After your last reply we haven't done anything else.
>>
>> I would merge his idea, but there is pushback from your side. Anyway, this idea would not break the api. So I don't think it is a blocking change, IMO.
>
> kk, I'll try contacting him via e-mail if Martin does not return to this thread soon enough :) This proposal may not break API directly but it greatly affects how derivative libraries are supposed to be designed and distributed so I'd prefer to nail it down immediately.

I get that

>
> There are also some more @safe changes need, I hope to provide another branch with those soon enough (~tomorrow)

thank you
November 11, 2014
On Monday, 10 November 2014 at 18:32:03 UTC, Robert burner Schadek wrote:
> On Monday, 10 November 2014 at 17:03:31 UTC, Dicebot wrote:
>> There are also some more @safe changes need, I hope to provide another branch with those soon enough (~tomorrow)
>
> thank you

https://github.com/Dicebot/phobos/tree/logger-safety

I think that should be it for now

November 12, 2014
On Tuesday, 11 November 2014 at 15:06:49 UTC, Dicebot wrote:
> https://github.com/Dicebot/phobos/tree/logger-safety
>
> I think that should be it for now

I could have completely missed some details but I took sometime to look at the code after reading that the logger was holding a lock during the write operation. I noticed the following lines.

One shared Logger:
https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L1696

One global function that references that shared Logger:
https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L292

And more importantly a Mutex that is always acquired when writing:
https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L1035

Does this mean that if I use this library on a machine that has 32 cores, 100s of threads and 1000s of fiber only one thread/fiber can write at a time no matter the concrete implementation of my logger? Am I missing something or isn't this a non-starter?

Thanks,
-Jose


November 12, 2014
On Wednesday, 12 November 2014 at 05:36:40 UTC, Jose wrote:
> On Tuesday, 11 November 2014 at 15:06:49 UTC, Dicebot wrote:
>> https://github.com/Dicebot/phobos/tree/logger-safety
>>
> One shared Logger:
> https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L1696
>
> One global function that references that shared Logger:
> https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L292
>
> And more importantly a Mutex that is always acquired when writing:
> https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L1035
>
> Does this mean that if I use this library on a machine that has 32 cores, 100s of threads and 1000s of fiber only one thread/fiber can write at a time no matter the concrete implementation of my logger? Am I missing something or isn't this a non-starter?
>
> Thanks,
> -Jose

Only one thread can write to one Logger at a time, also known as synchronization. Anything else is properly wrong. But you can have as many Logger as you have memory.
November 12, 2014
On Wednesday, 12 November 2014 at 12:39:24 UTC, Robert burner Schadek wrote:
> Only one thread can write to one Logger at a time, also known as synchronization. Anything else is properly wrong. But you can have as many Logger as you have memory.

Taking a lock when the logging call doesn't flush to disk sounds rather expensive.