manual flow control with ipypb about ipypb

[evfro]

Hi! Thanks for reporting. The problem is actually not related to ipypb. In your example pb variable is not initialized as it would be in a standard flow control (e.g., python for loop).
To mimic the expected behavior do iter on pb:

from ipypb import track

pb = iter(track(total=10))
pb.update()

[MartSlaaf]

from ipypb import track

pb = iter(track(total=10))
for i in range(5):
    pb.update()

Produces a progressbar, but doesn't fill it.

screenshot here: https://pasteboard.co/I3fmebh.png

[evfro]

That's because you never iterate over pb in your example. As with any Python iterator, you need to call next method in order to actually perform iteration step.

from ipypb import track
from time import sleep

pb = iter(track(total=10))
for i in range(5):
    next(pb)
    sleep(0.2) # delay to actually see updates

Note, that you don't have to call update method in that case as it's called within next. I have also added a short delay to actually see progress bar updating (there's a default update frequency limit to prevent DDOS'ing the screen)

[MartSlaaf]

Ok.
And so, how should it work with cycle=True?

This coded rises error:

from ipypb import track
from time import sleep

pb = iter(track(total=3, cycle=True))
for i in range(7):
    next(pb)
    sleep(0.2) # delay to actually see updates

[evfro]

The code above raises StopIteration error, which is expected and is a standard way for python iterators to indicate that the iterator sequence is exhausted.

cycle option is designed to handle nested loops in a specific way. Normally, after each external iteration the nested progressbar gets destroyed and recreated, which means that you'll have as many progressbars in the output as there are iterations in the external loop. With cycle enabled you can reuse the same progressbar without recreating it. See an example of usage here.

In your code, as you're taking the flow control under your responsibility with iter and next methods, in order to achieve the same functionality you would have to handle StopIteration manually, i.e. do smth like

pb = iter(track(total=3, cycle=True))
pb.update_interval = 0 # instead of doing sleep() before every next call
for i in range(7):
    try:
        next(pb)
    except StopIteration:
        pb = iter(pb)
        next(pb) # catch up with the external iteration
    sleep(0.2)
next(pb); # the last step is out of main flow control - have to do it manually

The last line is there because once the external iterator is exhausted, the internal one is never updated and is not aware that the last step was made. However, you probably don't want to do this whole thing anyway as it's quite inconvenient and makes code hard to read.

[MartSlaaf]

So I think, I've got it.
The simpliest way to use for i.e. model training and testing is to wrap loaders and epochs as follows.

from ipypb import track
from time import sleep

epochs_count = 3
train_samples_count = 10
test_samples_count = 7

epochs = track(range(epochs_count))
train_loader = track(range(train_samples_count), cycle=True)
test_loader = track(range(test_samples_count), cycle=True)


for e in epochs:
    for i in train_loader:
        
        # do some nerd things
        sleep(0.2)
        
    for i in test_loader:
        
        # do some nerd things
        sleep(0.2)

Surely, when you set your mind in a right way, it's obvious, but I think, it's better to add this to usage examples.

[evfro]

Yes, something like that. Note, that instead of track(range(x)) you can do irange(itr) (after importing it from ipypb).

Also, you generally don't need to sleep. Even if all your computations take less than 0.2 seconds, the progress bar will display the final state anyway.