Skip to content
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

Edge case: printing with MultiProgress after all bars are finished #369

Closed
KevinMGranger opened this issue Feb 10, 2022 · 2 comments
Closed

Comments

@KevinMGranger
Copy link

The Issue

When using a MultiProgress, you need to use a bar's println to avoid the terminal getting messy.

However, if all bars finish, you can't println, even though you could if using a solo ProgressBar.

Possible Solutions

  1. Add a println to the MultiProgress itself.
  2. Add some other type of join to MultiProgress, which continues even after all bars are done.
  3. Add another method to control the pump inside MultiProgress::join, a user can query if it's already done, and switch to regular println!. Something like MultiProgress::single_event(), which returns if the last event was final.
  4. Add another method that lets other threads wait for MultiProgress to finish, which could then switch over to regular println!.
  5. Some combination of the above.

Out of all of these, 1 seems the simplest, and I'd be happy to work on a PR if y'all think it's an appropriate solution.

Background

I'm working on two adapters for indicatif:

One to work in an async runtime that dispatches messages to another thread. Without a way to query if MultiProgress is done, println calls could be dropped, or I'd have to wrap all print calls in another mutex over MultiProgress.

That's complicated. And unless I haven't seen the solution, it's impossible to do without race conditions.

The other adapter will let you use indicatif's bars as a Writer for tracing_subscriber. It more or less has the same issue.

@KevinMGranger
Copy link
Author

Somehow I totally missed #351. I think keeping this open might make sense if there's discussion to be had for the other solutions I mentioned.

@KevinMGranger
Copy link
Author

I didn't see the removal of join in main! This is all handled, or at least will be once #351 is merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant