On Monday, 8 December 2014 at 21:20:20 UTC, Andrei Alexandrescu
wrote:
On 12/4/14 8:37 PM, Robert burner Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but
rather
__MODULE__ ~ _loggerinfo.d and then describe the import
On 12/4/14 8:16 PM, Martin Nowak wrote:
On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg wrote:
On 2014-12-04 02:10, Martin Nowak wrote:
I just found a very compelling alternative solution to the LogLevel
disabling problem. This was one of the reasons for the delay of std.log
and
On 12/4/14 8:37 PM, Robert burner Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but rather
__MODULE__ ~ _loggerinfo.d and then describe the import constraint in
the documentation.
Perhaps that might improve error
On Thursday, 4 December 2014 at 14:32:27 UTC, Daniel Murphy wrote:
FWIW I don't really like this - it feels like a hack. I'd
rather just declare a private logger alias (or something like
that) and use that in the library. Decision can be made at
compile time, doesn't require reverse module
On Friday, 5 December 2014 at 10:30:08 UTC, Dicebot wrote:
On Thursday, 4 December 2014 at 14:32:27 UTC, Daniel Murphy
wrote:
FWIW I don't really like this - it feels like a hack. I'd
rather just declare a private logger alias (or something like
that) and use that in the library. Decision
On 2014-12-04 02:10, Martin Nowak wrote:
I just found a very compelling alternative solution to the LogLevel
disabling problem. This was one of the reasons for the delay of std.log
and the current solution still isn't great [1].
This idea here achieves
- fine grained control over log levels
On Thursday, 4 December 2014 at 01:10:43 UTC, Martin Nowak wrote:
```d
module mypkg.foo.bar;
public import mypkg.logLevel;
void baz(T)(T t)
{
info(baz);
}
```
Not bad. Does info=baz compile?
On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg
wrote:
On 2014-12-04 02:10, Martin Nowak wrote:
I just found a very compelling alternative solution to the
LogLevel
disabling problem. This was one of the reasons for the delay
of std.log
and the current solution still isn't great
On Thursday, 4 December 2014 at 08:42:36 UTC, Kagamin wrote:
Not bad. Does info=baz compile?
That's not my business, if it's callable with a single argument,
it would work, but it's not @property.
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but rather
__MODULE__ ~ _loggerinfo.d and then describe the import
constraint in the documentation.
On Thursday, 4 December 2014 at 10:16:52 UTC, Martin Nowak wrote:
On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg
hack. I have stopped following the std.log thread, could you
summarize what issues you're having and trying to solve and
why not a more obvious solution doesn't work?
As I have explained countless times, the configuration in source
and through inheritance will always be more powerful and flexible
than a config file. I'm not gone create any config file support,
as there will be always one feature missing and there is just no
way to anticipate all possible
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner
Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but
rather __MODULE__ ~ _loggerinfo.d and then describe the
import constraint in the documentation.
Good idea,
On Thursday, 4 December 2014 at 10:56:29 UTC, Robert burner
Schadek wrote:
As I have explained countless times, the configuration in
source and through inheritance will always be more powerful and
There is no contradiction. Configuration is level 1,
implementation is level 2.
On Thursday, 4 December 2014 at 10:44:22 UTC, Ola Fosheim Grøstad
wrote:
I like the direction you are taking, but I think the better
solution is to have:
It's a nice idea for generic feature testing flags, but it's a
lot of implementation work in the compiler. And it seems odd to
implement a
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner
Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but
rather __MODULE__ ~ _loggerinfo.d and then describe the
import constraint in the documentation.
Importing a
On Thursday, 4 December 2014 at 11:02:39 UTC, Martin Nowak wrote:
It's a nice idea for generic feature testing flags, but it's a
lot of implementation work in the compiler. And it seems odd to
implement a big part of a library in the compiler.
I think D lacks a generic project configuration
On Thursday, 4 December 2014 at 11:02:23 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 4 December 2014 at 10:56:29 UTC, Robert burner
Schadek wrote:
As I have explained countless times, the configuration in
source and through inheritance will always be more powerful and
There is no
On Thursday, 4 December 2014 at 11:49:53 UTC, Ola Fosheim Grøstad
wrote:
I think D lacks a generic project configuration mechanism. I
generally want configurations to be located in one or at least
a few files that are easy to modify and which can have tools
written for them. So yes, this
On Thursday, 4 December 2014 at 11:12:02 UTC, Martin Nowak wrote:
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner
Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but
rather __MODULE__ ~ _loggerinfo.d and then
On Thursday, 4 December 2014 at 12:16:54 UTC, Robert burner
Schadek wrote:
I think D lacks a good std.serialization module
That would be a good point if you did binary logging…
Martin Nowak wrote in message news:m5ocaj$2i8t$1...@digitalmars.com...
I just found a very compelling alternative solution to the LogLevel
disabling problem. This was one of the reasons for the delay of std.log
and the current solution still isn't great [1].
This idea here achieves
- fine
On 12/04/2014 03:32 PM, Daniel Murphy wrote:
FWIW I don't really like this - it feels like a hack. I'd rather just
declare a private logger alias (or something like that) and use that in
the library. Decision can be made at compile time, doesn't require
reverse module imports, doesn't depend
On 4/12/2014 2:10 p.m., Martin Nowak wrote:
I just found a very compelling alternative solution to the LogLevel
disabling problem. This was one of the reasons for the delay of std.log
and the current solution still isn't great [1].
This idea here achieves
- fine grained control over log levels
(I don't want to hijack the thread, and I'm so happy for donated
hours. If I my just touch on that JRE size maintenance team did
not add logging till 1.4
http://www.onjava.com/pub/a/onjava/2002/03/06/topten.html
- instead people used downstream. Pardon me)
On 12/04/2014 03:41 AM, Rikki Cattermole wrote:
Okay its a lot simpler and far less context specific.
One thing I think should be addressed is at runtime, to override these
defaults.
Just use a value instead of an enum, and you can configure the log level
at runtime.
26 matches
Mail list logo
