On 8/30/14, 4:42 PM, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Aug 30, 2014 at 01:37:15PM +0000, Dicebot via Digitalmars-d wrote:
>> On Saturday, 30 August 2014 at 13:35:57 UTC, H. S. Teoh via Digitalmars-d
>> wrote:
>>>>> How do the remaining issues break down into QoI that can be >deferred
>>>>> to a future release? -- Andrei
>>>>
>>>> What is QoI? I am not familiar with this abbreviation
>>>
>>> Quality of Implementation.
>>
>> And how can one break issues into quality of implementation? :O I have
>> literally no idea what Andrei means.
>
> I'm guessing he means, break them down into must-solve-before-merge
> issues and stuff-to-be-fixed-later issues.

Correct. (I'm on vacation with scarce online access.) -- Andrei

On Saturday, 30 August 2014 at 20:53:58 UTC, Andrei Alexandrescu wrote:
> Correct. (I'm on vacation with scarce online access.) -- Andrei

With API stability in mind defining official stance on multi-threading in most important part. Rest can be added with small to none breaking changes.

I've got some questions:

How does logging interact with pure? You need to be able to log in pure functions.

Does the logger implementation flush() in the case of a crash? (Does it trap all crashes in a way that ensures that  logging buffers are written to disk?)

Is logf() needed? Can't you somehow detect that the string is an immutable string literal with string formatting characters?

Am Sun, 31 Aug 2014 01:09:32 +0000
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang@gmail.com>:

> I've got some questions:
> 
> How does logging interact with pure? You need to be able to log in pure functions.

How do you come to that conclusion? Purity is a synonym for _not_ having side effects. That said - as usual - "debug" statements allow you to punch a hole into purity.

> […]
> 
> Is logf() needed? Can't you somehow detect that the string is an immutable string literal with string formatting characters?

1) The first argument does not need to be a literal.
2) Checking the first argument for formatting chars slows the
   system down.
3) If you want to log a regular string, e.g. an incoming HTTP
   request or something that contains formatting symbols, log()
   would throw an exception about a missing second argument.
   This in turn could become a DOS vulnerability.

Other than that, you could create an additional log function that only accepts compile-time known formatting strings as a CT argument and verifies the runtime argument types at the same time.

-- 
Marco

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.

FWIW:

https://www.google.com/search?q=logger

Here's the results I see:

8 results related to programming and log files

1 Wikipedia disambiguation page

1 sports-related result ("La Crosse Loggers")

On Sunday, 31 August 2014 at 06:11:56 UTC, Marco Leise wrote:
> Am Sun, 31 Aug 2014 01:09:32 +0000
> schrieb "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang@gmail.com>:

>> How does logging interact with pure? You need to be able to log in pure functions.
>
> How do you come to that conclusion? Purity is a synonym for
> _not_ having side effects. That said - as usual - "debug"
> statements allow you to punch a hole into purity.

1. ~90% of all functions are weakly pure, if you cannot log execution in those functions then logging becomes a liability.

2. If you define logging in a weakly pure function as tracing of execution rather than logging of state, then you can allow memoization too.

3. You don't normally read back the log in the same execution, state is thus not preserved through logging within a single execution. It has traits which makes it less problematic than general side effects that change regular global variables.

Am Sun, 31 Aug 2014 08:52:58 +0000
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang@gmail.com>:

> On Sunday, 31 August 2014 at 06:11:56 UTC, Marco Leise wrote:
> > Am Sun, 31 Aug 2014 01:09:32 +0000
> > schrieb "Ola Fosheim Grøstad"
> > <ola.fosheim.grostad+dlang@gmail.com>:
> 
> >> How does logging interact with pure? You need to be able to log in pure functions.
> >
> > How do you come to that conclusion? Purity is a synonym for _not_ having side effects. That said - as usual - "debug" statements allow you to punch a hole into purity.
> 
> 1. ~90% of all functions are weakly pure, if you cannot log execution in those functions then logging becomes a liability.
>
> 2. If you define logging in a weakly pure function as tracing of execution rather than logging of state, then you can allow memoization too.

Ok, here is the current state: Logging is not a first-class
language feature with special semantics. Drop your "pure"
keywords on those 90% of functions or only log in "debug".

> 3. You don't normally read back the log in the same execution, state is thus not preserved through logging within a single execution. It has traits which makes it less problematic than general side effects that change regular global variables.

I still don't see it fly even theoretically. The "stdlog" will
be an interface with an arbitrary implementation behind it. A
file logger will eventually hit a "disk full" state and throw
an exception. Since "pure" implies that a function call can be
elided such a change of execution path cannot work.
It is much like discussing the strictness of transitive const.
If you need to cache values of initialize on first access, you
just have to drop const.

-- 
Marco

On Sunday, 31 August 2014 at 09:34:51 UTC, Marco Leise wrote:
> Am Sun, 31 Aug 2014 08:52:58 +0000
> schrieb "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang@gmail.com>:
>
>> On Sunday, 31 August 2014 at 06:11:56 UTC, Marco Leise wrote:
>> > Am Sun, 31 Aug 2014 01:09:32 +0000
>> > schrieb "Ola Fosheim Grøstad"
>> > <ola.fosheim.grostad+dlang@gmail.com>:

> I still don't see it fly even theoretically. The "stdlog" will
> be an interface with an arbitrary implementation behind it. A
> file logger will eventually hit a "disk full" state and throw
> an exception.

Why would that be the sole outcome? There are several strategies to cope with that, maybe through a special logger.

For example:
- start writing over the old logs transparently (because, usually, the most important logs are the most recent ones)
- simply fake logging, but not logging anything more (keeping all history and simply discard anything that comes after the disk is full)

These could be solved easily, by catching the exception and either processing it (the first strategy), either by ignoring it (the second strategy).

But it matters to have the functionality by default.

On Sunday, 31 August 2014 at 09:34:51 UTC, Marco Leise wrote:
> Ok, here is the current state: Logging is not a first-class
> language feature with special semantics. Drop your "pure"
> keywords on those 90% of functions or only log in "debug".

Then maybe the language lacks features that allow you to escape purity in a safe manner.

But maybe you should only allow "trace()" and not "log()" in pure functions. Tracing execution and logging state.

> I still don't see it fly even theoretically. The "stdlog" will
> be an interface with an arbitrary implementation behind it.

An interface can require specific properties of the implementation.

> file logger will eventually hit a "disk full" state and throw
> an exception. Since "pure" implies that a function call can be
> elided such a change of execution path cannot work.

Not sure what you mean by this.

The logger I am most interested in writes to a circular buffer and uploads the log to a database on a crash so that the source of the crash can be identified. I am only interested in in logging execution, not preserved state without execution.

It is not uncommon to have loggers that writes to a fixed size preallocated area that behaves like a circular buffer (e.g. retain at most 1GB and <3 months old logging-data)

On Sunday, 31 August 2014 at 09:56:29 UTC, Ola Fosheim Grøstad wrote:
> The logger I am most interested in writes to a circular buffer and uploads the log to a database on a crash so that the source of the crash can be identified. I am only interested in in logging execution, not preserved state without execution.

Does this logger already exist, could I take a look at it?

If not, if someone writes an appender for writing to the database, you could accomplish this goal with log4d using a buffer appender that triggers on fatal.