-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
[feature request] Multiple active progress bars #51
Comments
Hi, Yeah this is something that is going to happen for sure. It will look like's Having nested calls to So the code will look something like: pbar = ProgressBar()
outer = addtask(pbar, "Total"; N=10)
for i in 1:10
inner = addtask(pbar, "inner"; N=3)
for j in 1:3
update(inner)
end
update(outer)
end which is a bit cumbersome. Though perhaps there's a way to have |
Btw I'm currently working on making the code faster and cleaning up the codebase so the next release won't have any new feature. The one after that will include this |
Ah, so exciting! Thank you for working on this! |
Please don't make a Term.jl-only interface when one already exists and is built into Julia itself. The logging infrastructure specifies how progress information can be given. This is then be used by all downstream packages, such as VS Code, https://github.com/JuliaLogging/ProgressLogging.jl, https://github.com/JuliaLogging/TerminalLoggers.jl, Juno, etc. If you just accept that format, then progress bars from packages work. If you don't, then packages won't support it. |
Hi Chris, Could you elaborate?
Does this relate to logging progress info, or is it about printing this info to terminal? I haven't looked yet at how Term's packages look like in a log file, but I'm guessing they'll result in a bunch of repeated lines, I'm happy to try to avoid that if possible. What do they look like in e.g. ProgressLogging.jl?
Maybe I don't understand what 'interface' you're referring to above, but yes a package that wanted to use Term's progress bars would have to be modified to do so. Other than that I don't see what would prevent that from working. I haven't used ProgerssLogging or TerminalLoggers so I'm not sure what you're referring to exactly. If it's about logging progress information I'm happy to try and conform, but could you give me more details about how to do that/what to look for? If it is about the progress API itself (as pertains progress information to the terminal), then I think I'll stick with what I'm working on. I need something capable of handling:
As far as I can tell neither ProgressBars.jl nor ProgressMeter.jl can handle If there's a progress bar framework capable of handling all of this and more I can consider adapt Term to it. Otherwise I won't sacrifice functionality for it. Downstream packages would have to either adapt to it or not use Term for progress information (there's tons of other useful stuff fortunately). |
It's just how the info is handled, not how it's printed. For example, OrdinaryDiffEq.jl can do this: which emits logging information for a progress bar named OrdinaryDiffEq (i.e. for multiple concurrent progress bars) without having a dependency on any of the progress monitoring packages. That is then picked up in Juno, VS Code, ProgressLogging.jl, etc. |
@ChrisRackauckas I've moved this to a discussion because it's offtopic from the original issue. See here: #67 |
First and foremost, what a wonderful package and accompanying documentation! I really like the simplicity of using the
transient
property for a ProgressBar and was surprised when it did not accommodate a nested loop, like so:Yielding something like
This seems like a very natural API for having a top-level progressbar that tracks the outermost loop and an inner-level progressbar that tracks the progress of the inner loop, clearing itself when the inner loop exhausts itself. The documentation describes why STDOUT is withheld until the end, so I was wondering if this will also be prohibitive for such an implementation.
The text was updated successfully, but these errors were encountered: