mrlazy1708 / tqdm Goto Github PK

tqdm is not supported in Windows due to using termion as a dependency. crossterm is the recommended alternative with has a similar API.

error[E0015]: cannot call non-const fn `std::sync::Mutex::<Vec<std::sync::Arc<std::sync::Mutex<Info>>>>::new` in statics
   --> /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/tqdm-0.4.3/src/lib.rs:306:45
    |
306 | static TQDM: Mutex<Vec<Arc<Mutex<Info>>>> = Mutex::new(Vec::new());
    |                                             ^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: calls in statics are limited to constant functions, tuple structs and tuple variants

For more information about this error, try `rustc --explain E0015`.

This crate does not compile due to the error above.

It is a common pattern in Python to wrap the iterator in a for loop with tqdm like so:

for _ in tqdm(iter):
    ...

This Rust version of tqdm advances the progress bar when calling .next(), which makes sense in principle.

However, say the iterator is trivially fast (like a Vec) and the slow computation is within the for loop, then the progress bar will tick from 0 to 1 almost immediately, and take a lot longer to go from 1 to 2 and so on. This causes the ETA to be vastly underestimated since it is artificially reduced by that first false iteration.

The original tqdm seems to somehow avoid this, it stays at zero until the first for loop has completed. Is there a clean way to address this flaw in such a common pattern?

Leave an example of progress bar and characters it required

Example

#######7
0123456789#

Currently, if I want to print some information within the loop, there will be something like:

for i in tqdm(x.iter()) {
  // do something
  println!("anything");
}

However, this println will interfere with the progress bar, and it's like:

and a desirable output will be like:

Therefore, print the message through a tqdm.write method might be a good idea.