MultifilesLogger.jl#1
Conversation
…ilesLogger'. Every log file now has its own 'append' attribute.
… to the IO of a parent module
Remove some comments
Seelengrab
left a comment
Seelengrab
left a comment
There was a problem hiding this comment.
I like the idea of distinguishing between modules when logging, but I think it would be a good idea to incorporate the ideas of logging ranges from the FileLogger and generic IOLogger as well into this. That way different modules could be logged with different priorities and you can easily specify different ranges of log levels for different modules, with no logging done being the default.
| Dict{Module, Tuple{IO, LogLevel}}(), | ||
| Dict{Any, Int}(), | ||
| flush); | ||
| createIOs!(x); |
There was a problem hiding this comment.
Maybe do this lazily in handle_message on a per module basis in order to prevent opening too many files at creation of the logger even though they may not be needed at all.
There was a problem hiding this comment.
I know it's not consistent with the rest of the package but I find it more user friendly to have the files initialized at the instantiation of the logger. Like this we can check that everything is fine (eg.: check that files are created, check that files are emptied for IO with 'append' set to false).
- Move the 'flush' property from 'MultifilesLogger' to FileDefForMultifilesLogger - Do not throw an error if we cannot find an IO for a given module
2 participants
MultifilesLoggerallows to have several log files.Every log file is associated to a vector of Tuple{Module, LogLevel} using the struct
FileDefForMultifilesLogger.If a module is not associated to an IO,
getIOLevelTuple!()will try to associate the module with the IO of a parent module.NOTE:
test/runtests-MultifilesLogger.jlwould require some properly written tests. My first attempt to mimic the test sets of FileLogger has failed (the log files are empty, I don't understand why).