std.logger

[burner]

Logging facilities for Phobos.

Docu:
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_package.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_core.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_filelogger.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_multilogger.html
http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_nulllogger.html

dub
http://code.dlang.org/packages/logger

[JakobOvrum]

Please open a thread on the official D forums/newsgroup to facilitate discussion and review for any new Phobos module proposition. Consult the review queue and review process wiki pages for more information.

[burner]

I have send the mail minutes ago. Should pop up every second now

[monarchdodra]

I think you meant s/Fatel/Fatal/g ? Fatel ain't no english I know of.

[burner]

shit, My feult ;-)

[burner]

bump, I really could use some comments on this one.

[ghost]

�Really cool, very glad someone is looking at this.

Some suggestions:

1. Add Debug and Trace log levels, in the order: Trace < Debug < Info < Warning < Error < Critical < Fatal . "Trace" is meant for logging function enter and exit. "Debug" is for general debugging, the equivalent of JDK logger's Fine or Log4perl's Debug.
2. Speaking of Log4perl, instead of sub-classing a Logger to get different outputs (file, stdio), you might consider adopting the Log4j/Log4perl method of appenders. What's nice about that is the same log message can appear in multiple appenders, so for example there could be a logfile containing only Error+ messages and another containing Debug+ messages. You could still have a FileLogger, which would just be a Logger with its first appender being to a file.
3. Convenience functions Logger.info(), Logger.warning(), etc. which always pass to logf(LogLevel, ...).
4. The quick-and-dirty logger I've been using: http://bazaar.launchpad.net/~kevin-lamonte/nib/devel/view/head:/source/logging.d . Might be something useful in there.
5. Might consider adopting Log4perl-like configuration file with the init_and_watch() functionality, so that someone can enable/disable logging on-the-fly externally.

[burner]

thanks for your input. I will look into it

[grogancolin]

Would it be possible to add convenience methods for each log level like:
logger.logDebug("This is a debug message");
logger.logInfo("This is an info message");
logger.logSevere(...);
logger.logFatal(...);

This would be easier than typing:
logger.log(LogLevel.Info, "...");
every time?

Edit:
I see that this has already been suggested above.

[burner]

It is already implemented this way. As these methods are just proxy to the original log(LogLevel, ...) method and are therefor trivial to implement, I used a mixin to create them. Unfortunately https://d.puremagic.com/issues/show_bug.cgi?id=648 currently stops documentation from being generated.

[fugalh]

I like it. I agree a super-noisy-debug level (trace, spew, whatever you call it) is a good thing to have, then you can leave some very noisy but occasionally useful logging statements in the code for those really hairy debug sessions, without making debug output useless for daily debugging.

Tracing messages can be really useful - entering/exiting a function - especially if you auto-indent them. I once wrote a few log functions that did that, they incremented and decremented the indent level. As long as the coder put them in the right place it worked well. I wonder if you could do that automagically in D (or whether that would even be a good idea to trace all functions).

It loks like the fatal level doesn't actually terminate the program. Some logging libraries trigger the end of program when a fatal message is logged. Just how you would want to terminate in D I'm not sure. SIGABRT? Without the termination behavior, what value does it add above the critical level? I'm not sure it adds anything, but having the extra level doesn't bother me either.

[burner]

How about making the LogLevel a bitset, so you log traces and react on fatal?

Scope tracing is easy, RAII. I will add a something to do that.

I know, but I'm not sure how to quit a program the "correct" way. Maybe with exit.

[fugalh]

A bitset sounds like more sophistication than is needed, but as long as I can do log.warning() etc. I'm happy.

The thing with exiting is people set up signal handlers to do cleanup, which don't get called if you just exit(). An exception might be appropriate. Or maybe not exiting at all, and just let people use critical followed with exiting however they want. Or maybe it's ok that the exit is exceptional and signal handlers don't get called.

I sometimes get frustrated when I'm reading code and come across a fatal log call because I have to go figure out if the logging framework they're using does or does not terminate (and how) on a fatal-level logging call.

[burner]

warning will stay, no doubt about that.

I know what you mean, side-effect-hell.
Maybe throwing an Error by default and allowing a delegate as a custom hook?

[Geod24]

IMHO, it would be a bad idea to terminate it on fatal. This may be something some library do, but I don't think it's a good practice to do that in the standard library.

[burner]

I pushed a new version which calls a assignable delegate on fatal messages.

[andralex]

I have one request. Seems like there's no way to turn logging on/off during compilation. The only mechanism I saw is version(DisableLogging) but I was hoping for more - fine-grained control of what level is allowed for logging, and no overhead for anything disabled.

I also recall the previous proposal had some nice mechanisms for throttling logging ("log this once in n calls" or "log this once in n milliseconds"). Any plans to integrate that?

[burner]

I will add version(Disable[Trace,Info,Warning,...]Logging) and version(Disable[Stdio,File,Multi]Logging) statements.

std.log had a "when filter". std.logger takes a boolean as the first arguments. Appropriate predicates are very user specific, IMO. I would rather stay very generic here.

[braddr]

Just a reminder, this pull request should NOT be merged without having gone through the standard new module review process. std.log[ger] is too critical a component to sneak in by way of a pull request without proper review and discussion. Particularly considering that the last review of a similar module didn't pass the review.

[burner]

That will not happen. https://d.puremagic.com/issues/show_bug.cgi?id=648 has to be fixed before it can be merged, because most documentation is generated.

@AndrejMitrovic

[ghost]

Yeah well every time I ping people it takes 1+ months for a response, by the time the pull needs another rebase. I'm not gonna rebase 10 times a year.

[burner]

Well, that are bad news, at least for me. I'm not big into the dmd source, but the code looks not that hard and I'm will willing to rebase. I now see that it only works for template mixins and not normal templates, as far as I see. I would like to work on your patch, If you don't mind ? @AndrejMitrovic

[ghost]

That's not the problem, I can rebase it. But I need someone around who's willing to review and pull soon.

[andralex]

@burner fine - just make sure you don't evaluate arguments if the condition is false (I recall that was what made when() desirable).

[burner]

if there is a bool passed, the first line in reads

if (cond &&

[andralex]

@burner I'm referring to the arguments passed to the logging functions. Consider:

logger.log(sometimes(), "We're in file: " ~ file);

vs.

if (sometimes()) logger.log("We're in file: " ~ file);

In the first case you need to carefully make your parameters scope lazy to make sure concatenation isn't done when sometimes() is false. Make sure the right code is generated by using e.g. http://d.godbolt.org. I recall I made some experiments work but it took some tweaking.

[burner]

it lazy now

[burner]

I updated the docs, and the github preview (see the link at the top)

[MetaLang]

Isn't lazy very slow? Is using lazy worth it just to avoid concatenating some strings?

[burner]

It is not just used to concatenate strings, it is used to pass the args for the printf version in. They may require expensive computation and are not always need.

[burner]

take your time I waited 1.5 Years

[mihails-strasuns]

Reduced to this DMD bug:

static if (__traits(compiles, { import missing; }))
{
    pragma(msg, "importing missing");
    import missing;
}
else
{
    pragma(msg, "not importing missing");
}

/*
$ ./dmd/src/dmd -o- -v reduced.d 
binary    ./dmd/src/dmd
version   v2.067-devel-6b86b12
config    ./dmd/src/dmd.conf
parse     reduced
importall reduced
import    object    (/home/dicebot/devel/dlang/druntime/src/object.di)
semantic  reduced
import    missing   (missing.d)
not importing missing
semantic2 reduced
semantic3 reduced
*/

It manifests on all DMD versions I have used, doesn't matter what kind of installation it is (it doesn't even use runtime or phobos). I have no idea why it works for you to be honest. Maybe you have a rogue test_loggerconfig.d hidden somewhere in the system? :)

[mihails-strasuns]

https://issues.dlang.org/show_bug.cgi?id=14050

ping @andralex @WalterBright

[burner]

that is very strange. I just copied the test and ran it. it did not import missing.

I tested on two separated machines multiple times in different folders.

[mihails-strasuns]

it does not actually import (second pragma triggers) but lists it in verbose output in import list. It isn't there on your machine?

[burner]

"""
import foo (foo.d)
not importing foo
"""

but it does not fail.

@Dicebot I think I understand why this is a problem know. All the build tools using this output can find it afterwards.

[mihails-strasuns]

I will create a regression test PR for your branch based on that snippet and should be good to merge after.

[mihails-strasuns]

burner#4

[burner]

merged burner#4 thanks

[mihails-strasuns]

Auto-merge toggled on

[mihails-strasuns]

fingers crossed :)

I suggest making NG announcement which both describes most recent state of the logger (new features added since last mass review) and encourages people to create pull requests to fixup any remaining flaws before 2.067 (to minimize breakage). Can also do it myself tomorrow.

[quickfur]

Whoa. std.logger finally merged?! Time to celebrate!!

[burner]

indeed

[MartinNowak]

I'm glad to see this in std.experimental.
Can we please get a small announcement in the changelog?

[burner]

@Dicebot If you don't mind.
http://forum.dlang.org/post/hmqlrknrjezovnvttxdj@forum.dlang.org should be a good start. thats pretty much what is new.

[joakim-noah]

One note: std.experimental.logger.core leaves behind a file someFile.log when the unittests are run. I'm not sure what that unit test even does, considering it doesn't contain an assert.

[burner]

I will have a look:

Update:
can you tell me which OS and in which folder you found the file

update":
#3364

[JackStouffer]

This package has been in std.experimental for six releases (3 major, 3 minor) and for seven months. What is the time table for moving it?

[mihails-strasuns]

My original plan was like this : author feels module has matured enough to not undergo any serious changes in future, calls for review manager, standard voting happens for inclusion into next release. I don't know how it is supposed to be handled now as I don't do any review manager duties anymore.

[burner]

I wish that logger had been moved to into "stable" already, but http://forum.dlang.org/post/mlhj3t$1bdi$1@digitalmars.com sort of blocked it.
IMO when logger has to wait for RCString, or RC in any other way than what we have right now in phobos it is going to be a long time.

[JackStouffer]

That's really a shame, it could be a year before a RC scheme is decided on let alone it's implementation being added to DMD.

[burner]

it could be a year

I wish I had your optimism. My prediction: RC build into the language will not happen, ever. There will be thread local COW container and the RefCounted will become better. But there will be no ref counted schema that is build into the compiler.