July 30, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, 30 July 2014 at 18:08:12 UTC, Andrei Alexandrescu wrote:
> On 7/30/14, 10:50 AM, linkrope wrote:
>> On Wednesday, 30 July 2014 at 17:01:39 UTC, Andrei Alexandrescu wrote:
>>> On 7/30/14, 8:16 AM, Kagamin wrote:
>>>> On Wednesday, 30 July 2014 at 14:59:38 UTC, Andrei Alexandrescu wrote:
>>>>> Such logic doesn't apply to vocabularies.
>>>>
>>>> According to my vocabulary, a logger is something that logs. Didn't hear
>>>> about irater, and messer sounds like a German word.
>>>
>>> Yah but the log object, i.e. the thing you log things in (the paper
>>> log on a ship etc) is "a log", not "a logger". A "logger" would be the
>>> person writing into the log.
>>>
>>> So the appropriate name for the default log object is "defaultLog" not
>>> "defaultLogger", or "stdlog" not "stdlogger". The better choice is
>>> also shorter.
>>>
>>>
>>> Andrei
>>
>> Even shorter would be "log".
>> That would be better than enabling
>>
>> log.info(...);
>>
>> via the already proposed
>>
>> import log = std.logger;
>>
>> The only obstacle is the current "log" function.
>> But do we really need the free log functions? For UFCS?
>>
>> Otherwise
>>
>> alias info = log.info;
>>
>> would do the trick.
>
> But here we're discussing the name of the default log object... -- Andrei
Yes: most of the time I should be happy with the default log object.
Call it "log" and the uses look great:
log.error("something went wrong");
|
July 30, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to linkrope | On 7/30/14, 11:23 AM, linkrope wrote:
> Yes: most of the time I should be happy with the default log object.
> Call it "log" and the uses look great:
>
> log.error("something went wrong");
Yah but then we have stuttering such as log.log("ehm") which is oddly the same as log("ehm"). -- Andrei
|
July 31, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, 30 July 2014 at 17:01:39 UTC, Andrei Alexandrescu wrote:
> Yah but the log object, i.e. the thing you log things in (the paper log on a ship etc) is "a log", not "a logger". A "logger" would be the person writing into the log.
Logging to a paper log is done directly without a logger. A similar approach would be to use just printf - logging can be done this way, but the reason for a logger is to let people not write to console directly, but use an intermediate component, which manages logging.
|
July 31, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei Alexandrescu wrote:
> Yah but then we have stuttering such as log.log("ehm") which is oddly the same as log("ehm").
log.write
log.writef
|
July 31, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Thursday, 31 July 2014 at 07:13:37 UTC, Kagamin wrote:
> On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei Alexandrescu wrote:
>> Yah but then we have stuttering such as log.log("ehm") which is oddly the same as log("ehm").
>
> log.write
> log.writef
And with
alias writef opCall;
(from the previous std.log proposal) it could also be
log("ehm");
|
July 31, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On 7/31/14, 12:13 AM, Kagamin wrote:
> On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei Alexandrescu wrote:
>> Yah but then we have stuttering such as log.log("ehm") which is oddly
>> the same as log("ehm").
>
> log.write
> log.writef
Then you have the globals write and writef which will compete with those in std.stdio. -- Andrei
|
August 01, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 07/29/2014 07:11 AM, Dicebot wrote: > 1) Yes / No for inclusion into std.experimental > > At this point please consider if module has functionality you want to > see in standard library in general and if implementation is not > fundamentally broken. This is a simple sanity check. Not yet > > 2) Yes / No for inclusion into Phobos in its current state > No, as much as I'd like to have logging facilities in phobos, there are too many outstanding issues. > This is where you should summarize your concerns raised during review if > there are any and make decision if existing API / architecture are > promising enough to be set in stone via Phobos inclusion. > > 3) If you have answered "No" for (2) : list of mandatory changes that > are needed to make you vote "Yes" Get rid of the 8 different suffixes. I only see the need for log and logf, why is the rest needed? log -> log(lazy Args args); logl -> log(LogLevel, lazy Args args); logf -> logf(string fmt, lazy Args args); loglf -> logf(LogLevel, string fmt, lazy Args args); logc -> if (cond) log(lazy Args args); loglc -> if (cond) log(LogLevel, lazy Args args); logcf -> if (cond) log(string fmt, lazy Args); loglcf -> if (cond) log(LogLevel, string fmt, lazy Args); You cannot use version identifiers to selectively disable functionality or people would have to compile their own phobos library for every set of version combinations. Support duck-typing for the log functions. Logger should be a concept and log functions should be free-standing UFCS functions that take any `isLogger!T`. To support a global `defaultLog` variable, you could add a Logger interface and a loggerObject shim. See http://dlang.org/phobos/std_range.html#inputRangeObject for this a pattern. The code could be consolidated and some classes could go. This would probably result in 1-2KLOC, so this could be a single module instead of a package. > > 4) Any additional comments for author. > > Please separate (3) from (4) in some obvious fashion to make it possible > for author to prioritize of feedback. Please use linked thread for > discussions and only post vote + summary here. > > Currently only answer for (1) affects the voting outcome. Other answers > are necessary to eventually prepare std.logger for second voting during > beta period of some future release (for actual inclusion into Phobos). > > If you have any comments / proposals about actual voting procedure or > review process please create separate thread. > > Go ahead ;) |
August 01, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On 7/31/14, 7:19 PM, Martin Nowak wrote:
> You cannot use version identifiers to selectively disable functionality
> or people would have to compile their own phobos library for every set
> of version combinations.
Wait, doesn't code work with the version chosen by the user? -- Andrei
|
August 01, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert burner Schadek | On 07/30/2014 01:09 AM, Robert burner Schadek wrote: > > I'm not sure how you except log(LogLevel.xxxx, "Hello world") to be > disabled at compile time if LogLevel.xxxx is a runtime value? Or do I > misunderstood you? > > you can choose to disable name based logging like trace("Hello trace") > at CT with the current release Here is a proof of concept to achieve this. http://dpaste.dzfl.pl/95fb6a4e086d It works by creating a different type for each loglevel. |
August 01, 2014 Re: Voting: std.logger | ||||
---|---|---|---|---|
| ||||
Posted in reply to linkrope | On Thursday, 31 July 2014 at 09:07:07 UTC, linkrope wrote:
> On Thursday, 31 July 2014 at 07:13:37 UTC, Kagamin wrote:
>> On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei Alexandrescu wrote:
>>> Yah but then we have stuttering such as log.log("ehm") which is oddly the same as log("ehm").
>>
>> log.write
>> log.writef
>
> And with
>
> alias writef opCall;
>
> (from the previous std.log proposal) it could also be
>
> log("ehm");
log.note()
log.say()
What about dlog?
dlog.note()
dlog.log()
dlog.say()
It is short and it is D...
|
Copyright © 1999-2021 by the D Language Foundation