-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roadmap for 1.x #21
Comments
There's now various helper libraries which provide useful logging backend utilities
At some stage we should consolidate some common ideas from the tooling which has been emerging and do a design iteration to make the Currently I've changed jobs and I don't have a strong need for production grade logging which I admit has sapped my motivation to drive this development along! I'm definitely still interested though and would gladly collaborate to review pull requests here and elsewhere. |
Thank you for the great summary. I really like the basic logging functionality included in the stdlib. Also, I'm fully happy with the On the other way, what would be nice to have is the composability of loggers. Id like to combine a
lg= @logger InteractiveLogger(color = true, ...) ∘ ResultStorageLoger() ∘ ModuleFilterLogger(whitelist = [MyModule1, TheirModule4]) ∘ IterationFilterLogger([1:3] ,[end-3:end]) ∘ ProgressLogger()
whith_logger(lg) do
...
end So, yes, this definitely needs an architecture refactor (in a way fof maybe @oxinabox's LoggingExtras.jl ) and some amount of work to do. On the other hand, I think there is no need to touch the stdlib and all the desired composability is possible on the level of packages, with the enabling infrastructure in e.g. MicroLogging. |
This can definately be done with LoggingExtras.
PR to add that those would be welcomed. |
Hi,
I often use the Logging infrastructure that is part of 1.0 stdlib.
I'd like to ask what is the purpose of MicroLogging.jl in the context of Logging being part of stdlib?
Also, I'm using a private VisualLogger as a tool, see discussion in discourse.
The motivation is, if one writes nice "robust" reusable functionality, e.g. search for peak maxims in an array or image, where the user needs to fine-tune some input parameters that are used somewhere buried inside the function. To see why the algorithm is not satisfied with the provided inputs (e.g. thresholds, ...) the best way is to attach some array intermediates (or directly plots) to a @debug block and after the function is executed with VisualLogger the VisualLogger collects all the objects and those can be reviewed by the user.
Is it possible to host such a functionality in MicroLogging?
The text was updated successfully, but these errors were encountered: