July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | On Tuesday, 29 July 2014 at 12:18:31 UTC, Robert burner Schadek wrote:
> maybe we should have made a vote for logc vs. log(bool) first
>
> I think we gone full circle ulong.max times by now ;-)
This shouldn't affect inclusion to std.experimental and can be done at any moment
|
July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Tuesday, 29 July 2014 at 05:11:33 UTC, Dicebot wrote: > 1) Yes / No for inclusion into std.experimental Yes, absolutely. > 2) Yes / No for inclusion into Phobos in its current state Not yet. > 3) If you have answered "No" for (2) : list of mandatory changes that > are needed to make you vote "Yes" As far as I undestood, there's no way right now to do logging without using the GC. And that means it is currently impossible to log inside destructor calls. That is a blocker in my book. > 4) Any additional comments for author. No matter the changes that might be applied to reduce suffix notation, I would love to retain the ability to do conditional unformatted logging. |
July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Tue, 29 Jul 2014 05:11:31 +0000, Dicebot wrote: > 1) Yes / No for inclusion into std.experimental Yes > 2) Yes / No for inclusion into Phobos in its current state No see notes in (3) > 3) If you have answered "No" for (2) : list of mandatory changes that > are needed to make you vote "Yes" We need to hammer out how this will work inside libraries. If my app is using multiple libraries I need to know I have full control of how they log and where (), and if I write libraries I need to include logging that will not affect performance or added dependencies. I like the idea of a standard interface for D logging. Other logging implementations should be able to plug into the interface without having to inherit from std.log.Logger (single inheritance issue). I would like to see conditional logging as part of the interface, or in the documentation show how we can achieve that with stdlib in a clean and simple way. Logger should include a shared Logger, or include it in the interface for outside libraries to handle the implementation. There will be libraries that thread internally and will need to support shared logging. > 4) Any additional comments for author. Awesome work so far. Getting this "right" is I huge pain, and I applaud you going through this. |
July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Byron Heads | > Awesome work so far. Getting this "right" is I huge pain, and I applaud
> you going through this.
I should have said this as well. Regardless, I second this statement as this is probably the thing I'm looking forward to the most when it comes to additions to the standard library.
|
July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | Yes for experimental. |
July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 7/28/14, 11:46 PM, Dicebot wrote:
> On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu wrote:
>> No in current form. Yes assuming the fixes below are implemented.
>
>> ...
>
>> No. I also think any new module should sit in std.experimental for one
>> release cycle.
>
> Clarification, just to be sure you got it right - right now we _only_
> vote on inclusion into std.experimental, even if majority of voters will
> consider it Phobos-quality. Staging period of one release cycle is
> mandatory.
>
> That said - can you explain a bit more why you think it can't be
> included in std.experimental? (== think that it is fundamentally broken
> to the point it can't be even suggested for experiments) Most issues
> listed seem to be more related to actual Phobos inclusion.
I explained in the non-negotiable points. The point of keeping a module in std.experimental is watching for only minor tweaks. I think e.g. the names in the API is in need of solid change, which is easy to effect but affects callers quite a bit. -- Andrei
|
July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 7/29/14, 5:23 AM, Dicebot wrote:
> On Tuesday, 29 July 2014 at 12:18:31 UTC, Robert burner Schadek wrote:
>> maybe we should have made a vote for logc vs. log(bool) first
>>
>> I think we gone full circle ulong.max times by now ;-)
>
> This shouldn't affect inclusion to std.experimental and can be done at
> any moment
NO.
We put something in std.experimental when we can't imagine what other work is to be done on the module. (Inevitably a little more work is prompted by usage, which is the point of it all.) We don't put in std.experimental stuff that has already a known backlog of work to do.
Andrei
|
July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | On 7/29/14, 5:18 AM, Robert burner Schadek wrote:
> maybe we should have made a vote for logc vs. log(bool) first
>
> I think we gone full circle ulong.max times by now ;-)
My understanding is the entire prefix-letter approach was based on an oversight.
Andrei
|
July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Tuesday, 29 July 2014 at 16:59:51 UTC, Andrei Alexandrescu wrote:
> The point of keeping a module in std.experimental is watching for only minor tweaks.
I agree. For this reason, I also vote for "no" (1 as well as 2), as the current conditional logging support doubles the size of the API for shaving a grand total of 3 characters off the invocation in a rather infrequent use case.
Cheers,
David
|
July 29, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 7/29/14, 10:16 AM, Andrei Alexandrescu wrote:
> On 7/29/14, 5:18 AM, Robert burner Schadek wrote:
>> maybe we should have made a vote for logc vs. log(bool) first
>>
>> I think we gone full circle ulong.max times by now ;-)
>
> My understanding is the entire prefix-letter approach was based on an
> oversight.
>
> Andrei
s/prefix/suffix/
|
Copyright © 1999-2021 by the D Language Foundation