Issue when use logger during progress bar

[Nhoutain]

I faced some issue when there is logging information during a progress bar (single or multi).

I use the https://github.com/rust-lang-nursery/log libreary with fern.

let style = ProgressStyle::default_spinner()        
        .tick_chars("⠁⠂⠄⡀⢀⠠⠐⠈ ")                                             
        .template("{prefix:.bold.dim} {spinner} {wide_msg}");                                                  
let pb = ProgressBar::new(1);                                                     
pb.set_style(style.clone());                                                                                  
pb.enable_steady_tick(100);                                                                                                

debug!("A random message);

pb.set_message(&format!("Message..."));                
pb.finish();

I understand that we can't have a nice progress bar if there is logging during the progress bar. But, either there is nothing show or there is the complete message show.

Someone has the same behavior? May be I do miss something :)

Thanks

[mitsuhiko]

This is hard to solve generically, but you can look at sentry-cli to see how we make progress bars work with loggers: https://github.com/getsentry/sentry-cli/blob/master/src/utils/logging.rs

[Nhoutain]

Thank you, I will check that!

[rubdos]

Isn't it an idea to optionally install a progress bar as logger, now that there's a println function? I would imagine that the main MultiProgress bar could take the role of env_logger, or somehow interact with it.

[djc]

I guess that might work. Do you want to submit a PR for something like that?

[rubdos]

I guess that might work. Do you want to submit a PR for something like that?

If at a point it becomes annoying enough for me, I might 😃, currently, I'm okay with now and then strange behaviour:

[ishitatsuyuki]

I think there should be a suspend function that clears the progress bar and allows functions like println! to be used as normal. The progress bar would be restored after the printing, by either using a resume function or making suspend take a closure and automatically resume when the closure finishes.

[djc]

@ishitatsuyuki that sounds sensible. Want to submit a PR?

[ishitatsuyuki]

@djc An implementation is almost done, but I'm not sure about which type we should expose the suspend() method on:

• ProgressBar and MultiProgressBar?
  • With an additional trait since it's common among the two types?
• ProgressDrawTarget?
• Do more refactoring on the types first? 😛

[djc]

Currently ProgressBar doesn't seem to have a way to expose its ProgressDrawTarget, so I guess attaching this to ProgressDrawTarget will make it potentially harder to use?

If you have a plan for refactoring the types in a way that you think makes more sense, I'm open to reviewing it, but that should probably be a separate PR from suspend() itself.

I don't think a trait makes a lot of sense here as I don't expect a MultiProgressBar and ProgressBar to be used interchangeably. Hopefully we could share most of the backing implementation in some other way.

[wkordalski]

Currently ProgressBar doesn't seem to have a way to expose its ProgressDrawTarget, so I guess attaching this to ProgressDrawTarget will make it potentially harder to use?

I think that attaching .suspend() to ProgressDrawTarget will make it easier to use.
I usually want to suspend all progress bars using specific target, because I want to write to the target (whatever target my progress bar writes to and if I have reference to any (progressbar)).

Edit: I wrongly assumed that I can have multiple independent progressbars to one target. What is more suspending a progressbar in MultiProgressBar does not work properly.

[djc]

I'm going to close this issue now that #333 has landed. Please open new issues for issues not covered by the current implementation (either use cases not covered or issues with what we've got so far).