Closed matthiasbeyer closed 3 years ago
Do you perhaps print anything to console? It can have this kind of effect and in order for this use to work properly you need to use ProgressBar::println
If I would print something, wouldn't it be visible here?
$ rg println
does report only exactly one println!()
in the codebase and that one is visible a few more lines above the screenshot. As logging is disabled in this screenshot, no log::
macro calls should print anything... so I guess not?
See an example using println during MultiProgress::join
. The behavior isn't deterministic and leaves phantom progress bars. However it sounds like this shouldn't be the culprit.
The progress bars are printed twice only once, right? Can you share some code?
As said, the println!()
happens before the bars are even instantiated, so that's not the issue.
Unfortunately, I cannot share the code yet. The software might get opensourced in January, though.
The same thing, by the way, happens for spinners.
Maybe this is mis-use (I still doubt it)... if it is, maybe the API should be fixed to prevent misuse in the future?
Okay, I finally figured it out (by accident).
The issue was that I called set_message()
before I added the bar to the MultiProgress
object. This is clearly my fault, but I also blame the API for allowing such a thing.
My issue is resolved, although I would love to see improvements API-wise in indicatif to disallow such misuse.
Not sure why this is happening or how to debug why. Maybe you have some pointers?
The second set of bars is rendered as soon as there is any progress on them.