July 29, 2014
On 7/29/14, 3:25 PM, Robert burner Schadek wrote:
> On Tuesday, 29 July 2014 at 22:15:18 UTC, linkrope wrote:
>> Have a look at
>> https://github.com/linkrope/log/blob/master/src/log.d#L55-66 for the
>> overloading.
>>
>> It's much cleaner than the 'static if' sequences.
>
> of course, because you are doing much less

The idea would be to push the static ifs from inside the function into the template constraints. -- Andrei
July 30, 2014
On Tue, Jul 29, 2014 at 04:55:04PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 7/29/14, 4:16 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Tue, Jul 29, 2014 at 11:09:27PM +0000, Robert burner Schadek via Digitalmars-d wrote:
> >>On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu wrote:
> >[...]
> >>>4. Replace defaultLogger with theLog. "Logger" is a word, but one that means "lumberjack" so it doesn't have the appropriate semantics.  The use is generally acceptable as a nice play on words and as a disambiguator between the verb "to log" and the noun "log". When we actually want to talk about the current log in an application, we should, however, call it "the log". This is negotiable.
> >>
> >>I really don't care how a global Logger instance is called. Anyone else has an opinion on this? Otherwise Andrei wins.
> >[...]
> >
> >I propose 'stdlog'.
> 
> I thought of the same but then rejected it - stdlog looks like offering the same interface as stdout and stderr. Nevertheless it's a sensible choice, too. -- Andrei

I don't like 'theLog'. What about 'defaultLog'?


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze
July 30, 2014
On 7/29/14, 4:09 PM, 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

In all likelihood I misunderstood you! Whenever a LogLevel is passed explicitly there's no static complete elimination possible as you mentioned.

I now see a bunch of versions: DisableXxx (5 total) and DisableBelowXxx (5 total). That's fine if a bit out of character with the simplicity of the rest of the library.

> If you disabled one on the names logging functions at CT other
> prototypes will be used that have no lazy in it. You said that empty
> functions with lazy parameter are not optimized away. So there are no
> empty functions with lazy parameter if you disable these functions. As
> soon as the compiler can kill empty functions with lazy arguments this
> branching can be removed without any user code adjustment.

No, they should stay lazy. The code of the lambdas is still generated, that's the main problem.

As a matter of policy I'd rather push std.log and the compiler improvement together. Otherwise we push std.log and then nobody fixes the compiler, ever. We must put pressure on the compiler folks.

> Overloads are implemented in the current version. They behave as you
> described.

Awesome!

>> 5. I was hoping for a resolution on throttling. However, now I realize
>> that conditional logging plus throttling functions that return true
>> once in a while should work acceptably well. Higher-order functions
>> taking lambdas that log would also be a nice possibility. So... no
>> request here.
>
> Creating a std.logger.conditions module is on my todo,
> std.logger.(stderr,stdout) will be cut because of being to noisy. I'm
> thinking of
> * anyN
> * anyNmillisec
> * firstN
> * ...

Prolly these are good outside of logger, they have wider applicability.

>> 6. I'm still hoping for RefCounted as the storage for the class
>> backend. I realize users can do their own management but log objects
>> are unlikely to contain cycles and other liabilities for reference
>> counting, and at some point if we want to use reference counting where
>> appropriate we got to start somewhere with a few solid precedents.
>> This is negotiable, but I plan to fight for it.
>
> IMO something is wrong in the users code if the GC working on Logger
> instances is slowing the code done. The Logger instances properly stay
> around for the length of the programs execution. If you create Logger in
> a tight loop RC will properly slow you down as well.

Agreed. I'm just saying... well what I said: RC should be an obvious default to reach for unless true GC is needed.


Andrei

July 30, 2014
On Wednesday, 30 July 2014 at 00:15:26 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jul 29, 2014 at 04:55:04PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 7/29/14, 4:16 PM, H. S. Teoh via Digitalmars-d wrote:
>> >On Tue, Jul 29, 2014 at 11:09:27PM +0000, Robert burner Schadek via Digitalmars-d wrote:
>> >>On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu wrote:
>> >[...]
>> >>>4. Replace defaultLogger with theLog. "Logger" is a word, but one
>> >>>that means "lumberjack" so it doesn't have the appropriate
>> >>>semantics.  The use is generally acceptable as a nice play on words
>> >>>and as a disambiguator between the verb "to log" and the noun
>> >>>"log". When we actually want to talk about the current log in an
>> >>>application, we should, however, call it "the log". This is
>> >>>negotiable.
>> >>
>> >>I really don't care how a global Logger instance is called. Anyone
>> >>else has an opinion on this? Otherwise Andrei wins.
>> >[...]
>> >
>> >I propose 'stdlog'.
>> 
>> I thought of the same but then rejected it - stdlog looks like
>> offering the same interface as stdout and stderr. Nevertheless it's a
>> sensible choice, too. -- Andrei
>
> I don't like 'theLog'. What about 'defaultLog'?
>
>
> T

+1 for !theLog. I actually like "dlog" because I hate typing but defaultLog would be fine.


/uri
July 30, 2014
On Tuesday, 29 July 2014 at 23:09:28 UTC, Robert burner Schadek wrote:
> On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu wrote:
>> 4. Replace defaultLogger with theLog. "Logger" is a word, but one that means "lumberjack" so it doesn't have the appropriate semantics. The use is generally acceptable as a nice play on words and as a disambiguator between the verb "to log" and the noun "log". When we actually want to talk about the current log in an application, we should, however, call it "the log". This is negotiable.
>
> I really don't care how a global Logger instance is called. Anyone else has an opinion on this? Otherwise Andrei wins.

I don't see anything wrong with "logger". A "driver" is something that drives (a device), a "logger" is something that logs. Just "log" would be ok, too. Both are in common use, and are terms that I would use intuitively.

"defaultLogger" or "currentLogger" might also be ok, but don't read as nicely. But please not "theLogger".
July 30, 2014
Yes for inclusion into std.experimental
July 30, 2014
"Marc Schütz" " wrote in message news:igznybcggsqgfhmmymrd@forum.dlang.org...

> I don't see anything wrong with "logger". A "driver" is something that drives (a device), a "logger" is something that logs. Just "log" would be ok, too. Both are in common use, and are terms that I would use intuitively.
>
> "defaultLogger" or "currentLogger" might also be ok, but don't read as nicely. But please not "theLogger".

I agree with this too.  All of it. 

July 30, 2014
On Wednesday, 30 July 2014 at 12:01:21 UTC, Daniel Murphy wrote:
> "Marc Schütz" " wrote in message news:igznybcggsqgfhmmymrd@forum.dlang.org...
>
>> I don't see anything wrong with "logger". A "driver" is something that drives (a device), a "logger" is something that logs. Just "log" would be ok, too. Both are in common use, and are terms that I would use intuitively.
>>
>> "defaultLogger" or "currentLogger" might also be ok, but don't read as nicely. But please not "theLogger".
>
> I agree with this too.  All of it.

+1. theLog seems unintuitive to me. It's not like Logger is some kind of singleton, the global merely holds the default (!) instance.

On a note less related to bikes, could anybody explain to me why a name is something natural to a logger? In other words, why does it make sense to complicate the entire design with this instead of just using either a set (in place of a map) in MultiLogger or at least keeping the whole name concept local to it?

Cheers,
David
July 30, 2014
On Wednesday, 30 July 2014 at 14:25:49 UTC, David Nadlinger wrote:
> On a note less related to bikes, could anybody explain to me why a name is something natural to a logger? In other words, why does it make sense to complicate the entire design with this instead of just using either a set (in place of a map) in MultiLogger or at least keeping the whole name concept local to it?
>
> Cheers,
> David

In addition:
The setter property for the name of the logger together with the sorting of loggers by name and 'assumeSorted' will cause trouble.
July 30, 2014
On 7/30/14, 2:22 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Tuesday, 29 July 2014 at 23:09:28 UTC, Robert burner Schadek wrote:
>> On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu wrote:
>>> 4. Replace defaultLogger with theLog. "Logger" is a word, but one
>>> that means "lumberjack" so it doesn't have the appropriate semantics.
>>> The use is generally acceptable as a nice play on words and as a
>>> disambiguator between the verb "to log" and the noun "log". When we
>>> actually want to talk about the current log in an application, we
>>> should, however, call it "the log". This is negotiable.
>>
>> I really don't care how a global Logger instance is called. Anyone
>> else has an opinion on this? Otherwise Andrei wins.
>
> I don't see anything wrong with "logger". A "driver" is something that
> drives (a device), a "logger" is something that logs.

Such logic doesn't apply to vocabularies. Is an "irater" someone who irates, a "messer" someone who creates a mess etc?

> Just "log" would
> be ok, too. Both are in common use, and are terms that I would use
> intuitively.
>
> "defaultLogger" or "currentLogger" might also be ok, but don't read as
> nicely. But please not "theLogger".

Sure not, it's theLog. I'm okay with stdlog.


Andrei

1 2 3 4 5 6 7 8 9 10 11 12 13 14