On Wednesday, 15 October 2014 at 10:12:56 UTC, Jakob Ovrum wrote:
> 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...

Yes, because other people already complained that nobody will every need a logarithmic time MulitLogger and I always thought that MultiLogger was to complex anyway. I could make the Logger[] array alias this and it would be comforming to Phobos container, but that doesn't really solve the issue does it.

Will start review round in ~2 days.

I am very sorry for delay :(

On Saturday, 11 October 2014 at 13:34:29 UTC, Robert burner Schadek wrote:
> All that code is contained in 30 line template, That is by far the best working option anybody could come up with
>>
>> I even proposed an alternative that uses type tags instead.
>> http://dpaste.dzfl.pl/95fb6a4e086d
>
> And I showed that it did not work.

I never got a reply on this. Let's please try to solve this problem.
Depending on the leakage of version identifiers from client to library code (only templates) has severe issues. For example a template isn't reinstantiated, if it was already instatiated in another module (allinst switch). Also version identifiers work globally so you'll probably turn on logging in all libraries you use.
http://forum.dlang.org/post/lrf362$tkn$1@digitalmars.com

>> - Documentation is out of sync.
> gh-page is yes, give me 15min
>
Thanks

On Sunday, 12 October 2014 at 12:06:44 UTC, Robert burner Schadek wrote:
>> 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

I don't understand your answer. Do you have a link to your last response.

On Friday, 24 October 2014 at 10:59:43 UTC, Martin Nowak wrote:
>> And I showed that it did not work.
>
Found it http://forum.dlang.org/post/hmzfcxlafwlgoovuweak@forum.dlang.org

On Friday, 24 October 2014 at 11:01:40 UTC, Martin Nowak wrote:
> On Sunday, 12 October 2014 at 12:06:44 UTC, Robert burner Schadek wrote:
>>> 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
>
> I don't understand your answer. Do you have a link to your last response.

You can not tell if the Logger will log a message, because you can't know its LogLevel. It is not thread safe because the interface can't have an implementation. Therefore the default implementation is not thread safe.

On Friday, 24 October 2014 at 09:53:57 UTC, Dicebot wrote:
> Will start review round in ~2 days.
>
> I am very sorry for delay :(

No problem the PR has been open since Aug. 2013, one or two weeks more or less don't really matter anymore ;)

Jut for the reference, my position on current state of things as review manager is this:

I agree with some of mentioned concerns and would like to see those fixed. However, I don't think any of those are truly critical and this proposal has been hanging there for just too long. In my opinion it will be more efficient to resolve any remainining issues in follow-up pull requests on case by case basis then forcing Robert to do it himself - there will be some time left before next release to break a thing or two before public statement is made.

Because of that I am going to start voting despite some arguments being still in process. I hope that won't cause any tension.

On 2014-10-25 18:43, Dicebot wrote:
> Jut for the reference, my position on current state of things as review
> manager is this:
>
> I agree with some of mentioned concerns and would like to see those
> fixed. However, I don't think any of those are truly critical and this
> proposal has been hanging there for just too long. In my opinion it will
> be more efficient to resolve any remainining issues in follow-up pull
> requests on case by case basis then forcing Robert to do it himself -
> there will be some time left before next release to break a thing or two
> before public statement is made.
>
> Because of that I am going to start voting despite some arguments being
> still in process. I hope that won't cause any tension.

As long as the changes don't require a complete redesign. There was some talk about using templates instead of classes.

-- 
/Jacob Carlborg

On 10/25/2014 06:43 PM, Dicebot wrote:
> Because of that I am going to start voting despite some arguments being
> still in process. I hope that won't cause any tension.

The dependency on external version identifiers in phobos is still a complete bummer and there are still many implementation issues.
One reason why this is taking so long is that there were many issues some of which still need to be addressed.