thank you Dicebot for the work.

I thought I give a quick update.

* The interface now works on overloads with template constraints.
* The internal api has been split in logHeader, logMsgPart and finishLogMsg (writeLogMsg) can still be used
* StdIOLogger and StdErrLogger are replaced by FileLogger(stdout|stderr)
* FileLogger take std.stdio.File as parameter for the ctor, though files can be closed on scope exit
* FileLogger flush after logging
* new DataTime formatter to output range (placeholder until std.datetime comes up with something)
* fixed all spelling mistakes given in the review
* more documentation (introduced new spelling mistakes ;-) review please)
* ArrayLogger and MultiLogger use same std.container.Array based base class
* More stuff I forgot about

please review and let us get this thing moving

On Sunday, 17 August 2014 at 12:16:38 UTC, Robert burner Schadek wrote:
> thank you Dicebot for the work.
>
> I thought I give a quick update.
>
> * The interface now works on overloads with template constraints.
> * The internal api has been split in logHeader, logMsgPart and finishLogMsg (writeLogMsg) can still be used
> * StdIOLogger and StdErrLogger are replaced by FileLogger(stdout|stderr)
> * FileLogger take std.stdio.File as parameter for the ctor, though files can be closed on scope exit
> * FileLogger flush after logging
> * new DataTime formatter to output range (placeholder until std.datetime comes up with something)
> * fixed all spelling mistakes given in the review
> * more documentation (introduced new spelling mistakes ;-) review please)
> * ArrayLogger and MultiLogger use same std.container.Array based base class
> * More stuff I forgot about
>
> please review and let us get this thing moving

Eventually I am going to go through the list of requirements from voting and current implementation and highlight any differences but it will take some time.

On 8/17/14, 5:16 AM, Robert burner Schadek wrote:
> thank you Dicebot for the work.
>
> I thought I give a quick update.
>
> * The interface now works on overloads with template constraints.
> * The internal api has been split in logHeader, logMsgPart and
> finishLogMsg (writeLogMsg) can still be used
> * StdIOLogger and StdErrLogger are replaced by FileLogger(stdout|stderr)
> * FileLogger take std.stdio.File as parameter for the ctor, though files
> can be closed on scope exit
> * FileLogger flush after logging
> * new DataTime formatter to output range (placeholder until std.datetime
> comes up with something)
> * fixed all spelling mistakes given in the review
> * more documentation (introduced new spelling mistakes ;-) review please)
> * ArrayLogger and MultiLogger use same std.container.Array based base class
> * More stuff I forgot about
>
> please review and let us get this thing moving

This is very promising! Has the versioning issue been solved? I.e. we want the user code to choose the static logging level, not distribute five versions of Phobos.

Andrei

On Tuesday, 19 August 2014 at 02:26:24 UTC, Andrei Alexandrescu wrote:
> This is very promising! Has the versioning issue been solved? I.e. we want the user code to choose the static logging level, not distribute five versions of Phobos.

There is now a template function with version statements inside that returns a bool that is used in an static if inside the templates that implement the log calls with explicit LogLevel. As the version statements get evaluated at CT of the log call from the user code only one version of Phobos is required. And you can disable all five LogLevel individual.

On 8/19/14, 2:44 AM, Robert burner Schadek wrote:
> On Tuesday, 19 August 2014 at 02:26:24 UTC, Andrei Alexandrescu wrote:
>> This is very promising! Has the versioning issue been solved? I.e. we
>> want the user code to choose the static logging level, not distribute
>> five versions of Phobos.
>
> There is now a template function with version statements inside that
> returns a bool that is used in an static if inside the templates that
> implement the log calls with explicit LogLevel. As the version
> statements get evaluated at CT of the log call from the user code only
> one version of Phobos is required. And you can disable all five LogLevel
> individual.

This is great, thanks. Not only this will be a good thing for std.logger, but it will set a precedent for new similar libraries without an explosion in distributions.

We need some unittests to ensure that kind of stuff I guess.


Andrei

>
> We need some unittests to ensure that kind of stuff I guess.
>

I guess I have to freshen up my dmd compilation flow knowledge. I'm not use how to test version = DisableTrace; in std.logger.core and not disable user code trace logging with it. version(unittest) { version = DisableTrace; } will also not help. Maybe the non forward reference part does it!?

Any suggestions?

- Regarding i18n: I think you should avoid using natural language in strings or keep all such strings in a common file for all of phobos.

- I am sceptical to the use of macro style mixins. It makes the code less transparent and less maintainable.

- Having so many ways to call the log functions makes automatic search and replace difficult.

Am Wed, 30 Jul 2014 01:42:57 +0000
schrieb "uri" <email@ether.com>:

> 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:
> >> >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

appLog/applog

On Wednesday, 20 August 2014 at 13:54:29 UTC, Ola Fosheim Grøstad wrote:
> - Regarding i18n: I think you should avoid using natural language in strings or keep all such strings in a common file for all of phobos.

example, please?

>
> - I am sceptical to the use of macro style mixins. It makes the code less transparent and less maintainable.

grep -R "mixin" std/experimental/logger | wc -l
0

>
> - Having so many ways to call the log functions makes automatic search and replace difficult.

It uses overloads now

------------------------


BTW:
  * move std.logger to std.experimental.logger
  * the github project has unittests for the version statements (all pass)

whats next?

On 8/26/14, 8:44 AM, Robert burner Schadek wrote:
> whats next?

One more round of reviews and let's merge to experimental if all good.

Andrei