July 30, 2014
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
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
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
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
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
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
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
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
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
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...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16