Am 14.10.2013 13:39, schrieb Dicebot:
As `std.logger` is still marked as "work in progress" this thread is
less formal that typical pre-voting review. Goal is to provide as much
input about desirable `std.logger` functionality and current state and
let module author to use this information for pr
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
As `std.logger` is still marked as "work in progress" this
thread is less formal that typical pre-voting review. Goal is
to provide as much input about desirable `std.logger`
functionality and current state and let module author to use
Having skimmed through the docs I noticed that there are three features
missing that I use and would like to see in standard logger. First is
the ability to write to several loggers at once, the second is optional
formatting of log output and the third is an option to tell logger to
log only one co
My own few comments from quick overview of the documentation
(must admit I did not pay much attention to previous logger
discussion threads).
=== critical ===
1)
I don't like forced verbosity of mentioning logging levels. In my
opinion logging is one place where laconic syntax elegance reall
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
As `std.logger` is still marked as "work in progress" this
thread is less formal that typical pre-voting review. Goal is
to provide as much input about desirable `std.logger`
functionality and current state and let module author to use
On Monday, 14 October 2013 at 12:45:06 UTC, Dicebot wrote:
=== possible features? ===
One interesting addition would be to embed module name into
logger call and provide facilities to filter output on
per-module basis (similar to log level). D introspection tools
should allow to do that with
On 10/14/2013 02:39 PM, Sönke Ludwig wrote:
> Am 14.10.2013 13:39, schrieb Dicebot:
>> As `std.logger` is still marked as "work in progress" this thread is
>> less formal that typical pre-voting review. Goal is to provide as much
>> input about desirable `std.logger` functionality and current state
On 10/14/2013 02:42 PM, Vladimir Panteleev wrote:
> Would be nice if either FileLogger, or a "proxy" logger available to
> users, would add timestamps. Timestamps are very useful for log files,
> as they allow to correlate logged events with other events on the
> system (e.g. other applications' lo
On 10/14/2013 02:32 PM, Martin Drasar wrote:
> Having skimmed through the docs I noticed that there are three features
> missing that I use and would like to see in standard logger. First is
> the ability to write to several loggers at once, the second is optional
> formatting of log output and the
On 10/14/2013 02:51 PM, Andrea Fontana wrote:
> Just for comparison, on Android you can write something like:
> FileLogger.w(...) instead of FileLogger.log(LogLevel.Warning...)
>
> (and there's a "wtf" loglevel for "temporary" debugging)
>
hm, I don't really like it. To me it sounds like, "I'm don
On 14.10.2013 15:18, Robert Schadek wrote:
> On 10/14/2013 02:32 PM, Martin Drasar wrote:
>> 1) MultiLogger class that takes references to other loggers and just
>> forwards the call to the log function.
> will be done, see the reply to Sönke's post.
Cool
>> 2) Optional string parameter that desc
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
As `std.logger` is still marked as "work in progress" this
thread is less formal that typical pre-voting review. Goal is
to provide as much input about desirable `std.logger`
functionality and current state and let module author to use
On 10/14/2013 03:31 PM, Martin Drasar wrote:
> On 14.10.2013 15:18, Robert Schadek wrote:
>> On 10/14/2013 02:32 PM, Martin Drasar wrote:
>>> 1) MultiLogger class that takes references to other loggers and just
>>> forwards the call to the log function.
>> will be done, see the reply to Sönke's pos
On 14.10.2013 15:43, Robert Schadek wrote:
> On 10/14/2013 03:31 PM, Martin Drasar wrote:
> Yes, but you have to lookup the formatting parameter, which adds some
> complexity. It would also a time complexity for each logging call,
> because you would have to parse the format. IMO KISS.
Ok, let's h
Am 14.10.2013 15:12, schrieb Robert Schadek:
> On 10/14/2013 02:39 PM, Sönke Ludwig wrote:
>> - The static methods in LogManager should be made global and the class
>>be removed. It's not for objects so it shouldn't be a class.
> LogManager also stores the global log level. Sure I can make ano
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
As `std.logger` is still marked as "work in progress" this
thread is less formal that typical pre-voting review. Goal is
to provide as much input about desirable `std.logger`
functionality and current state and let module author to use
On Monday, 14 October 2013 at 13:39:10 UTC, Byron wrote:
** System logging: syslog and windows event logging support.
+1, add System logging, and use as default windows event logging
for windows and syslog for POSIX.
And remote log support for syslog to allow send log messages via
network.
Some comments from the peanut gallery:
* Mentioned already: configurable log output. Configure style/contents of
log output based on output location. More options for included info
(thread id, etc). Allow custom info to be inserted based on logger context.
* Also mentioned: Configurable log ro
Also:
* Asynchronous logging. Log something and continue, not blocking on actual
message getting written. Can write a custom logger that works this way,
but would be nice if this was supported at the base level.
On Mon, Oct 14, 2013 at 10:01 AM, Jeremy Powers wrote:
> Some comments from the p
On 10/14/2013 05:27 PM, ilya-stromberg wrote:
>
> Add e-mail logger (useful for critical errors) for example via
> `std.net.curl.SMTP`.
And than at a email format config parser that fulfills everyones wishes,
would bet the idea of the design. And I though people where trying to
remove curl.
On 10/14/2013 04:44 PM, Sönke Ludwig wrote:
> Am 14.10.2013 15:12, schrieb Robert Schadek:
>> On 10/14/2013 02:39 PM, Sönke Ludwig wrote:
>>> - The static methods in LogManager should be made global and the class
>>>be removed. It's not for objects so it shouldn't be a class.
>> LogManager als
On Monday, 14 October 2013 at 18:00:12 UTC, Robert Schadek wrote:
On 10/14/2013 05:27 PM, ilya-stromberg wrote:
Add e-mail logger (useful for critical errors) for example via
`std.net.curl.SMTP`.
And than at a email format config parser that fulfills
everyones wishes,
would bet the idea of the
It's weird that LogManager.defaultLogger exists as a read-only
property, and if I want to change it I have to use the global
static "log" variable.
I think this was mentioned elsewhere, but is the global logger
thread-local, shared, or __gshared? Or is this something we can
control? I can s
On Monday, 14 October 2013 at 12:40:16 UTC, Sönke Ludwig wrote:
Am 14.10.2013 13:39, schrieb Dicebot:
- For me this logger is completely worthless without any debug
log levels. The last std.log entry had at least anonymous
verbosity
levels, but I'd prefer something like I did in vibe.d [1],
w
On 2013-10-14 20:24, Robert Schadek wrote:
At least jmdavis had a very strong argument against it. Something like
function should be verbs ... Maybe something like logCritical, logInfo
would be a compromise, but I think everybody here has a different idea
of what is correct.
If "log.info" is u
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
As `std.logger` is still marked as "work in progress" this
thread is less formal that typical pre-voting review. Goal is
to provide as much input about desirable `std.logger`
functionality and current state and let module author to use
> Orthogonal to log levels one idea could be to define a namespace for a
logger instance.
Take a look at the way log4j does it, with logger hierarchy:
http://logging.apache.org/log4j/1.2/manual.html
This is incredibly useful.
On 10/14/2013 08:29 PM, ilya-stromberg wrote:
>
> I said: "for example via `std.net.curl.SMTP`". If you don't want to
> use curl, you shouldn't. But yes, I think that e-mail logger can be
> useful. For example Linux use it (and bash can send errors via e-mail).
>
> About "email format config parser
On 10/14/2013 08:55 PM, Sean Kelly wrote:
> It's weird that LogManager.defaultLogger exists as a read-only
> property, and if I want to change it I have to use the global static
> "log" variable.
this will be properly be fixed in the next incarnation (tonight, no
promises)
>
> I think this was ment
On Monday, 14 October 2013 at 20:49:19 UTC, Robert Schadek wrote:
I disagree on having a simple email layer among the default
logger,
because I feel that having this "special" logger in would water
the
design of the logging module. Maybe you are happy with a simple
string
message mail with
On 10/14/2013 09:59 PM, ponce wrote:
> Thanks for taking care of that.
> My logger class logs warning in yellow and errors in red ;),
colors are awesome I now, but hard to do across all shells and even
worse when you want to pipe the messages in a file afterwards. So I
suggest you implement your ow
On 10/14/2013 11:01 PM, Sean Kelly wrote:
> On Monday, 14 October 2013 at 20:49:19 UTC, Robert Schadek wrote:
>>
>> I disagree on having a simple email layer among the default logger,
>> because I feel that having this "special" logger in would water the
>> design of the logging module. Maybe you
On Monday, 14 October 2013 at 20:06:52 UTC, Jeremy Powers wrote:
Take a look at the way log4j does it, with logger hierarchy:
http://logging.apache.org/log4j/1.2/manual.html
This is incredibly useful.
It is useful but it's also a pain to configure. I used logback (
http://logback.qos.ch/ ) wh
On 10/14/2013 07:01 PM, Jeremy Powers wrote:
> Some comments from the peanut gallery:
>
> * Mentioned already: configurable log output. Configure
> style/contents of log output based on output location. More options
> for included info (thread id, etc). Allow custom info to be inserted
> based o
> It is useful but it's also a pain to configure. I used logback (
> http://logback.qos.ch/ ) which is a bit nicer but still... We should
> definitely step away from XML's configuration mess.
>
Yeah, there's a reason I linked to the old docs and not the newer
xml-centric stuff. The important bit
On Monday, 14 October 2013 at 19:47:19 UTC, Jacob Carlborg wrote:
On 2013-10-14 20:24, Robert Schadek wrote:
At least jmdavis had a very strong argument against it.
Something like
function should be verbs ... Maybe something like logCritical,
logInfo
would be a compromise, but I think everybod
On 10/14/2013 11:10 PM, Guillaume Chatelet wrote:
>
> It is useful but it's also a pain to configure. I used logback (
> http://logback.qos.ch/ ) which is a bit nicer but still... We should
> definitely step away from XML's configuration mess.
Did somebody say XML, I first cast a stone. ;-) But ser
On Monday, 14 October 2013 at 21:22:51 UTC, Robert Schadek wrote:
module myModule;
Logger myModuleLogger;
static this() {
myModuleLogger = new StdIOLogger();
}
I'd like to have module-specific logging _without_ creating local
module instance. And without referring to specific logger at all
Comments on comments. And to be clear, this is just me wanting everything
to be amazing - I'm incredibly glad to have any logging framework at all,
and will use what I can get.
>> Allow custom info to be inserted based on logger context.
> don't think that this is a good way to good, complexity
On Mon, Oct 14, 2013 at 2:27 PM, Dicebot wrote:
> I'd like to have module-specific logging _without_ creating local module
> instance. And without referring to specific logger at all. As I have
> mentioned, something like:
> ```
> import log = std.logger;
> log.local.info(...); // uses special de
On Monday, 14 October 2013 at 22:04:44 UTC, Jeremy Powers wrote:
And the shed should be blue.
I vote that we paint it octarine: a nice color that's not too
purple and yet not too green and can only be created with magic.
So far nobody has painted a bike shed to my satisfaction and I
can't un
A few concerns:
There doesn't seem to be a debug or trace log level. This is
quite a useful thing to have once your program is deployed.
I don't like the returning by ref for log methods. For example,
it seems like you can do: log(5 < 4, "This is a test log") = new
StdIOLogger();
It could po
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
Lets unleash the forces of constructive destruction.
So, not to be too heavy-handed with criticism on this library,
but I think this should come up to par with solutions like log4j,
log4cpp, or log4cxx, with respect to features and ca
On 2013-10-14 23:22, Dicebot wrote:
If we need to care about that, D module system is a failure.
But I don't think it is a valid concern.
People already complain about conflict function names in Phobos.
--
/Jacob Carlborg
Am 15.10.2013 09:08, schrieb Jacob Carlborg:
On 2013-10-14 23:22, Dicebot wrote:
If we need to care about that, D module system is a failure.
But I don't think it is a valid concern.
People already complain about conflict function names in Phobos.
And I'd agree with them. At least inside o
Am 14.10.2013 20:24, schrieb Robert Schadek:
On 10/14/2013 04:44 PM, Sönke Ludwig wrote:
Am 14.10.2013 15:12, schrieb Robert Schadek:
On 10/14/2013 02:39 PM, Sönke Ludwig wrote:
- The static methods in LogManager should be made global and the class
be removed. It's not for objects so it
On Monday, 14 October 2013 at 12:48:14 UTC, Martin Drasar wrote:
1) MultiLogger class that takes references to other loggers and
just
forwards the call to the log function.
+1
Also, we should support a few loggers whith same type. For
example, I can use 2 file loggers: the 1-st only for debug
On 10/15/2013 04:06 AM, Eric Anderton wrote:
> On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
>> Lets unleash the forces of constructive destruction.
>
> So, not to be too heavy-handed with criticism on this library, but I
> think this should come up to par with solutions like log4j, lo
On 10/15/2013 02:44 AM, Kapps wrote:
> A few concerns:
>
> There doesn't seem to be a debug or trace log level. This is quite a
> useful thing to have once your program is deployed.
there is a LogLevel.debug and a LogLevel.info
>
> I don't like the returning by ref for log methods. For example, it
On 10/15/2013 09:32 AM, Sönke Ludwig wrote:
> Am 15.10.2013 09:08, schrieb Jacob Carlborg:
>> On 2013-10-14 23:22, Dicebot wrote:
>>
>>> If we need to care about that, D module system is a failure.
>>> But I don't think it is a valid concern.
>>
>> People already complain about conflict function na
What are the philosophy behind errors vs fatal errors vs critical
errors?
When should we use each of these?
On Monday, 14 October 2013 at 18:29:09 UTC, ilya-stromberg wrote:
On Monday, 14 October 2013 at 18:00:12 UTC, Robert Schadek
wrote:
If you disagree, please tell why.
If you want a logger with a particular feature, this module will
allow to create a custom logger.
It would be a mistake to in
On 10/15/2013 09:40 AM, Sönke Ludwig wrote:
> Am 14.10.2013 20:24, schrieb Robert Schadek:
>> On 10/14/2013 04:44 PM, Sönke Ludwig wrote:
>>> The same could be said about the global "log" functions, which are
>>> tightly coupled to that state. I think this is already nicely grouped
>>> together by
On 10/15/2013 09:44 AM, ilya-stromberg wrote:
> On Monday, 14 October 2013 at 12:48:14 UTC, Martin Drasar wrote:
>> 1) MultiLogger class that takes references to other loggers and just
>> forwards the call to the log function.
>
> +1
> Also, we should support a few loggers whith same type. For exam
On 10/15/2013 10:49 AM, ponce wrote:
> What are the philosophy behind errors vs fatal errors vs critical errors?
> When should we use each of these?
fatal = the application is going down, I'm just letting you know
critical = the application is maybe going down, I'm not sure yet, but
this is a probl
On Tuesday, 15 October 2013 at 07:33:15 UTC, Sönke Ludwig wrote:
Am 15.10.2013 09:08, schrieb Jacob Carlborg:
On 2013-10-14 23:22, Dicebot wrote:
If we need to care about that, D module system is a failure.
But I don't think it is a valid concern.
People already complain about conflict funct
Am 15.10.2013 10:54, schrieb Robert Schadek:
On 10/15/2013 09:40 AM, Sönke Ludwig wrote:
Am 14.10.2013 20:24, schrieb Robert Schadek:
On 10/14/2013 04:44 PM, Sönke Ludwig wrote:
The same could be said about the global "log" functions, which are
tightly coupled to that state. I think this is al
On 10/15/2013 02:54 PM, Sönke Ludwig wrote:
> What I meant is just that in Druntime there is something like this:
>
> struct LogManager {
> static void somefunc();
> }
>
> instead of
>
> class LogManager {
> static void someFunc();
> }
>
> In any case, such a struct/class should also have a mem
Am 15.10.2013 10:41, schrieb Robert Schadek:
On 10/15/2013 02:44 AM, Kapps wrote:
The simple act of logging a message is very verbose right now:
log(LogLevel.trace, "Creating new pool") is a lot of boiler plate. I'd
prefer something like log.trace("Creating new pool") and log("Creating
new pool"
On Tuesday, 15 October 2013 at 07:52:28 UTC, Robert Schadek wrote:
On 10/15/2013 04:06 AM, Eric Anderton wrote:
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
Here's what I think is missing:
- System log support (as others have mentioned). This would
be syslog
or WEL, depending on
On 10/15/2013 03:21 PM, Sönke Ludwig wrote:
> Am 15.10.2013 10:41, schrieb Robert Schadek:
>> On 10/15/2013 02:44 AM, Kapps wrote:
>>> The simple act of logging a message is very verbose right now:
>>> log(LogLevel.trace, "Creating new pool") is a lot of boiler plate. I'd
>>> prefer something like
On Tuesday, 15 October 2013 at 13:31:40 UTC, ilya-stromberg wrote:
...
I think such stuff should go as an extra module in same package
with various useful out-of-the box logger implementations at the
very best. Probably even dub package built on top of std.logger;
Phobos has very specific g
On 10/15/2013 03:31 PM, ilya-stromberg wrote:
> On Tuesday, 15 October 2013 at 07:52:28 UTC, Robert Schadek wrote:
>> On 10/15/2013 04:06 AM, Eric Anderton wrote:
>>> On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
>>> Here's what I think is missing:
>>> - System log support (as others h
But actual batteries - no, this does belong to Phobos.
* does not belong
On Tuesday, 15 October 2013 at 13:52:17 UTC, Robert Schadek wrote:
I think this is good, as it gives you a way to quite libraries
down. The
idea behind the free standing "log" function is to provide an
ultra easy
way to log. It is not meant to be used for the 2<<31 line
program. In
that case yo
On 10/15/2013 03:54 PM, Dicebot wrote:
> On Tuesday, 15 October 2013 at 13:31:40 UTC, ilya-stromberg wrote:
>> ...
>
> I think such stuff should go as an extra module in same package with
> various useful out-of-the box logger implementations at the very best.
> Probably even dub package built on t
On 10/15/2013 03:57 PM, Dicebot wrote:
> On Tuesday, 15 October 2013 at 13:52:17 UTC, Robert Schadek wrote:
>> I think this is good, as it gives you a way to quite libraries down. The
>> idea behind the free standing "log" function is to provide an ultra easy
>> way to log. It is not meant to be us
On Tuesday, 15 October 2013 at 13:54:12 UTC, Dicebot wrote:
On Tuesday, 15 October 2013 at 13:31:40 UTC, ilya-stromberg
wrote:
...
I think such stuff should go as an extra module in same package
with various useful out-of-the box logger implementations at
the very best. Probably even dub pac
Am 15.10.2013 15:52, schrieb Robert Schadek:
On 10/15/2013 03:21 PM, Sönke Ludwig wrote:
Am 15.10.2013 10:41, schrieb Robert Schadek:
On 10/15/2013 02:44 AM, Kapps wrote:
The simple act of logging a message is very verbose right now:
log(LogLevel.trace, "Creating new pool") is a lot of boiler
On Tuesday, 15 October 2013 at 14:09:36 UTC, ilya-stromberg wrote:
I did not talk about additional external libraries. As I know,
Vibe.d use OpenSSL to provide SSL streams. Since we haven't got
encryption support in Phobos, we can provide only TCP streams.
For example, sending mail is clearly
On 10/15/2013 04:12 PM, Sönke Ludwig wrote:
>
> Believe it or not, for some reason I suspected as much.
>
> Yes, but the point is that when looking only at func1, you might
> expect that all messages are logged as debug messages, but the last
> one will be logged as a warning instead. func2 may be
On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig wrote:
Am 15.10.2013 15:52, schrieb Robert Schadek:
On 10/15/2013 03:21 PM, Sönke Ludwig wrote:
Am 15.10.2013 10:41, schrieb Robert Schadek:
On 10/15/2013 02:44 AM, Kapps wrote:
The simple act of logging a message is very verbose right
On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote:
On 10/15/2013 04:12 PM, Sönke Ludwig wrote:
Believe it or not, for some reason I suspected as much.
Yes, but the point is that when looking only at func1, you
might
expect that all messages are logged as debug messages, but th
Am 15.10.2013 15:31, schrieb ilya-stromberg:
On Tuesday, 15 October 2013 at 07:52:28 UTC, Robert Schadek wrote:
On 10/15/2013 04:06 AM, Eric Anderton wrote:
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
Here's what I think is missing:
- System log support (as others have mentioned)
On Tuesday, 15 October 2013 at 14:13:53 UTC, Dicebot wrote:
On Tuesday, 15 October 2013 at 14:09:36 UTC, ilya-stromberg
wrote:
I did not talk about additional external libraries. As I know,
Vibe.d use OpenSSL to provide SSL streams. Since we haven't
got encryption support in Phobos, we can prov
On 10/15/2013 04:17 PM, ilya-stromberg wrote:
> On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig wrote:
>> But if it's available people _will_ use it in complex contexts. Also
>> if the writer of a 2<<8 loc library uses it and the library is used
>> by a large piece of software, that will
On 10/15/2013 04:23 PM, ilya-stromberg wrote:
> On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote:
>> Logging is the most unpure functionality I can think of. It is side
>> effect heaven.
>
> Yes, but we should minimise possible side effects.
Of course, but having global state aka.
Am 15.10.2013 16:33, schrieb Robert Schadek:
On 10/15/2013 04:23 PM, ilya-stromberg wrote:
On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote:
Logging is the most unpure functionality I can think of. It is side
effect heaven.
Yes, but we should minimise possible side effects.
On Tuesday, 15 October 2013 at 14:25:55 UTC, Robert Schadek wrote:
On 10/15/2013 04:17 PM, ilya-stromberg wrote:
On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig
wrote:
But if it's available people _will_ use it in complex
contexts. Also
if the writer of a 2<<8 loc library uses it and
On 10/15/13 12:52 AM, Robert Schadek wrote:
On 10/15/2013 04:06 AM, Eric Anderton wrote:
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
Lets unleash the forces of constructive destruction.
So, not to be too heavy-handed with criticism on this library, but I
think this should come
On Tue, Oct 15, 2013 at 8:17 AM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> One note - log4j, log4cxx, and log4cpp are not part of the respective
> languages' standards. That doesn't mean much (in fact it may be a
> competitive advantage to integrating log4d in std) but it is on
On 2013-10-15 16:13, Dicebot wrote:
For example, sending mail is clearly relying on external stuff and
should never be in Phobos (again, std.net.curl was a terrible mistake)
I don't see why this couldn't be included in Phobos, if it doesn't have
any external dependencies.
--
/Jacob Carlborg
On Tuesday, 15 October 2013 at 07:52:28 UTC, Robert Schadek wrote:
On 10/15/2013 04:06 AM, Eric Anderton wrote:
Here's what I think is missing:
- System log support (as others have mentioned). This would
be syslog
or WEL, depending on environment.
This is sort of the idea of the design, I can
On 10/16/2013 01:34 AM, Jeremy Powers wrote:
> On Tue, Oct 15, 2013 at 8:17 AM, Andrei Alexandrescu
> mailto:seewebsiteforem...@erdani.org>>
> wrote:
>
> One note - log4j, log4cxx, and log4cpp are not part of the
> respective languages' standards. That doesn't mean much (in fact
> it ma
Short version of below:
I want a powerful logging system. Maybe std.logging should provide the
interface with some basic functionality, allow other solutions to fill in
gaps. Should be able to always code against std.logging, complications
added as needed w/o code calling log() caring or changing
On 10/16/2013 08:18 PM, Jeremy Powers wrote:
> Short version of below:
> I want a powerful logging system. Maybe std.logging should provide
> the interface with some basic functionality, allow other solutions to
> fill in gaps. Should be able to always code against std.logging,
> complications ad
On Tuesday, 15 October 2013 at 15:16:44 UTC, Andrei Alexandrescu
wrote:
Eric, could you please enumerate a short list of features of
log4j that you think would be really missed if absent?
Certainly. Here's my top 3, with some background to explain why
I think they'd be missed.
- Hierarchica
On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton wrote:
The strength of this is that it would allow us to freely
integrate D libraries that use std.logger, yet filter their log
output from *outside* the library through the std.logger API.
This is one of the most important aspects in
On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton wrote:
On Tuesday, 15 October 2013 at 15:16:44 UTC, Andrei
Alexandrescu wrote:
Eric, could you please enumerate a short list of features of
log4j that you think would be really missed if absent?
Certainly. Here's my top 3, with some
On 10/17/2013 09:34 AM, qznc wrote:
> On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton wrote:
>> The strength of this is that it would allow us to freely integrate D
>> libraries that use std.logger, yet filter their log output from
>> *outside* the library through the std.logger API.
>
On 10/17/2013 04:13 AM, Eric Anderton wrote:
> On Tuesday, 15 October 2013 at 15:16:44 UTC, Andrei Alexandrescu wrote:
>> Eric, could you please enumerate a short list of features of log4j
>> that you think would be really missed if absent?
>
> Certainly. Here's my top 3, with some background to e
Can you please re-generate the documentation after all recent
updates?
On 10/18/2013 02:55 PM, Dicebot wrote:
> Can you please re-generate the documentation after all recent updates?
I usually do that. The only documentation missing is for MultiLogger, as
I'm not sure if the current implementation is done.
On Friday, 18 October 2013 at 13:35:19 UTC, Robert Schadek wrote:
On 10/18/2013 02:55 PM, Dicebot wrote:
Can you please re-generate the documentation after all recent
updates?
I usually do that. The only documentation missing is for
MultiLogger, as
I'm not sure if the current implementation is
On 10/18/2013 03:49 PM, Dicebot wrote:
> On Friday, 18 October 2013 at 13:35:19 UTC, Robert Schadek wrote:
>> On 10/18/2013 02:55 PM, Dicebot wrote:
>>> Can you please re-generate the documentation after all recent updates?
>> I usually do that. The only documentation missing is for MultiLogger, as
Also, Tango have log module:
https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d
For example, "Funkwerk IT Karlsfeld" use it because Phobos
haven't got logger:
http://dconf.org/talks/rohe.html
On 10/20/2013 08:52 AM, ilya-stromberg wrote:
> Also, Tango have log module:
> https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d
I looked through the source and IMO the tango logger is my logger + (
configuration and more default logger) or the other way round. And this
thread
On Sunday, 20 October 2013 at 10:56:44 UTC, Robert Schadek wrote:
On 10/20/2013 08:52 AM, ilya-stromberg wrote:
Also, Tango have log module:
https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d
I looked through the source and IMO the tango logger is my
logger + (
configuration
On Wednesday, 16 October 2013 at 07:18:39 UTC, ilya-stromberg
wrote:
Disagree. We need a log rotation support.
As I can see, available options could be:
* rotating conditions
- by date (rotate every hour, day (default), week, month, year)
- by file size (rotate if file size more than ... Mb)
On Sunday, 20 October 2013 at 15:34:50 UTC, Sean Kelly wrote:
On Wednesday, 16 October 2013 at 07:18:39 UTC, ilya-stromberg
wrote:
Disagree. We need a log rotation support.
As I can see, available options could be:
* rotating conditions
- by date (rotate every hour, day (default), week, month,
1 - 100 of 123 matches
Mail list logo
