-
Notifications
You must be signed in to change notification settings - Fork 8
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
New API: ProgressLogging.implementedby(logger) #24
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #24 +/- ##
==========================================
+ Coverage 71.77% 71.95% +0.17%
==========================================
Files 1 1
Lines 163 164 +1
==========================================
+ Hits 117 118 +1
Misses 46 46
Continue to review full report at Codecov.
|
to be compatible with asprogress
This looks reasonable to me if it solves the As I said over at |
Thanks for having a look at it!
(Edit: Never mind. This was not what SciML/DiffEqBase.jl#450 was about.) |
How about this? JuliaLang/julia#33960 (comment) |
Good suggestion, I think something like that is the right way to go. |
This is useful for progress log record providers to check if users have progress monitors. Ref: SciML/DiffEqBase.jl#450 (comment)
Originally I called it
enabled_for
. But I thinkimplementedby
makes more sense. For example, the user may turn off progress logging capability for a particular instance of a custom logger type. In this case, the nameenabled_for
implies that this function should returnfalse
. But if this function is used by log record providers, they may take action incompatible to the user's intent (e.g., warning message telling the user that the current logger does not support progress bar).