Voting: std.logger

[Dicebot via Digitalmars-d]

(sorry for being a bit late, was distracted)

std.logger proposal by Robert Schadek enters voting period which
will last two weeks starting from now.

Discussion thread :
http://forum.dlang.org/post/zhvmkbahrqtgkptdlcvh at forum.dlang.org

This voting will be somewhat different from previous ones because
it will be done with std.experimental in mind. Because of that
please reply with a bit more structured votes:

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.

2) Yes / No for inclusion into Phobos in its current state

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"

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 ;)

[Dicebot via Digitalmars-d]

Small foreword specifically about std.logger :

It is quite clear that something like logging system is very
opinionated thing with API/design preferences highly based on
actual use cases. I don't think that we will ever be able to come
up with decisions that will satisfy everyone - some compromises
are necessary. Because of that, please think twice before
declaring certain features crucial or API unacceptable - reserve
such judgement only for something that is really a blocker for
your work and will likely result in using completely different
logging solution as opposed to building on top of std.logger

And big thanks to Robert for being incredibly patient in pursuing
inclusion of his proposal despite all the time it has taken!

[Jakob Ovrum via Digitalmars-d]

Post by Dicebot via Digitalmars-d
1) Yes / No for inclusion into std.experimental

If modules in std.experimental are completely free to make
breaking changes, then my vote is a clear yes.

I'm uncertain if std.experimental can carry its own weight in the
presence of dub, but I guess that's a discussion for another
thread.

Post by Dicebot via Digitalmars-d
2) Yes / No for inclusion into Phobos in its current state

No.

IMO, both API and implementation are insufficient. Additionally,
the "current state" is extremely volatile with sweeping API
changes being made in the last two weeks or so.

However, review is on-going and at this rate, I'm hopeful it will
be good enough by the next vote.

Post by Dicebot via Digitalmars-d
3) If you have answered "No" for (2) : list of mandatory
changes that are needed to make you vote "Yes"

a) The *API* must support minimal dynamic memory allocation for
the normal execution path. However, theoretical *implementation*
changes that reduce memory allocation are not a deal-breaker.

b) API must specify a strong stance on threading, whatever the
form it takes.

c) This one might seem unnecessarily strict, but I think the fact
that Logger is a class and not an interface smells of poor
design. I might still be convinced that having it as a class is
justified, but my current stance is that it must be an interface.

Post by Dicebot via Digitalmars-d
4) Any additional comments for author.

The author is aware of my gripes from Github comments and posts
in the review thread.

[Rikki Cattermole via Digitalmars-d]

Post by Dicebot via Digitalmars-d
(sorry for being a bit late, was distracted)
std.logger proposal by Robert Schadek enters voting period which will
last two weeks starting from now.
http://forum.dlang.org/post/zhvmkbahrqtgkptdlcvh at forum.dlang.org
This voting will be somewhat different from previous ones because it
will be done with std.experimental in mind. Because of that please reply
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.

Yes,
I have not tested it, just for reference sake. But the code design looks
fine. Nicely documented with unittests.

Post by Dicebot via Digitalmars-d
2) Yes / No for inclusion into Phobos in its current state
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.

Yes
But might be a good idea to add a Syslog and Windows event viewer
logger(s) support.

Post by Dicebot via Digitalmars-d
3) If you have answered "No" for (2) : list of mandatory changes that
are needed to make you vote "Yes"
4) Any additional comments for author.

Okay 1) update sidebar for phobos docs (atleast I couldn't see link to
modules in there).
2) for std.logger.core defaultLogger please please please add that at
the top of the page of documentation. Or else the very ability to change
the default logger could be lost. It took me a while to find it.

Post by Dicebot via Digitalmars-d
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 ;)

[Andrei Alexandrescu via Digitalmars-d]

Post by Dicebot via Digitalmars-d
(sorry for being a bit late, was distracted)
std.logger proposal by Robert Schadek enters voting period which will
last two weeks starting from now.
http://forum.dlang.org/post/zhvmkbahrqtgkptdlcvh at forum.dlang.org
This voting will be somewhat different from previous ones because it
will be done with std.experimental in mind. Because of that please reply

My vote is a qualified "yes" contingent upon fixes that I'll give detail
on below. In the current form my vote is "no" seeing as the module makes
a number of unforced tactical errors. Overall I think the goods are
there, and are easy to put in acceptable form.

Post by Dicebot via Digitalmars-d
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.

No in current form. Yes assuming the fixes below are implemented.

Post by Dicebot via Digitalmars-d
2) Yes / No for inclusion into Phobos in its current state
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.

No. I also think any new module should sit in std.experimental for one
release cycle.

Post by Dicebot via Digitalmars-d
3) If you have answered "No" for (2) : list of mandatory changes that
are needed to make you vote "Yes"

Here's my list:

1. Minimal logging level must be selected statically in addition to the
current dynamic selection. Static settings preclude dynamic settings.
This is not negotiable.

2. All logging code must be rigorously eliminated if below the static
logging level. More precisely, there must be a front-end optimization
that eliminates all code dedicated to a "lazy" variable that's not used
by a generic function. This would be a fantastic redeeming of the "lazy"
keyword, which has been of marginal utility until now. The challenge
here is cooperating with someone on the compiler team to make sure that
front-end improvement gets implemented, and writing unit tests that make
sure there's no regression later. This is not negotiable.

3. The suffix notations must be replaced with overloads. The only
acceptable suffix is "f" for formatting. Everything else must be
achieved via overloads with the help of template constraints. Robert's
answer http://goo.gl/FehDVh suggests he didn't consider using template
constraints. We can't let that slip become a feature of the library for
millenia to come.

The overloads must be:

// just log stuff
log(T...)(lazy T stuff) if (!is(T[0] : const LogLevel));
// log with format
logf(S, T...)(lazy S fmt, lazy T stuff) if (isSomeString!Str);
// log conditional with format
logf(S, T...)(lazy bool cond, lazy S fmt, lazy T stuff) if
(isSomeString!Str);

These three overloads should be repeated for all logging functions
(info, trace etc). The functions don't evaluate their arguments if the
respective log level is disabled.

The following functions will NOT be repeated for all logging functions:

// just log stuff at some level
log(T...)(LogLevel lvl, lazy T stuff) if (!is(T[0] : const LogLevel));
// log with format
logf(S, T...)(LogLevel lvl, lazy S fmt, lazy T stuff) if (isSomeString!Str);
// log conditional with format
logf(S, T...)(LogLevel lvl, lazy bool cond, lazy S fmt, lazy T stuff) if
(isSomeString!Str);

These overloads always evaluate their first argument eagerly to
determine the required logging level. Depending on it they may or may
not evaluate their other arguments.

This is not negotiable.

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.

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.

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.

Post by Dicebot via Digitalmars-d
4) Any additional comments for author.

Don't let any of the above discourage you. This is great work and is
already one foot in. Let's get this done and done. Don't forget - it's
all about Deutsche GrÃŒndlichkeit!


Andrei

[Dicebot via Digitalmars-d]

On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
No in current form. Yes assuming the fixes below are
implemented.
...
No. I also think any new module should sit in std.experimental
for one release cycle.

Clarification, just to be sure you got it right - right now we
_only_ vote on inclusion into std.experimental, even if majority
of voters will consider it Phobos-quality. Staging period of one
release cycle is mandatory.

That said - can you explain a bit more why you think it can't be
included in std.experimental? (== think that it is fundamentally
broken to the point it can't be even suggested for experiments)
Most issues listed seem to be more related to actual Phobos
inclusion.

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
No in current form. Yes assuming the fixes below are implemented.
...
No. I also think any new module should sit in std.experimental for one
release cycle.

Clarification, just to be sure you got it right - right now we _only_
vote on inclusion into std.experimental, even if majority of voters will
consider it Phobos-quality. Staging period of one release cycle is
mandatory.
That said - can you explain a bit more why you think it can't be
included in std.experimental? (== think that it is fundamentally broken
to the point it can't be even suggested for experiments) Most issues
listed seem to be more related to actual Phobos inclusion.

I explained in the non-negotiable points. The point of keeping a module
in std.experimental is watching for only minor tweaks. I think e.g. the
names in the API is in need of solid change, which is easy to effect but
affects callers quite a bit. -- Andrei

[David Nadlinger via Digitalmars-d]

On Tuesday, 29 July 2014 at 16:59:51 UTC, Andrei Alexandrescu

The point of keeping a module in std.experimental is watching
for only minor tweaks.

I agree. For this reason, I also vote for "no" (1 as well as 2),
as the current conditional logging support doubles the size of
the API for shaving a grand total of 3 characters off the
invocation in a rather infrequent use case.

Cheers,
David

[Robert burner Schadek via Digitalmars-d]

On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
My vote is a qualified "yes" contingent upon fixes that I'll
give detail on below. In the current form my vote is "no"
seeing as the module makes a number of unforced tactical
errors. Overall I think the goods are there, and are easy to
put in acceptable form.
1. Minimal logging level must be selected statically in
addition to the current dynamic selection. Static settings
preclude dynamic settings. This is not negotiable.

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

Post by Andrei Alexandrescu via Digitalmars-d
2. All logging code must be rigorously eliminated if below the
static logging level. More precisely, there must be a front-end
optimization that eliminates all code dedicated to a "lazy"
variable that's not used by a generic function. This would be a
fantastic redeeming of the "lazy" keyword, which has been of
marginal utility until now. The challenge here is cooperating
with someone on the compiler team to make sure that front-end
improvement gets implemented, and writing unit tests that make
sure there's no regression later. This is not negotiable.

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.

Post by Andrei Alexandrescu via Digitalmars-d
3. The suffix notations must be replaced with overloads. The
only acceptable suffix is "f" for formatting. Everything else
must be achieved via overloads with the help of template
constraints. Robert's answer http://goo.gl/FehDVh suggests he
didn't consider using template constraints. We can't let that
slip become a feature of the library for millenia to come.
// just log stuff
log(T...)(lazy T stuff) if (!is(T[0] : const LogLevel));
// log with format
logf(S, T...)(lazy S fmt, lazy T stuff) if (isSomeString!Str);
// log conditional with format
logf(S, T...)(lazy bool cond, lazy S fmt, lazy T stuff) if
(isSomeString!Str);
These three overloads should be repeated for all logging
functions (info, trace etc). The functions don't evaluate their
arguments if the respective log level is disabled.
The following functions will NOT be repeated for all logging
// just log stuff at some level
log(T...)(LogLevel lvl, lazy T stuff) if (!is(T[0] : const
LogLevel));
// log with format
logf(S, T...)(LogLevel lvl, lazy S fmt, lazy T stuff) if
(isSomeString!Str);
// log conditional with format
logf(S, T...)(LogLevel lvl, lazy bool cond, lazy S fmt, lazy T
stuff) if (isSomeString!Str);
These overloads always evaluate their first argument eagerly to
determine the required logging level. Depending on it they may
or may not evaluate their other arguments.
This is not negotiable.

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

Post by Andrei Alexandrescu via Digitalmars-d
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.

Post by Andrei Alexandrescu via Digitalmars-d
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
* ...

Post by Andrei Alexandrescu via Digitalmars-d
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.

Post by Andrei Alexandrescu via Digitalmars-d

Post by Dicebot via Digitalmars-d
4) Any additional comments for author.

Don't let any of the above discourage you. This is great work
and is already one foot in. Let's get this done and done. Don't
forget - it's all about Deutsche GrÃŒndlichkeit!
Andrei

Hope this brings you closer to a "yes"
Robert

[H. S. Teoh via Digitalmars-d]

[...]

Post by Andrei Alexandrescu via Digitalmars-d
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'.


T

[Andrei Alexandrescu via Digitalmars-d]

Post by H. S. Teoh via Digitalmars-d
[...]

Post by Andrei Alexandrescu via Digitalmars-d
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

[H. S. Teoh via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
[...]

Post by Andrei Alexandrescu via Digitalmars-d
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

[uri via Digitalmars-d]

On Wednesday, 30 July 2014 at 00:15:26 UTC, H. S. Teoh via

On Tue, Jul 29, 2014 at 04:55:04PM -0700, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

On Tue, Jul 29, 2014 at 11:09:27PM +0000, Robert burner

Post by Dicebot via Digitalmars-d
On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei

[...]

Post by Dicebot via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
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

[Marco Leise via Digitalmars-d]

Am Wed, 30 Jul 2014 01:42:57 +0000

Post by uri via Digitalmars-d
On Wednesday, 30 July 2014 at 00:15:26 UTC, H. S. Teoh via

On Tue, Jul 29, 2014 at 04:55:04PM -0700, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by H. S. Teoh via Digitalmars-d
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

[Andrei Alexandrescu via Digitalmars-d]

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!

Post by Andrei Alexandrescu via Digitalmars-d
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.

Post by Andrei Alexandrescu via Digitalmars-d
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

[via Digitalmars-d]

On Tuesday, 29 July 2014 at 23:09:28 UTC, Robert burner Schadek

Post by Dicebot via Digitalmars-d
On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
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".

[Daniel Murphy via Digitalmars-d]

"Marc SchÃŒtz" " wrote in message

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.

[David Nadlinger via Digitalmars-d]

Post by Daniel Murphy via Digitalmars-d
"Marc SchÃŒtz" " wrote in message

Post by via Digitalmars-d
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

[linkrope via Digitalmars-d]

Post by David Nadlinger via Digitalmars-d
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.

[David Nadlinger via Digitalmars-d]

Post by David Nadlinger via Digitalmars-d
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?

Wow, upon further code review I discovered that Logger actually
overrides opCmp/opEquals to be based on the name (?!). This leads
to the following gem:

---
void main() {
import std.logger.filelogger;
auto a = new FileLogger("asdf", "w");
auto b = new FileLogger("qwer", "w");
assert(a == b); // WAT
}
---

Cheers,
David

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
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

[Kagamin via Digitalmars-d]

On Wednesday, 30 July 2014 at 14:59:38 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
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.

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
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

[Daniel Murphy via Digitalmars-d]

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.

But the default log object is the tool you use to write things into the log!
It's the secretary you yell things at from the other room, who then writes
them down in the actual log (or logs (or nowhere)).

[Andrei Alexandrescu via Digitalmars-d]

"Andrei Alexandrescu" wrote in message

Post by Andrei Alexandrescu via Digitalmars-d
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.

But the default log object is the tool you use to write things into the
log! It's the secretary you yell things at from the other room, who then
writes them down in the actual log (or logs (or nowhere)).

No, the way I see it is myLog.write("stuff"), i.e. it's me, the caller,
who is doing the logging (i.e. I'm the logger), and myLog is the object
of the action. Granted, things could be interpreted as in "I tell the
logger to carry writing into some other log" but that becomes pop
philosophy. By Occam's rule, just call the object a log, not a logger.
-- Andrei

[Daniel Murphy via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
No, the way I see it is myLog.write("stuff"), i.e. it's me, the caller,
who is doing the logging (i.e. I'm the logger), and myLog is the object of
the action. Granted, things could be interpreted as in "I tell the logger
to carry writing into some other log" but that becomes pop philosophy. By
Occam's rule, just call the object a log, not a logger.

It's subjective either way. Isn't language fun!

[David Nadlinger via Digitalmars-d]

On Wednesday, 30 July 2014 at 17:01:39 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
So the appropriate name for the default log object is
"defaultLog" not "defaultLogger", or "stdlog" not "stdlogger".
The better choice is also shorter.

I'm not going to join a discussion about the finer details of
applying logic to natural language or the applicability of
anthropomorphic analogies to log(ging forests of) messages, but
let me point out that you should probably also argue for
std.logger -> std.log and XyzLogger -> XyxLog to keep the names
consistent.

Cheers,
David

[linkrope via Digitalmars-d]

On Wednesday, 30 July 2014 at 17:01:39 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by Kagamin via Digitalmars-d
On Wednesday, 30 July 2014 at 14:59:38 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d
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.

[Andrei Alexandrescu via Digitalmars-d]

Post by linkrope via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
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

[linkrope via Digitalmars-d]

On Wednesday, 30 July 2014 at 18:08:12 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by David Nadlinger via Digitalmars-d
On Wednesday, 30 July 2014 at 17:01:39 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d

Post by Kagamin via Digitalmars-d
On Wednesday, 30 July 2014 at 14:59:38 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d
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");

[Andrei Alexandrescu via Digitalmars-d]

Yes: most of the time I should be happy with the default log object.
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

[Kagamin via Digitalmars-d]

On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
Yah but then we have stuttering such as log.log("ehm") which is
oddly the same as log("ehm").

log.write
log.writef

[linkrope via Digitalmars-d]

Post by Kagamin via Digitalmars-d
On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
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");

[eles via Digitalmars-d]

Post by linkrope via Digitalmars-d

Post by Kagamin via Digitalmars-d
On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei

Post by Andrei Alexandrescu via Digitalmars-d
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...

[Andrei Alexandrescu via Digitalmars-d]

Post by Kagamin via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
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

[Kagamin via Digitalmars-d]

On Thursday, 31 July 2014 at 15:41:40 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
Then you have the globals write and writef which will compete
with those in std.stdio. -- Andrei

Aren't they from different overload sets?

[Andrei Alexandrescu via Digitalmars-d]

Post by Kagamin via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Then you have the globals write and writef which will compete with
those in std.stdio. -- Andrei

Aren't they from different overload sets?

Doesn't seem to me. They all accept e.g. one string. -- Andrei

[Dicebot via Digitalmars-d]

On Friday, 1 August 2014 at 15:05:55 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by Kagamin via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Then you have the globals write and writef which will compete with
those in std.stdio. -- Andrei

Aren't they from different overload sets?

Doesn't seem to me. They all accept e.g. one string. -- Andrei

So what is the problem? We have module system to resolve that, do
we?

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Kagamin via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Then you have the globals write and writef which will compete with
those in std.stdio. -- Andrei

Aren't they from different overload sets?

Doesn't seem to me. They all accept e.g. one string. -- Andrei

So what is the problem? We have module system to resolve that, do we?

Yah but there's this inconvenience when people import two stdlib modules
and then they need to qualify calls. I agree it's more of a matter of
perception/user education. -- Andrei

[Martin Nowak via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Kagamin via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Then you have the globals write and writef which will compete with
those in std.stdio. -- Andrei

Aren't they from different overload sets?

Doesn't seem to me. They all accept e.g. one string. -- Andrei

So what is the problem? We have module system to resolve that, do we?

Exactly, that's the problem. They collide, so when import both the
hijack protection will error.

import std.stdio, std.log;

write("foobar"); // matches both std.stdio.write and std.log.write

It'd also make it more difficult to tell what `write("foobar")` does,
which is unacceptable for such a fundamental operation.

[Martin Nowak via Digitalmars-d]

Post by Martin Nowak via Digitalmars-d
Exactly, that's the problem. They collide, so when import both the
hijack protection will error.
import std.stdio, std.log;
write("foobar"); // matches both std.stdio.write and std.log.write
It'd also make it more difficult to tell what `write("foobar")` does,
which is unacceptable for such a fundamental operation.

We already have a similar issue with std.stdio.write and std.file.write
that is fairly annoying.

[Dicebot via Digitalmars-d]

Post by Martin Nowak via Digitalmars-d
Exactly, that's the problem. They collide, so when import both
the hijack protection will error.
import std.stdio, std.log;
write("foobar"); // matches both std.stdio.write and
std.log.write
It'd also make it more difficult to tell what `write("foobar")` does,
which is unacceptable for such a fundamental operation.

Solution is easy - don't do `import std.log` an don't recommend
use to do it in docs, always use `import log = std.log`. This is
how D module system is supposed to work.

Right now there two conflicting statements in language docs:
1) namespaces are not needed, modules should work as replacement
2) usage of plain imports is encouraged

Pretending that (1) is true and at the same time putting
namespace workaround to the library is just lying to the
programmers. Either we need to encourage programming style that
works with D module system or admit it has completely failed. It
is a problem not unique to std.logger

[Daniel Murphy via Digitalmars-d]

Solution is easy - don't do `import std.log` an don't recommend use to do
it in docs, always use `import log = std.log`. This is how D module system
is supposed to work.

It's easy, but it's not the easiest. There is a lot of value in having the
easiest way to do something also be the right way.

[Dicebot via Digitalmars-d]

"Dicebot" wrote in message

Post by Dicebot via Digitalmars-d
Solution is easy - don't do `import std.log` an don't
recommend use to do it in docs, always use `import log =
std.log`. This is how D module system is supposed to work.

It's easy, but it's not the easiest. There is a lot of value
in having the easiest way to do something also be the right way.

I am afraid we don't have the right way in D then. Caring about
cross-module name conflicts feels too much like plain C.

[Daniel Murphy via Digitalmars-d]

Post by Dicebot via Digitalmars-d
I am afraid we don't have the right way in D then. Caring about
cross-module name conflicts feels too much like plain C.

But with overloading!

It isn't just about avoiding conflicts - if the function name is unique, you
can tell what the code is doing without having to examine the context so
closely. This is especially important for the standard library, because the
time spent learning names can be reclaimed over multiple projects.

This is a strength of C, although C goes way too far with forcing it.

[Dicebot via Digitalmars-d]

"Dicebot" wrote in message

Post by Dicebot via Digitalmars-d
I am afraid we don't have the right way in D then. Caring
about cross-module name conflicts feels too much like plain C.

But with overloading!
It isn't just about avoiding conflicts - if the function name
is unique, you can tell what the code is doing without having
to examine the context so closely. This is especially
important for the standard library, because the time spent
learning names can be reclaimed over multiple projects.

If you find this important, you can always require renamed /
static imports in your projects. On the contrary, if function
name is already qualified with some redundant information, there
is no simple way back other than aliasing all symbols from that
module.

I am convinced we are missing good style of using D import
system, not good names.

This is a strength of C, although C goes way too far with
forcing it.

There are surprisingly many things I miss from C but manual name
mangling is not in that list.

[Andrei Alexandrescu via Digitalmars-d]

Post by Daniel Murphy via Digitalmars-d

Post by Dicebot via Digitalmars-d
I am afraid we don't have the right way in D then. Caring about
cross-module name conflicts feels too much like plain C.

But with overloading!
It isn't just about avoiding conflicts - if the function name is
unique, you can tell what the code is doing without having to examine
the context so closely. This is especially important for the standard
library, because the time spent learning names can be reclaimed over
multiple projects.

If you find this important, you can always require renamed / static
imports in your projects. On the contrary, if function name is already
qualified with some redundant information, there is no simple way back
other than aliasing all symbols from that module.
I am convinced we are missing good style of using D import system, not
good names.

To an extent I agree, but I have to side with the view that common
artifacts in stdlib can cause quite some annoyance. I remember bug
reports being made about clashing symbols between (I forgot exactly)
std.string, std.regex, and std.algorithm. Clearly avoiding those clashes
was all business as usual, but that doesn't mean we can't make things a
tad better for standard library users.

Andrei

[Timon Gehr via Digitalmars-d]

Clearly avoiding those clashes was all business as usual,

The newly introduced _private_ aliases would have possibly led to more
clashes, aggravating the issue.

[Daniel Murphy via Digitalmars-d]

There are surprisingly many things I miss from C but manual name mangling
is not in that list.

I don't like manual name mangling, but I like being able to look at a line
of code and know exactly what it does. There are other factors, but this is
an important one.

I know using IDEs makes the cost of finding out what it actually does much
lower, but it's a cost nonetheless.

[Kagamin via Digitalmars-d]

Post by Martin Nowak via Digitalmars-d
It'd also make it more difficult to tell what `write("foobar")` does,
which is unacceptable for such a fundamental operation.

Can you tell, what `log(1)` does?

[Timon Gehr via Digitalmars-d]

Post by Kagamin via Digitalmars-d

Post by Martin Nowak via Digitalmars-d
It'd also make it more difficult to tell what `write("foobar")` does,
which is unacceptable for such a fundamental operation.

Can you tell, what `log(1)` does?

It returns 0. No, wait...

[Jeremy Powers via Digitalmars-d]

Post by Kagamin via Digitalmars-d
Can you tell, what `log(1)` does?

Is there a irrefutable requirement to have a log function without explicit
level?

Do we lose anything if we just force every log call to have a level, and
dump the plain 'log' method? Point people to use info if they don't care
about the level, and you can clean things up considerably.

As for voting:

Qualified yes for std.experimental. If experimental is supposed to be
'done but not baked' then this would be a no vote, in favor of a few more
iterations with the dub package (and pointing people to use it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140801/e3d4c28a/attachment.html>

[Kagamin via Digitalmars-d]

On Friday, 1 August 2014 at 20:20:00 UTC, Jeremy Powers via

Post by Jeremy Powers via Digitalmars-d

Post by Kagamin via Digitalmars-d
Can you tell, what `log(1)` does?

Is there a irrefutable requirement to have a log function
without explicit
level?

As I understand, it's a defensive feature. There are things one
wants in the log unconditionally, like OS version and program
version. They can be logged at fatal level, but that's a
workaround and looks confusing, and still can be filtered.

[Jeremy Powers via Digitalmars-d]

Is there a[n] irrefutable requirement to have a log function without

Post by Andrei Alexandrescu via Digitalmars-d
explicit
level?

As I understand, it's a defensive feature. There are things one wants in
the log unconditionally, like OS version and program version. They can be
logged at fatal level, but that's a workaround and looks confusing, and
still can be filtered.

Believe that's what the 'off' level is for, though it is confusingly named
(off as in no filtering, not no logging). Maybe better called 'always'?


I contend that having bare log methods without a specified level is a
mis-feature. They may be useful as a shortcut when the desired level is
unknown/irrelevant, but I don't believe what they add is worth the bother.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140804/3d9d63f1/attachment.html>

[Jeremy Powers via Digitalmars-d]

As I understand, it's a defensive feature. There are things one wants in

the log unconditionally, like OS version and program version. They can be
logged at fatal level, but that's a workaround and looks confusing, and
still can be filtered.

Believe that's what the 'off' level is for, though it is confusingly named
(off as in no filtering, not no logging). Maybe better called 'always'?

Looking at the current version of the logger code, there is nothing that
will always be logged - if the logging level (global or logger) is set to
'off' it will not log even if you call log() without a level. So a bit of
clarifying around this may be desired.

I contend that having bare log methods without a specified level is a
mis-feature. They may be useful as a shortcut when the desired level is
unknown/irrelevant, but I don't believe what they add is worth the bother.

Leaving this quote in, since it's my main point - I think not having a bare
log() method is better than having one. Log levels are pretty basic to the
idea of logging (as done here and most everywhere else), trying to ignore
them just moves the complexity elsewhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140804/a87fc019/attachment.html>

[Kagamin via Digitalmars-d]

'always' or 'unfiltered'
I'm fine with logl(LogLevel.max,...); I expect it to be used
rarely. Well, maybe not logging anything when the level is set to
'off' makes sense, it just should work on any other level.

[Kagamin via Digitalmars-d]

On Wednesday, 30 July 2014 at 17:01:39 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
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.

[via Digitalmars-d]

On Wednesday, 30 July 2014 at 14:59:38 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by via Digitalmars-d
On Tuesday, 29 July 2014 at 23:09:28 UTC, Robert burner

Post by Robert burner Schadek via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
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?

Yes. It's called "derivation" in linguistics. It works in this
case, because "-er" is a semi-productive suffix, which produces
new nouns (called "nomina agentis") that refer to the "do-er",
i.e. either a person, like the other meaning of "logger", or a
tool, e.g. "box cutter". It is semi-productive, because as you
noted, some derivations indeed sound odd and are almost never
used.

But this is getting way off-topic. My main point is that it's
easy to understand, and it has lots of precedence in other
software.

[Martin Nowak via Digitalmars-d]

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.

[Martin Nowak via Digitalmars-d]

Post by Martin Nowak via Digitalmars-d

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.

Just checked tested this.

static struct TestLogger
{
enum minLogLevel = LogLevel.error;
void write(in LogEntry e) { _entries ~= e; }

const(LogEntry)[] _entries;
}

void main()
{
TestLogger logger;
logger.log(LogLevel.debug_, "foobar");
}


The call logger.log(LogLevel.debug_) can be completely removed by the
compiler. The delegates for the lazy parameters are still generated though.
Either fixing
[`--gc-sections`](https://issues.dlang.org/show_bug.cgi?id=879) or
adding [LTO](https://github.com/ldc-developers/ldc/issues/693) would help.
Also dmd (but not LDC) has a
[bug](https://issues.dlang.org/show_bug.cgi?id=8615) where it still adds
a few instructions to pass the delegate (even though the function is
never called).

So I think it's an appropriate solution to the problem.
http://dpaste.dzfl.pl/95fb6a4e086d

[Martin Drašar via Digitalmars-d]

Post by Dicebot via Digitalmars-d
(sorry for being a bit late, was distracted)
std.logger proposal by Robert Schadek enters voting period which will
last two weeks starting from now.
http://forum.dlang.org/post/zhvmkbahrqtgkptdlcvh at forum.dlang.org
This voting will be somewhat different from previous ones because it
will be done with std.experimental in mind. Because of that please reply
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.

Yes.

The API is sane and the design has withstood a lot of relevant criticism
as well as bikeshedding. Although, I do not really like log function
suffixes and would prefer overloads.

Post by Dicebot via Digitalmars-d
2) Yes / No for inclusion into Phobos in its current state
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.

No.

There were a lot of changes during the review process. The module should
IMO go to experimental to have some time to take care of all those small
things as well as to get (hopefully) some larger adoption.

Post by Dicebot via Digitalmars-d
3) If you have answered "No" for (2) : list of mandatory changes that
are needed to make you vote "Yes"

For me it is the stay in std.experimental and seeing that nobody is
pressing for another api changes (like Andrei is doing now).

Post by Dicebot via Digitalmars-d
4) Any additional comments for author.

Great work and some great patience you have displayed in the process.
Thank you!

[John Colvin via Digitalmars-d]

Post by Dicebot via Digitalmars-d
1) Yes / No for inclusion into std.experimental

Yes. It's ready for an official stamp.

Post by Dicebot via Digitalmars-d
2) Yes / No for inclusion into Phobos in its current state

No. Full advantage should be taken of the std.experimental time.

Post by Dicebot via Digitalmars-d
3) If you have answered "No" for (2) : list of mandatory
changes that are needed to make you vote "Yes"

Nothing new here, it's been covered by others. If I had to pick
out something: Using overloads properly is a clear improvement
step that must be taken for this to be considered phobos quality.

[Casey via Digitalmars-d]

Post by Dicebot via Digitalmars-d
1) Yes / No for inclusion into std.experimental

Yes

Post by Dicebot via Digitalmars-d
2) Yes / No for inclusion into Phobos in its current state

No

Post by Dicebot via Digitalmars-d
3) If you have answered "No" for (2) : list of mandatory
changes that are needed to make you vote "Yes"

I can't say Yes until I've actually used it.

Post by Dicebot via Digitalmars-d
4) Any additional comments for author.

None for the author as I detailed my concerns in Github, though I
should apologize for being very lax about participating (RL has
been busy). However, I wanted to address the suffix notation as
I suggested it. What I was going for was consistency with the
write/writef method signatures to keep things consistent. I felt
it would be good to make the two similar since they do similar
things.

My suggestion for conditional versions, logc and logcf, I believe
are the ones causing some heartburn. If you look at how write
works, what does this mean?

write(a < b, "some message");

Am I writing conditionally or am I writing out something like
"truesome message"? In phobos, it is the latter. To have
consistency, we can't simply make the first parameter be a
condition as it would prevent us from doing something like this:

log(canFind("foobar", "bar"));

Second, the way I look at it, you can read the methods like this:

write - write
writef - write formatted
log - log
logf - log formatted
logc - log conditionally
logcf - log conditionally and formatted

Having that english-like meaning I think will make it easier to
recognize what's being done.

tl;dr I proposed having the log interface consistent with the
write interface (from a parameter standpoint) and suggested the
"c" suffix to make it clear that conditional logging is being
performed vs. the first parameter being a boolean that's part of
the log message.

[Robert burner Schadek via Digitalmars-d]

maybe we should have made a vote for logc vs. log(bool) first

I think we gone full circle ulong.max times by now ;-)

[Dicebot via Digitalmars-d]

On Tuesday, 29 July 2014 at 12:18:31 UTC, Robert burner Schadek

Post by Robert burner Schadek via Digitalmars-d
maybe we should have made a vote for logc vs. log(bool) first
I think we gone full circle ulong.max times by now ;-)

This shouldn't affect inclusion to std.experimental and can be
done at any moment

[Andrei Alexandrescu via Digitalmars-d]

Post by Robert burner Schadek via Digitalmars-d
maybe we should have made a vote for logc vs. log(bool) first
I think we gone full circle ulong.max times by now ;-)

This shouldn't affect inclusion to std.experimental and can be done at
any moment

NO.

We put something in std.experimental when we can't imagine what other
work is to be done on the module. (Inevitably a little more work is
prompted by usage, which is the point of it all.) We don't put in
std.experimental stuff that has already a known backlog of work to do.


Andrei

[Dicebot via Digitalmars-d]

On Tuesday, 29 July 2014 at 17:15:22 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
NO.
We put something in std.experimental when we can't imagine what
other work is to be done on the module. (Inevitably a little
more work is prompted by usage, which is the point of it all.)
We don't put in std.experimental stuff that has already a known
backlog of work to do.
Andrei

Spawned separate discussion thread :
http://forum.dlang.org/post/icumpyexlsneievlmfex at forum.dlang.org

[Andrei Alexandrescu via Digitalmars-d]

Post by Robert burner Schadek via Digitalmars-d
maybe we should have made a vote for logc vs. log(bool) first
I think we gone full circle ulong.max times by now ;-)

My understanding is the entire prefix-letter approach was based on an
oversight.

Andrei

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Robert burner Schadek via Digitalmars-d
maybe we should have made a vote for logc vs. log(bool) first
I think we gone full circle ulong.max times by now ;-)

My understanding is the entire prefix-letter approach was based on an
oversight.
Andrei

s/prefix/suffix/

[Robert burner Schadek via Digitalmars-d]

On Tuesday, 29 July 2014 at 17:20:58 UTC, Andrei Alexandrescu
wrote:

I should have the overload approach done by tonight

[linkrope via Digitalmars-d]

On Tuesday, 29 July 2014 at 17:31:27 UTC, Robert burner Schadek

Post by Robert burner Schadek via Digitalmars-d
On Tuesday, 29 July 2014 at 17:20:58 UTC, Andrei Alexandrescu
I should have the overload approach done by tonight

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.

[Robert burner Schadek via Digitalmars-d]

Post by linkrope via Digitalmars-d
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

[Andrei Alexandrescu via Digitalmars-d]

Post by Robert burner Schadek via Digitalmars-d

Post by linkrope via Digitalmars-d
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

[destroyer via Digitalmars-d]

Post by Casey via Digitalmars-d
Second, the way I look at it, you can read the methods like
write - write
writef - write formatted
log - log
logf - log formatted
logc - log conditionally
logcf - log conditionally and formatted

Andrei is Romanian; not Hungarian.
And a Romanian is AFAIK also not a reverse Hungarian.
So no need to arouse him by proposing a Hungarian Api. :)
better being concise and precise.

[Francesco Cattoglio via Digitalmars-d]

Post by Dicebot via Digitalmars-d
1) Yes / No for inclusion into std.experimental

Yes, absolutely.

Post by Dicebot via Digitalmars-d
2) Yes / No for inclusion into Phobos in its current state

Not yet.

Post by Dicebot via Digitalmars-d
3) If you have answered "No" for (2) : list of mandatory
changes that
are needed to make you vote "Yes"

As far as I undestood, there's no way right now to do logging
without using the GC. And that means it is currently impossible
to log inside destructor calls. That is a blocker in my book.

Post by Dicebot via Digitalmars-d
4) Any additional comments for author.

No matter the changes that might be applied to reduce suffix
notation, I would love to retain the ability to do conditional
unformatted logging.

[Byron Heads via Digitalmars-d]

Post by Dicebot via Digitalmars-d
1) Yes / No for inclusion into std.experimental

Yes

Post by Dicebot via Digitalmars-d
2) Yes / No for inclusion into Phobos in its current state

No

see notes in (3)

Post by Dicebot via Digitalmars-d
3) If you have answered "No" for (2) : list of mandatory changes that
are needed to make you vote "Yes"

We need to hammer out how this will work inside libraries. If my app is
using multiple libraries I need to know I have full control of how they
log and where (), and if I write libraries I need to include logging that
will not affect performance or added dependencies.

I like the idea of a standard interface for D logging. Other logging
implementations should be able to plug into the interface without having
to inherit from std.log.Logger (single inheritance issue).

I would like to see conditional logging as part of the interface, or in
the documentation show how we can achieve that with stdlib in a clean and
simple way.

Logger should include a shared Logger, or include it in the interface for
outside libraries to handle the implementation. There will be libraries
that thread internally and will need to support shared logging.

Post by Dicebot via Digitalmars-d
4) Any additional comments for author.

Awesome work so far. Getting this "right" is I huge pain, and I applaud
you going through this.

[Casey via Digitalmars-d]

Post by Byron Heads via Digitalmars-d
Awesome work so far. Getting this "right" is I huge pain, and I applaud
you going through this.

I should have said this as well. Regardless, I second this
statement as this is probably the thing I'm looking forward to
the most when it comes to additions to the standard library.

[Jesse Phillips via Digitalmars-d]

Yes for experimental.

[ponce via Digitalmars-d]

Post by Dicebot via Digitalmars-d
(sorry for being a bit late, was distracted)
std.logger proposal by Robert Schadek enters voting period
which will last two weeks starting from now.
http://forum.dlang.org/post/zhvmkbahrqtgkptdlcvh at forum.dlang.org
This voting will be somewhat different from previous ones
because it will be done with std.experimental in mind. Because
1) Yes / No for inclusion into std.experimental

Yes.

Post by Dicebot via Digitalmars-d
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.
2) Yes / No for inclusion into Phobos in its current state

Yes. A lot of reusable components need warnings (hence: logging).

Post by Dicebot via Digitalmars-d
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"
4) Any additional comments for author.

Thanks.

[Sean Kelly via Digitalmars-d]

Yes, assuming Andrei's non-negotiable issues are addressed first.

[MrSmith via Digitalmars-d]

Yes for inclusion into std.experimental

[Martin Nowak via Digitalmars-d]

Post by Dicebot via Digitalmars-d
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

Post by Dicebot via Digitalmars-d
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.

Post by Dicebot via Digitalmars-d
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.

Post by Dicebot via Digitalmars-d
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 ;)

[Andrei Alexandrescu via Digitalmars-d]

Post by Martin Nowak via Digitalmars-d
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

[Martin Nowak via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Martin Nowak via Digitalmars-d
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

Well phobos as a library is precompiled, so the versions used to compile
phobos will be relevant, not the ones in client code.

For templated functions version identifier will "leak" from client code
into the library, because technically they are instantiated by the
client code.

Also the version identifiers of client code determine which declarations
you see.

Relying on this would be a constant source of bugs.

I did proof-of-concept yesterday using type tags and template
constraints to statically disable certain log levels.
It also has some drawbacks because LogLevel is no longer a plain enum,
but it's more appropriate than version identifiers.
http://forum.dlang.org/post/lrf362$tkn$1 at digitalmars.com

[Andrei Alexandrescu via Digitalmars-d]

Post by Martin Nowak via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by Martin Nowak via Digitalmars-d
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

Well phobos as a library is precompiled, so the versions used to compile
phobos will be relevant, not the ones in client code.
For templated functions version identifier will "leak" from client code
into the library, because technically they are instantiated by the
client code.
Also the version identifiers of client code determine which declarations
you see.
Relying on this would be a constant source of bugs.
I did proof-of-concept yesterday using type tags and template
constraints to statically disable certain log levels.
It also has some drawbacks because LogLevel is no longer a plain enum,
but it's more appropriate than version identifiers.
http://forum.dlang.org/post/lrf362$tkn$1 at digitalmars.com

Oh I hadn't realized that. Thanks! That strengthens my opinion that more
work is needed on the library before inclusion in std.experimental. --
Andrei

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
Oh I hadn't realized that. Thanks! That strengthens my opinion that more
work is needed on the library before inclusion in std.experimental.

To clarify: I'm very strongly opposed to a design that requires
rebuilding Phobos (or relying on different pre-built versions) for
different logging levels. That's just unacceptable. User code must be
able to set logging levels by just passing flags to their own builds.

Andrei

[Johannes Pfau via Digitalmars-d]

Am Fri, 01 Aug 2014 09:43:32 -0700

Post by Andrei Alexandrescu via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Oh I hadn't realized that. Thanks! That strengthens my opinion that
more work is needed on the library before inclusion in
std.experimental.

To clarify: I'm very strongly opposed to a design that requires
rebuilding Phobos (or relying on different pre-built versions) for
different logging levels. That's just unacceptable. User code must be
able to set logging levels by just passing flags to their own builds.
Andrei

It's kinda awkward how complicated the D solutions are compared to
C/C++ with the preprocessor. The only simple way in D seems to be using
string mixins, but these look ugly on the user side.

[Kagamin via Digitalmars-d]

On Friday, 1 August 2014 at 16:43:32 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Oh I hadn't realized that. Thanks! That strengthens my opinion that more
work is needed on the library before inclusion in
std.experimental.

To clarify: I'm very strongly opposed to a design that requires
rebuilding Phobos (or relying on different pre-built versions)
for different logging levels. That's just unacceptable. User
code must be able to set logging levels by just passing flags
to their own builds.

Must be able, but should it be the only possible way?

[Andrei Alexandrescu via Digitalmars-d]

Post by Kagamin via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
Oh I hadn't realized that. Thanks! That strengthens my opinion that more
work is needed on the library before inclusion in std.experimental.

To clarify: I'm very strongly opposed to a design that requires
rebuilding Phobos (or relying on different pre-built versions) for
different logging levels. That's just unacceptable. User code must be
able to set logging levels by just passing flags to their own builds.

Must be able, but should it be the only possible way?

Other ways would be also nice, but the primary use case is the user
chooses the static logging level during build. -- Andrei

[Robert burner Schadek via Digitalmars-d]

Post by Martin Nowak via Digitalmars-d
Well phobos as a library is precompiled, so the versions used
to compile phobos will be relevant, not the ones in client code.
For templated functions version identifier will "leak" from
client code into the library, because technically they are
instantiated by the client code.

could you elaborate please? Currently I use the version
statements in two template functions. I'm not sure why one would
brand this negatively as a leak into the library.

Post by Martin Nowak via Digitalmars-d
Also the version identifiers of client code determine which
declarations you see.
Relying on this would be a constant source of bugs.

could you elaborate please?

Post by Martin Nowak via Digitalmars-d
I did proof-of-concept yesterday using type tags and template
constraints to statically disable certain log levels.
It also has some drawbacks because LogLevel is no longer a
plain enum, but it's more appropriate than version identifiers.
http://forum.dlang.org/post/lrf362$tkn$1 at digitalmars.com

Thank you for taking the time, but I found several conceptional
problems with that POC. The worst being that if I make the
LogLevel inside the TestLogger anything other than a enum it
fails, as it is used in the template constraint. That would mean
the LogLevel is fixed at CT.

[Dicebot via Digitalmars-d]

Voting ends tomorrow, summary post may get delayed for a few days
though.

[Robert burner Schadek via Digitalmars-d]

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

[Dicebot via Digitalmars-d]

On Sunday, 17 August 2014 at 12:16:38 UTC, Robert burner Schadek

Post by Robert burner Schadek via Digitalmars-d
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.

[Andrei Alexandrescu via Digitalmars-d]

Post by Robert burner Schadek via Digitalmars-d
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

[Robert burner Schadek via Digitalmars-d]

On Tuesday, 19 August 2014 at 02:26:24 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d
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.

[Andrei Alexandrescu via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
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

[Robert burner Schadek via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
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?

[via Digitalmars-d]

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

[Robert burner Schadek via Digitalmars-d]

On Wednesday, 20 August 2014 at 13:54:29 UTC, Ola Fosheim GrÞstad

Post by via Digitalmars-d
- 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?

Post by via Digitalmars-d
- 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

Post by via Digitalmars-d
- 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?

[Andrei Alexandrescu via Digitalmars-d]

Post by Robert burner Schadek via Digitalmars-d
whats next?

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

Andrei