per_n_sec proof of concept

[1Dragoon]

Proof of concept for how smoothing can be done. Note I'm not a professional software developer, just a hobbyist with no formal training, so please excuse any kludgy things I might have done. The code isn't meant to be optimized yet, just readable, perhaps a little verbose even, mainly to get my ideas across. There are a few things we could do like using another ring buffer instead of VecDeque.

Example usage:

    pb.enable_steady_tick(Duration::from_millis(100));
    pb.set_style(
        ProgressStyle::with_template(
                "{spinner:.green} [{elapsed_precise}] [{bar:50.cyan/blue}] {bytes}/{total_bytes} {my_bytes_sec} ({my_eta}) [{wide_msg:>}]",
            ).expect("Bad programmer! Bad!")
            .progress_chars("#>-").with_key("my_eta", |s| 
            match (s.pos(), s.len(), s.per_n_sec(3)){
               (pos,len, pps) if (pps.trunc() >= 1.0 && pos >= 1) => format!("{:#}", HumanDuration( Duration::from_secs_f64((len.unwrap_or_default() as f64-pos as f64) / pps.trunc()))),
               _ => "-".to_string()
           }).with_key("my_bytes_sec", |s| 
           match s.per_n_sec(1) {
              pps if (pps.trunc() <= 0.0) => "-".to_string(),
              pps => format_args!("{}/s", BinaryBytes(pps.trunc() as _)).to_string(),
          })
    );

[djc]

I don't think we really want to go here. The more I think about it, I think we want to expose API so that people can implement good custom formatters, and include one simple default set of ETA/per second formatters.

[1Dragoon]

That sounds like a good idea because this adds significant overhead, and I can't really think of any decent ways to mitigate it other than making the VecDeque an Option<Box<T>>, while avoiding the additional per-tick overhead for recording. Any other more complex formatters will probably run into the same problem, and most people probably don't need all of that.

How would something like an optional closure to the record function sound?

[1Dragoon]

By the way, on the matter of those failing test workflows on github, is there a minimum rust version that you want to target, or does the latest rustc always suffice? I don't have an Ubuntu box set up to test against (only Kali linux) but I suspect that the compile error is just because it uses an older rustc.

[djc]

Yes, CI explicitly tests for compatibility with Rust 1.53. If you have a particular feature that you'd like to use that's newer we can talk about it, but I'd like to at least keep 6 months of compatibility (about 4 releases) and even then IMO it's a trade-off in how much extra complexity working around it requires.