July 13, 2014
On Sunday, 13 July 2014 at 16:44:21 UTC, Dragos Carp wrote:
>>>
>
> Sorry that I didn't described how logFirstN and logEveryN work.
>
> Let say you output a log in a loop with 100 iterations.
> logFirstN(10, ...) outputs the log message just for the first 10
> iterations, and logEveryN(10, ...)  outputs only for 1st, 11th,
> 21st, .. and 91st iterations.

I know how they work. apart from my foreach brain frat. But what do you think is logc for.
July 13, 2014
>
> If we get rid of the write style variant, then you need to remember just one name with 4 overloads:
>
> log(string message);
> log(string format, Args...);
> log(bool condition, string message);
> log(bool condition, string format, Args...);
>
>
But you would also have to remember that log(...) behaves like writef(...)
and not write(...)

Having consistency with the already existing write methods is a good thing.
 And having both options is useful, as some prefer one over the other (and
you can do more interesting logging things with a list of items to log when
you aren't restricted by a format string).

On the conditional log methods: +1 to not having them, I believe that they are more complicating than useful.  They muddy the responsibility of logging, putting program logic along with log level configuration to decide what to log.  They are an easy thing to add as an extension to the logging library, no need to include them in the base logging API.


July 13, 2014
>
> Having consistency with the already existing write methods is a good thing.
>  And having both options is useful, as some prefer one over the other (and
> you can do more interesting logging things with a list of items to log when
> you aren't restricted by a format string).

Could you provide an example?

>
> On the conditional log methods: +1 to not having them, I believe that they
> are more complicating than useful.

+1 for not having the conditional log
July 13, 2014
>
> Could you provide an example?


If you decouple the things being logged from the actual logged string, you can do stuff like have different log sinks format things differently, or even filter what appears in the log line as needed.

For example, you could have a setup with logging going to two separate files.  One used for auditing, which only contains the bare timestamp and log message, and the other for debugging that contains all the things verbosely.  Or filter the output to any log sink based on circumstances (prod vs. dev, etc).  You write your code to give all the context to the logger, and let the logging figure out what belongs where.  This can be especially important when the log output has to conform to existing systems, and you don't want to change every logging call.

Basically, limiting to string format logging limits to thinking of logging as purely strings.  Using an API of 'list of items' decouples it to the more abstract 'logging stuff', with the actual string only mattering for final output.


Logically, I look at the formatting version as a convenience version of a one-argument call to the non-formatting version.  So:

logf("some %s other %s", foo, bar)

is like

log(format("some %s other %s", foo, bar), <other stuff>)

where the 'other stuff' may be formatted as required by logging configuration, and is not possible with the logf version.

logf(string msg, ...stuff to put in message)
log(string msg, ...stuff to log with message)


July 13, 2014
> Basically, limiting to string format logging limits to thinking of logging
> as purely strings.  Using an API of 'list of items' decouples it to the
> more abstract 'logging stuff', with the actual string only mattering for
> final output.

This is really valid point.
There is still a problem: the analogy, that log/logf is similar
to write/writef, is not right anymore. Please correct me if I'm
wrong... but AFAIK write converts every argument to string and
the output device has no mean to choose a preferred
representation of the arguments.

It will be a surprise if I replace
   log(a, b, c);
with
   logf("%s%s%s", a, b, c);
and possibly get different results.
July 14, 2014
On 13/07/14 17:16, Dicebot wrote:

> Because starting with documentation in Phobos and than proceeding with
> convincing Walter to add built-in support for such idiom is much more
> realistic way than the other way around ;)

"built-in" as in built-in to the language?

-- 
/Jacob Carlborg
July 14, 2014
On Monday, 14 July 2014 at 09:10:36 UTC, Jacob Carlborg wrote:
> On 13/07/14 17:16, Dicebot wrote:
>
>> Because starting with documentation in Phobos and than proceeding with
>> convincing Walter to add built-in support for such idiom is much more
>> realistic way than the other way around ;)
>
> "built-in" as in built-in to the language?

Yes, something like separate "partially static" import type.
July 14, 2014
On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote:
> Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger

I guess this is possible with the proposal, but I'd like to see structured logging in the runtime and in a way that is compatible with existing services, so that all libraries use the same logging infrastructure and such  a way that it can be redirected easily without rewriting any logging calls.

E.g. when building a service on AppEngine you log to a buffer of 1+GB for all your servers implemented in various languages and can do structured searching by type: (debug, info, warning, error, critical), time:real representing seconds since epoch, and message: string. However, since system level "debug" is higher level than language level "debug" there should be several levels below "debug" used in libraries and frameworks that is kept in-memory only to avoid spamming the global application/system level debug-logging.

Having a flexible language level logging mechanism is good, but making sure it fits into existing logging-frameworks (that cannot be modified) is more important and what it should be evaluated against.
July 14, 2014
On 07/14/2014 01:07 PM, via Digitalmars-d wrote:
> On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote:
>> Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger
>
> I guess this is possible with the proposal, but I'd like to see structured logging in the runtime and in a way that is compatible with existing services, so that all libraries use the same logging infrastructure and such  a way that it can be redirected easily without rewriting any logging calls.
>
> E.g. when building a service on AppEngine you log to a buffer of 1+GB for all your servers implemented in various languages and can do structured searching by type: (debug, info, warning, error, critical), time:real representing seconds since epoch, and message: string. However, since system level "debug" is higher level than language level "debug" there should be several levels below "debug" used in libraries and frameworks that is kept in-memory only to avoid spamming the global application/system level debug-logging.
>
> Having a flexible language level logging mechanism is good, but making sure it fits into existing logging-frameworks (that cannot be modified) is more important and what it should be evaluated against.
? could you rephrase, I can not grasp your point (points)
July 14, 2014
On Sunday, 13 July 2014 at 12:18:40 UTC, Jacob Carlborg wrote:
> On 2014-07-13 13:57, Robert burner Schadek wrote:
>
>> Anyone else?
>
> I agree with Sönke.
>
>> if I change it back, people will argue that that is redundant and
>> unintuitive. Than I will change it back again and the discussion starts
>> again.
>
> "logError" is a lot more clear and descriptive. I think that's important. If people don't like that they can use an alias.

I see a lot of people pushing for opposite changes that would make Robert make full circle:
- info/warning/error cs logInfo/logWarning/logError
- infof/warnf/errorf vs info/warn/error (formatted the default)
- removing conditionals overloads vs having conditional overloads with own name vs having conditional overloads with same name

Not everyone will ever get satisfied.