The implementation and documentation for std.log is ready for viewing.
You can take a look at the doc at
http://jsancio.github.com/phobos/phobos/std_log.html. The source code
is at https://github.com/jsancio/phobos/blob/master/std/log.d.
I had to make some changes to druntime to get the thread id.
On 2011-05-29 01:40, Jose Armando Garcia wrote:
The implementation and documentation for std.log is ready for viewing.
You can take a look at the doc at
http://jsancio.github.com/phobos/phobos/std_log.html. The source code
is at https://github.com/jsancio/phobos/blob/master/std/log.d.
I had to m
On 5/29/11 5:07 AM, Jacob Carlborg wrote:
Why is everyone that contribute with a std.log implementation keep
insisting that it should be configured via command line options? This is
not how a library should be configured, it should be configured via
regular methods like the rest of Phobos. If an
Configuring through the command line is optional for example the
following command line:
$ program --minloglevel=warning --v=3 --logdir=/tmp
Translate to the following in code:
---
import std.log;
void main(string[] args)
{
FilterConfig filterConfig;
filterConfig.minSeverity = Level.warni
On 5/28/11 6:40 PM, Jose Armando Garcia wrote:
The implementation and documentation for std.log is ready for viewing.
You can take a look at the doc at
http://jsancio.github.com/phobos/phobos/std_log.html. The source code
is at https://github.com/jsancio/phobos/blob/master/std/log.d.
I had to ma
Thanks. Comments below.
On Sun, May 29, 2011 at 12:44 PM, Andrei Alexandrescu
wrote:
> On 5/28/11 6:40 PM, Jose Armando Garcia wrote:
>>
>> The implementation and documentation for std.log is ready for viewing.
>> You can take a look at the doc at
>> http://jsancio.github.com/phobos/phobos/std_lo
On 2011-05-29 17:10, Jose Armando Garcia wrote:
Configuring through the command line is optional for example the
following command line:
$ program --minloglevel=warning --v=3 --logdir=/tmp
Translate to the following in code:
---
import std.log;
void main(string[] args)
{
FilterConfig filt
On 2011-05-29 17:06, Andrei Alexandrescu wrote:
On 5/29/11 5:07 AM, Jacob Carlborg wrote:
Why is everyone that contribute with a std.log implementation keep
insisting that it should be configured via command line options? This is
not how a library should be configured, it should be configured vi
On 05/29/2011 01:32 PM, Jacob Carlborg wrote:
Sometimes you are very consistent but other times you just want to go
with the shortest. Why can't we have it consistent?
Again, consistency is a relation, not a value, i.e. consistent with
_what_ is key. In this case I'm being consistent with glog
On 05/29/2011 12:25 PM, Jose Armando Garcia wrote:
Thanks. Comments below.
[snip]
All good points. Thanks!
Andrei
On 2011-05-29 20:34, Andrei Alexandrescu wrote:
On 05/29/2011 01:32 PM, Jacob Carlborg wrote:
Sometimes you are very consistent but other times you just want to go
with the shortest. Why can't we have it consistent?
Again, consistency is a relation, not a value, i.e. consistent with
_what_ is
On 5/29/2011 3:07 AM, Jacob Carlborg wrote:
Why is everyone that contribute with a std.log implementation keep insisting
that it should be configured via command line options?
What rolls down stairs
alone or in pairs,
and over your neighbor's dog?
What's great for a snack,
And fits on your back
On 5/29/11, Walter Bright wrote:
> On 5/29/2011 3:07 AM, Jacob Carlborg wrote:
>> Why is everyone that contribute with a std.log implementation keep
>> insisting
>> that it should be configured via command line options?
>
> What rolls down stairs
> alone or in pairs,
> and over your neighbor's dog
On 5/29/2011 8:44 AM, Andrei Alexandrescu wrote:
> 1. The fatal log should never be stripped. This is because execution of code
> after using fatal depends on compile-time
> flags, which is unacceptable. Logging to fatal should terminate the
> application regardless of circumstances. Otherwise
>
On 05/29/2011 01:42 PM, Jacob Carlborg wrote:
On 2011-05-29 20:34, Andrei Alexandrescu wrote:
On 05/29/2011 01:32 PM, Jacob Carlborg wrote:
Sometimes you are very consistent but other times you just want to go
with the shortest. Why can't we have it consistent?
Again, consistency is a relatio
Am 29.05.2011 23:07, schrieb Andrei Alexandrescu:
> On 05/29/2011 01:42 PM, Jacob Carlborg wrote:
>> On 2011-05-29 20:34, Andrei Alexandrescu wrote:
>>> On 05/29/2011 01:32 PM, Jacob Carlborg wrote:
Sometimes you are very consistent but other times you just want to go
with the shortest. W
Am 29.05.2011 22:57, schrieb Brad Roberts:
> On 5/29/2011 8:44 AM, Andrei Alexandrescu wrote:
>> 1. The fatal log should never be stripped. This is because execution of code
>> after using fatal depends on compile-time
>> flags, which is unacceptable. Logging to fatal should terminate the
>> appl
On Sun, 29 May 2011 08:40:16 +0900, Jose Armando Garcia
wrote:
The implementation and documentation for std.log is ready for viewing.
You can take a look at the doc at
http://jsancio.github.com/phobos/phobos/std_log.html. The source code
is at https://github.com/jsancio/phobos/blob/master/std
On 2011-05-29 10:25, Jose Armando Garcia wrote:
> Thanks. Comments below.
>
> On Sun, May 29, 2011 at 12:44 PM, Andrei Alexandrescu
> wrote:
> > 4. initLogging and initializeLogging are highly confusing names. Overload
> > them to share the same name, or rename one.
>
> Yeah. I don't like this e
On 5/29/11 11:43 PM, Masahiro Nakagawa wrote:
- every, first, after
These are useful? I can't image the use cases.
I think 'when(cond)' is enough.
These can be quite useful when logging from a function that is called
really frequently, where logging all calls would just flood the logs,
but yo
By default the module will read the command line arguments looking for
known option. For any option that is missing the default will be used.
The default for each option is described in FilterConfig,
VerboseConfig and LoggerConfig. I.e. the module works without any
explicit initialization by the us
That is a valid point. I think if we add critical and put a suggestion
in the doc that fatal should only be used in extreme cases because it
cannot be disabled. Then that should solve the problem. Going from
fatal to critical to error is only a regular expression away.
On Sun, May 29, 2011 at 5:57
Then use critical with all the exception handling techniques that D
provide, try, scope, etc. Maybe critical should allow the throwing of
user define exceptions with a meaningful default. What do people
think?
On Sun, May 29, 2011 at 6:20 PM, Daniel Gibson wrote:
> Am 29.05.2011 22:57, schrieb Br
Comments below.
Thanks!
2011/5/29 Masahiro Nakagawa :
> On Sun, 29 May 2011 08:40:16 +0900, Jose Armando Garcia
> wrote:
>
>> The implementation and documentation for std.log is ready for viewing.
>> You can take a look at the doc at
>> http://jsancio.github.com/phobos/phobos/std_log.html. The s
Am 30.05.2011 02:11, schrieb Jose Armando Garcia:
> Then use critical with all the exception handling techniques that D
> provide, try, scope, etc. Maybe critical should allow the throwing of
> user define exceptions with a meaningful default. What do people
> think?
>
I don't have much experienc
On Sun, May 29, 2011 at 9:37 PM, Daniel Gibson wrote:
> Am 30.05.2011 02:11, schrieb Jose Armando Garcia:
>> Then use critical with all the exception handling techniques that D
>> provide, try, scope, etc. Maybe critical should allow the throwing of
>> user define exceptions with a meaningful defa
Am 30.05.2011 03:07, schrieb Jose Armando Garcia:
> On Sun, May 29, 2011 at 9:37 PM, Daniel Gibson wrote:
>> Am 30.05.2011 02:11, schrieb Jose Armando Garcia:
>>> Then use critical with all the exception handling techniques that D
>>> provide, try, scope, etc. Maybe critical should allow the throw
On Sun, May 29, 2011 at 10:19 PM, Daniel Gibson wrote:
> Am 30.05.2011 03:07, schrieb Jose Armando Garcia:
>> On Sun, May 29, 2011 at 9:37 PM, Daniel Gibson wrote:
>>> Am 30.05.2011 02:11, schrieb Jose Armando Garcia:
Then use critical with all the exception handling techniques that D
p
Am 30.05.2011 03:40, schrieb Jose Armando Garcia:
> On Sun, May 29, 2011 at 10:19 PM, Daniel Gibson wrote:
>> [OT:] What is assert(false); supposed to do, anyway?
>> I think I've read it's supposed to terminates the program immediately
>> without any cleanups (which is unfortunate for a logging li
On 2011-05-29 18:19, Daniel Gibson wrote:
> Am 30.05.2011 03:07, schrieb Jose Armando Garcia:
> > On Sun, May 29, 2011 at 9:37 PM, Daniel Gibson
wrote:
> >> Am 30.05.2011 02:11, schrieb Jose Armando Garcia:
> >>> Then use critical with all the exception handling techniques that D
> >>> provide, t
On 2011-05-29 18:43, Daniel Gibson wrote:
> Am 30.05.2011 03:40, schrieb Jose Armando Garcia:
> > On Sun, May 29, 2011 at 10:19 PM, Daniel Gibson
wrote:
> >> [OT:] What is assert(false); supposed to do, anyway?
> >> I think I've read it's supposed to terminates the program immediately
> >> withou
On 2011-05-29 23:07, Andrei Alexandrescu wrote:
On 05/29/2011 01:42 PM, Jacob Carlborg wrote:
On 2011-05-29 20:34, Andrei Alexandrescu wrote:
On 05/29/2011 01:32 PM, Jacob Carlborg wrote:
Sometimes you are very consistent but other times you just want to go
with the shortest. Why can't we have
On 2011-05-30 01:59, Jose Armando Garcia wrote:
By default the module will read the command line arguments looking for
known option. For any option that is missing the default will be used.
The default for each option is described in FilterConfig,
VerboseConfig and LoggerConfig. I.e. the module w
On Sun, May 29, 2011 at 3:57 PM, Walter Bright
wrote:
> On 5/29/2011 3:07 AM, Jacob Carlborg wrote:
>>
>> Why is everyone that contribute with a std.log implementation keep
>> insisting
>> that it should be configured via command line options?
>
> What rolls down stairs
> alone or in pairs,
> and
On May 31, 11 00:59, Jose Armando Garcia wrote:
[snip]
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but instead get replaced by
the name of the module. This would be really useful for std.log's
verbosity filtering feature.
I ca
On 5/30/2011 9:59 AM, Jose Armando Garcia wrote:
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but instead get replaced by
the name of the module. This would be really useful for std.log's
verbosity filtering feature.
I don't kn
On 05/30/2011 01:02 PM, Walter Bright wrote:
On 5/30/2011 9:59 AM, Jose Armando Garcia wrote:
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but instead get replaced by
the name of the module. This would be really useful for std.l
On 30/05/2011 20:08, Andrei Alexandrescu wrote:
On 05/30/2011 01:02 PM, Walter Bright wrote:
On 5/30/2011 9:59 AM, Jose Armando Garcia wrote:
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but instead get replaced by
the name of
On May 31, 11 03:32, Robert Clipsham wrote:
On 30/05/2011 20:08, Andrei Alexandrescu wrote:
On 05/30/2011 01:02 PM, Walter Bright wrote:
On 5/30/2011 9:59 AM, Jose Armando Garcia wrote:
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LI
> On May 31, 11 00:59, Jose Armando Garcia wrote:
> [snip]
>>
>> Walter, what do you think about adding __MODULE__ to the language? It
>> will work similar to __FILE__ and __LINE__ but instead get replaced by
>> the name of the module. This would be really useful for std.log's
>> verbosity filterin
On May 31, 11 03:56, Timon Gehr wrote:
On May 31, 11 00:59, Jose Armando Garcia wrote:
[snip]
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but instead get replaced by
the name of the module. This would be really useful for std.
On Sun, 29 May 2011 16:57:52 -0400, Brad Roberts
wrote:
On 5/29/2011 8:44 AM, Andrei Alexandrescu wrote:
1. The fatal log should never be stripped. This is because execution of
code after using fatal depends on compile-time
flags, which is unacceptable. Logging to fatal should terminate the
On Tue, May 31, 2011 at 11:28 AM, Steven Schveighoffer
wrote:
> On Sun, 29 May 2011 16:57:52 -0400, Brad Roberts
> wrote:
>
>> On 5/29/2011 8:44 AM, Andrei Alexandrescu wrote:
>>>
>>> 1. The fatal log should never be stripped. This is because execution of
>>> code after using fatal depends on com
On Tue, 31 May 2011 12:28:12 -0400, Jose Armando Garcia
wrote:
On Tue, May 31, 2011 at 11:28 AM, Steven Schveighoffer
wrote:
On Sun, 29 May 2011 16:57:52 -0400, Brad Roberts
wrote:
On 5/29/2011 8:44 AM, Andrei Alexandrescu wrote:
1. The fatal log should never be stripped. This is becau
On Tue, May 31, 2011 at 2:34 PM, Steven Schveighoffer
wrote:
> On Tue, 31 May 2011 12:28:12 -0400, Jose Armando Garcia
> wrote:
>
>> On Tue, May 31, 2011 at 11:28 AM, Steven Schveighoffer
>> wrote:
>>>
>>> On Sun, 29 May 2011 16:57:52 -0400, Brad Roberts
>>> wrote:
>>>
On 5/29/2011 8:44 AM
On Tue, May 31, 2011 at 3:10 PM, Jose Armando Garcia wrote:
> On Tue, May 31, 2011 at 2:34 PM, Steven Schveighoffer
> wrote:
>> On Tue, 31 May 2011 12:28:12 -0400, Jose Armando Garcia
>> wrote:
>>
>>> On Tue, May 31, 2011 at 11:28 AM, Steven Schveighoffer
>>> wrote:
On Sun, 29 May 201
On Tue, 31 May 2011 14:10:20 -0400, Jose Armando Garcia
wrote:
On Tue, May 31, 2011 at 2:34 PM, Steven Schveighoffer
wrote:
Again, this sounds way too complicated for what it's giving you
(avoiding
having to forcibly kill your application if that's what you desire).
If I
had to choose
On 5/31/11 1:32 PM, Steven Schveighoffer wrote:
On Tue, 31 May 2011 14:10:20 -0400, Jose Armando Garcia
wrote:
On Tue, May 31, 2011 at 2:34 PM, Steven Schveighoffer
wrote:
Again, this sounds way too complicated for what it's giving you
(avoiding
having to forcibly kill your application if
On Tue, 31 May 2011 14:48:57 -0400, Andrei Alexandrescu
wrote:
On 5/31/11 1:32 PM, Steven Schveighoffer wrote:
On Tue, 31 May 2011 14:10:20 -0400, Jose Armando Garcia
wrote:
On Tue, May 31, 2011 at 2:34 PM, Steven Schveighoffer
wrote:
Again, this sounds way too complicated for what it
On Tue, 31 May 2011 15:09:07 -0400, Steven Schveighoffer
wrote:
On Tue, 31 May 2011 14:48:57 -0400, Andrei Alexandrescu
wrote:
I'm operating under the assumption that logCritical and logFatal are at
a different log level (i.e. the primary function of a logging facility
is to have diff
On 05/31/2011 09:29 PM, Steven Schveighoffer wrote:
On Tue, 31 May 2011 15:09:07 -0400, Steven Schveighoffer
wrote:
On Tue, 31 May 2011 14:48:57 -0400, Andrei Alexandrescu
wrote:
I'm operating under the assumption that logCritical and logFatal are
at a different log level (i.e. the primary
On 30/05/2011 18:41, KennyTM~ wrote:
On May 31, 11 00:59, Jose Armando Garcia wrote:
[snip]
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but instead get replaced by
the name of the module. This would be really useful for std.lo
On Jun 2, 11 22:47, Bruno Medeiros wrote:
On 30/05/2011 18:41, KennyTM~ wrote:
On May 31, 11 00:59, Jose Armando Garcia wrote:
[snip]
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but instead get replaced by
the name of the mod
On 2011-06-02 16:47, Bruno Medeiros wrote:
On 30/05/2011 18:41, KennyTM~ wrote:
On May 31, 11 00:59, Jose Armando Garcia wrote:
[snip]
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but instead get replaced by
the name of the mo
On 02/06/2011 16:28, KennyTM~ wrote:
On Jun 2, 11 22:47, Bruno Medeiros wrote:
On 30/05/2011 18:41, KennyTM~ wrote:
On May 31, 11 00:59, Jose Armando Garcia wrote:
[snip]
Walter, what do you think about adding __MODULE__ to the language? It
will work similar to __FILE__ and __LINE__ but inste
55 matches
Mail list logo
