Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add named loggers with individually controlled log levels. #1481
Adds named loggers with individually controlled log levels.
There are currently several different ways to control which log messages are generated and printed in the log files
These can be configured/toggled from the following locations.
This PR creates a consistent system where it is easy to create/remove named loggers for specific sections of code that can be configured from the command-line, or OptionsDB or the OptionWnd at runtime.
The default logger works the same as before.
Create a new named logger.
Create a log message.
ErrorLogger(name_of_logger) << "any streamable output, only computed " << "at the error threshold or greater " << "for the 'name_of_logger' logger."; WarnLogger(name_of_logger) << "streamable output"; InfoLogger(name_of_logger) << "streamable output"; DebugLogger(name_of_logger) << "streamable output"; TraceLogger(name_of_logger) << "streamable output";
(Optionallly) Set the log threshold in config.xml/persistent_config.xml
<logging> <sources> <name_of_logger>warn</name_of_logger> </sources> </logging>
(Optionally) Set the log threshold from the OptionsWnd with the Other/Logging/Log threshold for individual sources/name_of_logger drop down list.
(Optionally) Override each executables defaut logger to specific log levels in config.xml/persistent_config.xml.
<logging> <execs> <ai>warn</ai> <client>debug</client> <server>trace</server> </execs> </logging>
(Optionally) Override each executables default logger to specific log levels from the OptionsWnd with the Other/Logging/Log threshold for default logger for process/<ai/client/server> drop down list.
(Optionally) Override all individual loggers of all executables log levels with the command-line/OptionsDB option
Changes in this PR.
The changes are in three steps: refactor
It now compiles on OSX and Windows, as well as the original linux.
It needs testing on those OSs, because OSX and particularly Windows required additional coding.
Testing is as follows:
Thanks in advance for your testing time.
This seems overly complicated to me... In particular, are 5 log levels really necessary?
I find the lambda function syntax for controlling whether to evaluate stuff to log particularly clunky / awkward. A simple if block seems preferable. Can this be easily integrated with the named loggers, perhaps to poll whether a particular named logger has a particular log level?
The pull request is another huge one, which is difficult to review. Can you break it into smaller chunks?
I will start start breaking it into smaller chunks.
I think that at least 4 levels are necessary.
We should have 2 levels of problem log messages, error and warning. Errors are a notice to the devs that something should be fixed in the code. (Ideally) there should be no errors in released code. Warnings are a notice to the user that something is in a downgraded state, like a missing sound system.
We need at least 2 levels of progress/state log messages for developers, debug and trace. This distinction is already apparent in the existing code with
No it can't be done easily. It would involve replicating parts of the
However, most of the lamda functions are in the trace logging of the effects code. Most are only preventing unnecessary iteration over some set, when there will be no log generated. They can be removed.
Briefly checked this PR earlier, really like some of the changes.
If nothing else changes, please set the default severity of
No config option for
Did you check if this is actually true?
Further remarks after the PR was shrinked to a consumable size.
@adrianbroher I believe the wording there suggests that
The first doc mention I see confirming this is the note at http://www.boost.org/doc/libs/1_59_0/libs/log/doc/html/log/tutorial/trivial_filtering.html
In practice, this diff(print to console when sound enabled) also appears to exhibit the functionality described by LGM-Doyle.
Thanks everyone for the comments. I'm working on the fixes and the split.
@dbenage-cx I changed the effects priority to
I'm working on the
I now plan to do some "playtesting" of the release candidate.
This was referenced
Apr 24, 2017
I've now broken this up into multiple parts.
This PR is now the last part.
This PR replaces the various other verbose or trace logging methods with a named
It follows the core implementation #1529.