Feedback/Suggestions for std.log

[Jose Armando Garcia]

Hi Gary.

You should take a look at the proposed logging module for phobos at
http://jsancio.github.com/phobos/phobos/std_log.html and
https://github.com/jsancio/phobos/blob/master/std/log.d. Please
comment.

I have some comments below.

Thanks for your input.

> - Must be scalable with respect to project size
> -- Feature: Allow custom log destinations specified at compile or run-time,
> and log level options specified at logger instantiation (compile time) or at
> run-time.
This is not actually a requirement but more of an implementation
suggest. What are you trying to achieve? With std.log you can enable
and disable verbose logging in a module at run time with --vmodule.
You can also disable logging at a specific severity for the entire
process at compile time and run time.

> -- Feature: Allow loggers to exist in a hierarchy, in which properties of
> parent loggers are shared with children.
Again, this is a implementation detail and not a requirement. What do
you plan to do with a hierarchy? Look at vlog, it is much more
flexible than a tree of loggers.

> --- Our team of 18 developers must make judgments about what to log and
> when. Depending on the diagnostic activity, it is necessary to
> enable/disable logging in specific domains of the application. The ability
> to shut off logging in certain parts of the program at run time is paramount
> to success in debugging certain issues, from our experiences.
You can use verbose logging and the command line flag --vmodule.

> --- The hierarchy helps in being able to shut off a large branch of loggers
> by specifying the level for just one ancestor. Also the hierarchy format (at
> least in our case) maps well to the organization of objects across our
> domains.
>From my experience you never really know how to organize your loggers
at dev time. You realize you want to turn something only at debug time
which in many cases it is too late (E.g. you already shipped a binary
to QA or customer). std.log gives you the ability to enable and
disable logging based on glob match on the source file.

>
> - Must be performant
>
> - Log calls and interaction must be concise, readable code
> -- Feature: Minimal setup code, minimal code at log call site
> --- Our team has felt the pain of supporting and troubleshooting our
> products at customer sites, with irate customers present. Each illuminative
> log statement is worth it's weight in gold, but we're also cognizant of
> maintainability of software, and code with verbose comments becomes
> difficult to read.
> --- I opine: the current interface for std.log currently achieves good
> readability! Awesome!
> -- Feature: Allow code/logic to be run inside the conditional block of a log
> call.
> --- An example of our need for this is the need to print specific data from
> each member of a list of objects. Rather than incur log call overhead on
> each iteration over a list (much less not being able to compile away that
> logic), the most efficient solution seems to be allowing logic in the log
> conditional block.
> --- Of course, somebody somewhere will misuse this and put "business" logic
> in there, and compile out a small but necessary tidbit which made their
> program function.
> --- From my very rough understanding after reading the Lazy Evaluation
> article on "d-programming-language.org", this can be possible with the
> current std.log interface:
>                Sample pseudo-code:
>                logInfo({
>                auto msg = "Video modes found: ";
>                foreach( mode, videoModes )
>                {
>                msg ~= to!string( mode.width ) ~ "x" ~ to!string( mode.height
> ) ~ ";";
>                }
>                return msg
>                });
Yes! but your example has a small bug...

> --- log4cxx simply allows a query to the logger at run-time to find out the
> current log level.
This currently not exposed but it is trivial to add support for it...

>
> I can provide success stories (well, success in finding and debugging
> issues) from having a few of these features in our logging library, but that
> could be boring so I'll hold back (available on request).
>
> 3. Suggestions
> Well, the suggestions for std.log are basically the features described above
> :-) . It'd be an injustice to express a desire to recreate log4cxx/log4j in
> D, but certain features which log4cxx provides greatly enhance development
> on large teams.
>
> I haven't thought through it, but I get the feeling D might accommodate
> creating the logger hierarchy at compile time, or rather avoid string
> (logger name) computations at run-time (log4cxx does all the string
> manipulation at run-time).
We can talk about how to improve performance at a later point but it
should be possible to cache the results of vmodule filtering.
>
> I hopefully have made a case for including these features. I believe they'd
> be helpful to larger teams and teams supporting somewhat complex commercial
> products.
>
> I'm aware that it's very easy to ask for things when I'm not the one working
> to help provide them. Since I'd like to see this and other growth in the D
> language, I'll offer my help however I can.
>
> Thanks,
> Gary
>