On Thursday, 24 July 2014 at 18:51:03 UTC, Andrei Alexandrescu
wrote:
0. There's no way to set the minimal logging level statically,
except for an on/off switch. There must be a way to define e.g.
-version=logLevel=trace that sets the minimum logging level
actually performed. Any logging
On 22/07/14 11:43, ponce wrote:
NullLogger is there precisely because it's trivial and needed.
If it's so trivial then the users can implement that themselves. A
standard library isn't about implementing what's trivial, it's about
implementing what's most useful to most people.
--
/Jacob
On Friday, 25 July 2014 at 07:11:06 UTC, Jacob Carlborg wrote:
A standard library isn't about implementing what's trivial,
it's about implementing what's most useful to most people.
On the other hand, not having to re-implement trivial functions
that you need all the time is a form of
Am Thu, 24 Jul 2014 11:50:54 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
6. The current backend design requires use of classes and references,
i.e. garbage collection. Amid the current tendency to make std work
without requiring GC, I think a design based on RefCounted
Am Fri, 25 Jul 2014 01:23:21 +
schrieb Jakob Ovrum jakobov...@gmail.com:
On Thursday, 24 July 2014 at 23:40:56 UTC, Jakob Ovrum wrote:
How often have you seen a formatted log message logged in a
loop? I'd wager that happens quite often. Using `format` is a
no-go as it completely
On 25/07/14 09:37, Brian Schott wrote:
On the other hand, not having to re-implement trivial functions that you
need all the time is a form of usefulness.
I'm arguing that NullLogger is not something that's needed all the time.
--
/Jacob Carlborg
On Thursday, 24 July 2014 at 23:40:56 UTC, Jakob Ovrum wrote:
On Thursday, 24 July 2014 at 23:01:56 UTC, Robert burner
Schadek wrote:
I do this lazily in a function, because having it global froze
std.concurrency and std.process unittest. I couldn't figure
out why.
It could still be
On Friday, 25 July 2014 at 07:11:06 UTC, Jacob Carlborg wrote:
On 22/07/14 11:43, ponce wrote:
NullLogger is there precisely because it's trivial and needed.
If it's so trivial then the users can implement that
themselves. A standard library isn't about implementing what's
trivial, it's
On Friday, 25 July 2014 at 07:11:06 UTC, Jacob Carlborg wrote:
On 22/07/14 11:43, ponce wrote:
NullLogger is there precisely because it's trivial and needed.
If it's so trivial then the users can implement that
themselves. A standard library isn't about implementing what's
trivial, it's
On Friday, 25 July 2014 at 13:01:29 UTC, francesco cattoglio
wrote:
On Friday, 25 July 2014 at 07:11:06 UTC, Jacob Carlborg wrote:
On 22/07/14 11:43, ponce wrote:
fmin is trivial as well, is not used all the time, yet is in
the standard library. Sometime trivial stuff is still good to
have.
On 2014-07-25 15:01, francesco cattoglio wrote:
fmin is trivial as well, is not used all the time, yet is in the
standard library. Sometime trivial stuff is still good to have.
I'm not saying it bad to have trivial stuff in the standard library. I
just don't see how NullLogger is useful. But
On 2014-07-25 14:52, Dicebot wrote:
That is interesting clash of attitude to standard library :) In my
opinion it is quite the opposite - standard library is here to ensure
primarily that all trivial things are done in a same way in all
projects. Anything more complicated can be packaged as a
On Wednesday, 23 July 2014 at 17:56:52 UTC, linkrope wrote:
Indeed: that's why the lazy condition should be evaluated last!
Your will log condition is very simple and efficient: only =
and !=
But you cannot know, how long the evaluation of the
user-provided condition will take.
I believe
Initial review period is closing soon. I will make a summary and
start a voting thread this weekend.
It does the right thing... there is an overload: without
additional arguments, the first argument (not necessary a
string) is not a format string.
Now if write a bug:
warning(there was an error because the file %s is missing!);
and I forgot the argument, no problem, it will run without
On 7/11/14, 7:36 AM, Dicebot wrote:
Round of a formal review before proceeding to voting. Subject for Phobos
inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert
Schadek.
Preface: (1) We already use the std.logger candidate at Facebook; (2) I
really want to get this in, it's
On Thursday, 24 July 2014 at 18:51:03 UTC, Andrei Alexandrescu
wrote:
3. I'm not sure I like the design using defaultLogger in
conjunction with free functions using it. It clearly makes for
comfortable casual logging by just calling log(whatevs) and it
uses a precedent set by stdout. But I
On Thursday, 24 July 2014 at 18:51:03 UTC, Andrei Alexandrescu
wrote:
0. There's no way to set the minimal logging level statically,
except for an on/off switch. There must be a way to define e.g.
-version=logLevel=trace that sets the minimum logging level
actually performed. Any logging
On 7/24/14, 12:23 PM, Robert burner Schadek wrote:
On Thursday, 24 July 2014 at 18:51:03 UTC, Andrei Alexandrescu wrote:
log(A...)(lazy A stuff); // just log whatevs
log(A...)(LogLevel lvl, lazy A stuff); // log at specified level
log(A...)(bool c, LogLevel lvl, lazy A stuff); // conditionally
In fact you may want to define an extra logging level e.g. verbose or
yap which is by default disabled and can be enabled explicitly. It would
be hierarchically below normal logging.
Isn't this what 'trace' level is for?
On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote:
Round of a formal review before proceeding to voting. Subject
for Phobos inclusion : http://wiki.dlang.org/Review/std.logger
authored by Robert Schadek.
First I want to say that I want this to be *the* logging library,
just as I always
On Thursday, 24 July 2014 at 22:27:34 UTC, Jakob Ovrum wrote:
On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote:
Round of a formal review before proceeding to voting. Subject
for Phobos inclusion : http://wiki.dlang.org/Review/std.logger
authored by Robert Schadek.
First I want to say
On Thursday, 24 July 2014 at 23:01:56 UTC, Robert burner Schadek
wrote:
I do this lazily in a function, because having it global froze
std.concurrency and std.process unittest. I couldn't figure out
why.
It could still be initialized lazily, using `emplace`, ala
---
private static __gshared
On Thursday, 24 July 2014 at 23:40:56 UTC, Jakob Ovrum wrote:
How often have you seen a formatted log message logged in a
loop? I'd wager that happens quite often. Using `format` is a
no-go as it completely thrashes the GC, it needs to use
`formattedWrite` to write directly to the underlying
That api may work for your requirements, but this should go
into phobos and allow anybody to get satisfied.
I think a hardcoded fast version is preferable, then you simply
use a modified version of phobos/runtime if you want low overhead
in-memory logging.
The most important thing, besides
On Wednesday, 23 July 2014 at 06:10:22 UTC, Ola Fosheim Grøstad
wrote:
The most important thing, besides being fast, is that everybody
use the same syntax, making it grep'able.
It is easily grepable
On Tuesday, 22 July 2014 at 23:43:59 UTC, Robert burner Schadek
wrote:
On Tuesday, 22 July 2014 at 21:52:09 UTC, linkrope wrote:
Controversial conditional logging
The only advantage of
tracec(condition, passed);
over
if (condition) trace(passed);
would be,
On Wednesday, 23 July 2014 at 09:15:26 UTC, Robert burner Schadek
wrote:
On Wednesday, 23 July 2014 at 06:10:22 UTC, Ola Fosheim Grøstad
wrote:
The most important thing, besides being fast, is that
everybody use the same syntax, making it grep'able.
It is easily grepable
I mean in the
On Wednesday, 23 July 2014 at 22:07:16 UTC, Ola Fosheim Grøstad
wrote:
It is easily grepable
I mean in the sense that you can write a regexp that catch all
cases for automated search and replace.
that is no problem.
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
At least in the code of our company, logging a formatted string
is the basic use case.
The function for the basic use case should not require a suffix
letter.
I'm in 100% disagreement. If you don't add the f suffix, users
will write:
I'm in 100% disagreement. If you don't add the f suffix, users
will write:
info(user provided string that could contain format);
This is a crash if the user provided string happens to contains
%s.
I wouldn't use such an API which makes format bugs hard to find.
It does the right
On Tuesday, 22 July 2014 at 07:55:04 UTC, Dragos Carp wrote:
Contrary to the NullLogger, writing a rolling logger is a
non-trivial task.
It is an easy ten line function and one additional if.
On Tuesday, 22 July 2014 at 07:27:38 UTC, ponce wrote:
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
By the way: Instead of what I really need, I get a NullLogger.
I have no clue, why I never ever missed such an oddity.
I asked for it. And I use it, because I write libraries that
On Tuesday, 22 July 2014 at 07:55:04 UTC, Dragos Carp wrote:
I'm in 100% disagreement. If you don't add the f suffix, users
will write:
info(user provided string that could contain format);
This is a crash if the user provided string happens to
contains %s.
I wouldn't use such an API which
On Tuesday, 22 July 2014 at 08:44:06 UTC, linkrope wrote:
On Tuesday, 22 July 2014 at 07:27:38 UTC, ponce wrote:
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
By the way: Instead of what I really need, I get a NullLogger.
I have no clue, why I never ever missed such an oddity.
I
On Tuesday, 22 July 2014 at 09:51:24 UTC, ponce wrote:
On Tuesday, 22 July 2014 at 08:44:06 UTC, linkrope wrote:
On Tuesday, 22 July 2014 at 07:27:38 UTC, ponce wrote:
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
By the way: Instead of what I really need, I get a
NullLogger.
I
On Tuesday, 22 July 2014 at 10:24:33 UTC, linkrope wrote:
Not the need is artificial. For example, I have the need to
measure the performance of an application with and without
logging.
I think, the solution is artificial. The obvious solution would
be to register no logger at all.
that
On Tuesday, 22 July 2014 at 10:24:33 UTC, linkrope wrote:
On Tuesday, 22 July 2014 at 09:51:24 UTC, ponce wrote:
On Tuesday, 22 July 2014 at 08:44:06 UTC, linkrope wrote:
On Tuesday, 22 July 2014 at 07:27:38 UTC, ponce wrote:
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
By the
Sorry, but at the first contact with the implementation (the one
with 'genDocComment' and 'buildLogFunction' from months ago) I
was scared away. (It's better now.)
I feared that if I criticize the 'mixin' sequences you would ask
something like suggestions? ;-)
So, I made this experiment to
On Tuesday, 22 July 2014 at 21:52:09 UTC, linkrope wrote:
Sorry, but at the first contact with the implementation (the
one with 'genDocComment' and 'buildLogFunction' from months
ago) I was scared away. (It's better now.)
There was no need, even read that, for implementing a
FileRotateLogger
Pros
The lighning talk about the std.logger proposal at DConf 2014 had
a positive impact.
We were able to change the Current D Use entry of our company
from
Uses D2 / Phobos, Tango (log, xml)
to
Uses D2 / Phobos, Tango (xml).
(We got rid of tango.util.log; we still rely on the
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
Pros
The lighning talk about the std.logger proposal at DConf 2014
had a positive impact.
We were able to change the Current D Use entry of our company
from
Uses D2 / Phobos, Tango (log, xml)
to
Uses D2 / Phobos, Tango
I just pushed a new version to dub and the PR.
Highlights:
* LogManager is gone. ( s/LogManager\.//g should fix all user
code)
* The codegen was replaced by some format token strings
* log(lcf) and trace(cf) now present documentation
* trace(cf) stands as an example for info, warning ...
+1 for not having the conditional log
Not so sure about that. -- Andrei
I agree that the conditional could be useful. But I think that
the current API definition where we already have some strange
letter combinations ('l', 'c', 'f') is an one-way street, that
throws away some good
On Tuesday, 15 July 2014 at 07:31:39 UTC, Dragos Carp wrote:
+1 for not having the conditional log
Not so sure about that. -- Andrei
I agree that the conditional could be useful. But I think that
the current API definition where we already have some strange
letter combinations ('l', 'c',
On Tuesday, 15 July 2014 at 03:22:46 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 14 July 2014 at 20:45:29 UTC, Jeremy Powers via
Digitalmars-d wrote:
The logging API in the standard library needs to be able to
support this
kind of thing. Doesn't mean it actually needs to be included
in the
What does 'errorlcf' mean?
You specify log level 'error' and then you specify another log
level ('l):
which log level wins?
The order of these modifier letters has to be 'lcf', not 'cfl',
...?
On Tuesday, 15 July 2014 at 08:01:12 UTC, Robert burner Schadek
wrote:
I wouldn't call them
On Tuesday, 15 July 2014 at 10:33:24 UTC, linkrope wrote:
What does 'errorlcf' mean?
You specify log level 'error' and then you specify another log
level ('l):
which log level wins?
The order of these modifier letters has to be 'lcf', not 'cfl',
...?
good point one l to much its errorcf
Will you then be able to get fully inlined low overhead ringbuffer logging
throughout the application and used frameworks? E.g. do low level logging
to a ringbuffer that is only saved/mailed upon fatal crashes. This is
useful for online services.
Yes, apart from the inlined part, I'm not
On Tuesday, 15 July 2014 at 17:41:09 UTC, Jeremy Powers via
Digitalmars-d wrote:
I believe to do this with the current setup, you would need
some standard
'dispatcher' logger, and have every user of logging use it.
Then could
configure the dispatcher as needed for your case without
modifying
On Tuesday, 15 July 2014 at 17:41:09 UTC, Jeremy Powers via
Digitalmars-d wrote:
Will you then be able to get fully inlined low overhead
ringbuffer logging
throughout the application and used frameworks? E.g. do low
level logging
to a ringbuffer that is only saved/mailed upon fatal crashes.
On 13/07/14 17:16, Dicebot wrote:
Because starting with documentation in Phobos and than proceeding with
convincing Walter to add built-in support for such idiom is much more
realistic way than the other way around ;)
built-in as in built-in to the language?
--
/Jacob Carlborg
On Monday, 14 July 2014 at 09:10:36 UTC, Jacob Carlborg wrote:
On 13/07/14 17:16, Dicebot wrote:
Because starting with documentation in Phobos and than
proceeding with
convincing Walter to add built-in support for such idiom is
much more
realistic way than the other way around ;)
built-in
On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote:
Round of a formal review before proceeding to voting. Subject
for Phobos inclusion : http://wiki.dlang.org/Review/std.logger
I guess this is possible with the proposal, but I'd like to see
structured logging in the runtime and in a way
On 07/14/2014 01:07 PM, via Digitalmars-d wrote:
On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote:
Round of a formal review before proceeding to voting. Subject for
Phobos inclusion : http://wiki.dlang.org/Review/std.logger
I guess this is possible with the proposal, but I'd like to see
On Sunday, 13 July 2014 at 12:18:40 UTC, Jacob Carlborg wrote:
On 2014-07-13 13:57, Robert burner Schadek wrote:
Anyone else?
I agree with Sönke.
if I change it back, people will argue that that is redundant
and
unintuitive. Than I will change it back again and the
discussion starts
On 07/14/2014 01:45 PM, ponce via Digitalmars-d wrote:
Not everyone will ever get satisfied.
Indeed. I can only compromise so much, until it becomes compromised.
On 14/07/14 11:35, Dicebot wrote:
Yes, something like separate partially static import type.
I doesn't need language support. Just have a single function, log,
which returns a struct. The struct have all the error, warning and
so on, functions.
--
/Jacob Carlborg
On Monday, 14 July 2014 at 14:24:39 UTC, Jacob Carlborg wrote:
On 14/07/14 11:35, Dicebot wrote:
Yes, something like separate partially static import type.
I doesn't need language support. Just have a single function,
log, which returns a struct. The struct have all the error,
warning and
On Monday, 14 July 2014 at 15:34:12 UTC, Dicebot wrote:
On Monday, 14 July 2014 at 14:24:39 UTC, Jacob Carlborg wrote:
On 14/07/14 11:35, Dicebot wrote:
Yes, something like separate partially static import type.
I doesn't need language support. Just have a single function,
log, which
Dicebot wrote in message news:veqlcdugugxpffajp...@forum.dlang.org...
D unit of encapsulation is module. Any other namespace
solutions must die after proper torture.
Just use this in the next release!
extern(C++, log)
{
extern(D):
... functions ...
}
On Monday, 14 July 2014 at 15:43:33 UTC, Daniel Murphy wrote:
Dicebot wrote in message
news:veqlcdugugxpffajp...@forum.dlang.org...
D unit of encapsulation is module. Any other namespace
solutions must die after proper torture.
Just use this in the next release!
extern(C++, log)
{
On Monday, 14 July 2014 at 11:35:16 UTC, Robert burner Schadek
via Digitalmars-d wrote:
? could you rephrase, I can not grasp your point (points)
The point is that the most crucial aspect of logging is being
able to filter or put triggers on the logs in pre-existing
external
There is still a problem: the analogy, that log/logf is similar
to write/writef, is not right anymore. Please correct me if I'm
wrong... but AFAIK write converts every argument to string and
the output device has no mean to choose a preferred
representation of the arguments.
It will be a
The point is that the most crucial aspect of logging is being able to
filter or put triggers on the logs in pre-existing external
logging-solutions without having to modify the frameworks you use.
Important, but I'd hesitate to call it the most crucial aspect... that
honour probably goes to
Not everyone will ever get satisfied.
Indeed. I can only compromise so much, until it becomes compromised.
Naming is one of the two hard problems (along with cache invalidation and
off-by-one errors).
We can argue about these things forever, but ultimately all that really
matters is: does
D unit of encapsulation is module. Any other namespace solutions must
die after proper torture.
Just use this in the next release!
extern(C++, log)
{
extern(D):
... functions ...
}
Not helping :grumpy:
Is this where I talk about hierarchical logging?
There was some talk in the
On Monday, 14 July 2014 at 17:44:37 UTC, Jeremy Powers via
Digitalmars-d wrote:
Is this where I talk about hierarchical logging?
There was some talk in the original review thread about having
each log
import create or tag the log with the module, so one could
refer to and
filter by modules.
While trying to use logger i've found that this doesn't work. The
execution stalls and thread is not executed, while eith writeln
it works fine.
import std.logger;
import std.parallelism;
void worker()
{
log(in worker);
}
void main()
{
auto pool = taskPool;
On Monday, 14 July 2014 at 17:02:59 UTC, Jeremy Powers via
Digitalmars-d wrote:
The stated goal of this log library is to provide a base with
common useful
functionality, in a way that can be extended to fit more
complicated use
cases. I'd argue that what you are talking about fits into the
On Monday, 14 July 2014 at 18:12:44 UTC, MrSmith wrote:
While trying to use logger i've found that this doesn't work.
The execution stalls and thread is not executed, while eith
writeln it works fine.
import std.logger;
import std.parallelism;
void worker()
{
log(in worker);
}
void
On 7/13/14, 9:02 AM, Dragos Carp wrote:
This is a library: you can always add names, but it is very hard
to remove them. If next version of std.logger should support
something like logFirstN or logEveryN (ideas from Google log
library). How this should look like? logfnf, logenf...?
There were
On 7/13/14, 11:45 AM, Dragos Carp wrote:
On the conditional log methods: +1 to not having them, I believe that
they
are more complicating than useful.
+1 for not having the conditional log
Not so sure about that. -- Andrei
On Monday, 14 July 2014 at 18:54:35 UTC, Robert burner Schadek
wrote:
On Monday, 14 July 2014 at 18:12:44 UTC, MrSmith wrote:
While trying to use logger i've found that this doesn't work.
The execution stalls and thread is not executed, while eith
writeln it works fine.
import std.logger;
Getting things changed is more difficult than getting it right from the
start.
Very true. The logging API needs to be right before it goes into std and
has to be locked down. But then, no API is ever right the first time,
needs banging on to expose the weaknesses so they can be fixed.
On Monday, 14 July 2014 at 17:18:05 UTC, Jeremy Powers via
Digitalmars-d wrote:
We can argue about these things forever, but ultimately all
that really
matters is: does it do what we need? As long as the API works,
and lets
one build fancier functionality underneath, it is good.
(Though,
On Monday, 14 July 2014 at 18:59:45 UTC, MrSmith wrote:
can you make an issue out of it here
https://github.com/burner/logger, so we
don't lose track
Here it is https://github.com/burner/logger/issues/10
fixed
On Monday, 14 July 2014 at 20:45:29 UTC, Jeremy Powers via
Digitalmars-d wrote:
The logging API in the standard library needs to be able to
support this
kind of thing. Doesn't mean it actually needs to be included
in the base
implementation.
Will you then be able to get fully inlined low
... I'd almost always prefer a non-string-mixin solution.
... actually writing out the different signatures ...
+1
From a maintenance/sanity standpoint, I'd much rather have a little bit of
duplication over one large if/else'd string mixin. It is much easier to
figure out exactly what is
On Sunday, 13 July 2014 at 07:14:50 UTC, Jeremy Powers via
Digitalmars-d wrote:
... I'd almost always prefer a non-string-mixin solution.
... actually writing out the different signatures ...
+1
I also think that the usage of mixins in std.log is an unforced
error and non-idiomatic D
On 2014-07-11 16:36, Dicebot wrote:
Round of a formal review before proceeding to voting. Subject for Phobos
inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert
Schadek.
* The free functions are not documented
* The API of the free functions look complicated and have cryptic
On Saturday, 12 July 2014 at 21:23:28 UTC, Andrei Alexandrescu
wrote:
I agree. This is not Java. That idiom must go. -- Andrei
I will fix this today
On Saturday, 12 July 2014 at 14:04:00 UTC, Johannes Pfau wrote:
The whole point of journald is that the user can define
arbitrary
key/value pairs. you're not limited to the special key/value
pairs.
http://0pointer.de/blog/projects/journal-submit.html
Also giving log messages uuids is an
On Saturday, 12 July 2014 at 16:13:22 UTC, Sönke Ludwig wrote:
Overall looks good to me. Some points that haven't been
mentioned so far in this review round:
- Using a class with static members doesn't seem to be very
idiomatic. It seems like the three member properties can simply
be made
On Sunday, 13 July 2014 at 11:19:20 UTC, Dragos Carp wrote:
On Sunday, 13 July 2014 at 07:14:50 UTC, Jeremy Powers via
Digitalmars-d wrote:
... I'd almost always prefer a non-string-mixin solution.
... actually writing out the different signatures ...
+1
I also think that the usage of
On Sunday, 13 July 2014 at 11:25:51 UTC, Jacob Carlborg wrote:
On 2014-07-11 16:36, Dicebot wrote:
Round of a formal review before proceeding to voting. Subject
for Phobos
inclusion : http://wiki.dlang.org/Review/std.logger authored
by Robert
Schadek.
* The free functions are not documented
On Sunday, 13 July 2014 at 11:57:26 UTC, Robert burner Schadek
wrote:
- The functions error(), info(), fatal(), etc. don't follow
the usual rule for functions to start with a verb. The
question is if saving three characters over logError() is
worth making the code more ambiguous for the
On 2014-07-13 14:01, Robert burner Schadek wrote:
The compiler does not create ddoc for mixined source
Hasn't that been fixed recently? If not, then I don't think you should
use mixins. We can't have undocumented functions.
The names are quite easy if you look at the bnf.
If you don't
On 2014-07-13 13:57, Robert burner Schadek wrote:
Anyone else?
I agree with Sönke.
if I change it back, people will argue that that is redundant and
unintuitive. Than I will change it back again and the discussion starts
again.
logError is a lot more clear and descriptive. I think that's
On Sunday, 13 July 2014 at 12:18:40 UTC, Jacob Carlborg wrote:
logError is a lot more clear and descriptive. I think that's
important. If people don't like that they can use an alias.
It is effectively same as using static namespace class but
C-style - mangling namespace into function name.
On Saturday, 12 July 2014 at 16:13:22 UTC, Sönke Ludwig wrote:
- The functions error(), info(), fatal(), etc. don't follow
the usual rule for functions to start with a verb. The question
is if saving three characters over logError() is worth making
the code more ambiguous for the outside
On Sunday, 13 July 2014 at 12:41:59 UTC, sigod wrote:
I use my own log module like this:
```
import log = util.log;
log.info(...);
log.debug(...);
// etc
```
Exactly. I think this should be popularized as default style via
std.logger documentation.
But creating x , necessary, function with only slightly
different names is also very non idiomatic D code. Anyway I'm
working on that.
For the conditional variants, wouldn't be enough an overload with
the condition on the first position?
On Sunday, 13 July 2014 at 13:30:20 UTC, Dragos Carp wrote:
But creating x , necessary, function with only slightly
different names is also very non idiomatic D code. Anyway I'm
working on that.
For the conditional variants, wouldn't be enough an overload
with
the condition on the first
On 2014-07-13 14:45, Dicebot wrote:
Exactly. I think this should be popularized as default style via
std.logger documentation.
If that's the style everyone is encouraged to use, why not force it then?
--
/Jacob Carlborg
On 2014-07-13 14:21, Dicebot wrote:
It is effectively same as using static namespace class but C-style -
mangling namespace into function name. `log.error` looks descriptive
enough to me.
I think most usage would _not_ look like that because of the free functions.
--
/Jacob Carlborg
On Sunday, 13 July 2014 at 14:12:56 UTC, Jacob Carlborg wrote:
On 2014-07-13 14:45, Dicebot wrote:
Exactly. I think this should be popularized as default style
via
std.logger documentation.
If that's the style everyone is encouraged to use, why not
force it then?
because if you force it,
On Sunday, 13 July 2014 at 13:37:13 UTC, Robert burner Schadek
wrote:
On Sunday, 13 July 2014 at 13:30:20 UTC, Dragos Carp wrote:
But creating x , necessary, function with only slightly
different names is also very non idiomatic D code. Anyway I'm
working on that.
For the conditional
Am 13.07.2014 14:45, schrieb Dicebot:
On Sunday, 13 July 2014 at 12:41:59 UTC, sigod wrote:
I use my own log module like this:
```
import log = util.log;
log.info(...);
log.debug(...);
// etc
```
Exactly. I think this should be popularized as default style via
std.logger documentation.
On Sunday, 13 July 2014 at 14:25:42 UTC, Dragos Carp wrote:
write/writeln are generic functions that are used for producing
plain-text output in line oriented format (.csv, etc.) or not
line oriented format (json, xml, etc.). This text is human
readable, but not necessary user friendly.
A
1 - 100 of 150 matches
Mail list logo
