Request - sleep/trace/stopped/disk-sleep indicator

[ThomasByr]

Hi !
First of all, thanks for the library, it is awesome and i use it everywhere.
I even found myself using it in some company where we have large servers with a ton going on. Which brings me to my suggestion.

On some potato configurations, memory/IO intensive programs are subject to temporary halts.
We can actually see them in htop with the status being S, t or D (blocking IO) (R and Z are running fine I guess).
I do not how how easy or ridulously hard it is to capture the state of the program (similar to ps r) in alive-progress to display a pause icon instead of the running spinner when applicable.

Anyway, a huge thank you for this amazing library <3

[rsalmei]

Hi @ThomasByr!

You're welcome! I appreciate the kind words 😄

It’s not that simple, and I’d still be concerned about a significant slowdown. Adding a system call to a spinner could cause it to run less smoothly and hinder its ability to achieve the ceiling of 60 frames per second.

In fact, the spinner I designed should visually indicate whether the process is fast or slow. The only limitation I’ve imposed is that its lower frame rate is 4 per second, so it wouldn’t ever completely stall. If it does reach that bottom for you and you wanted a complete stall, I could relax this minimum or even make it configurable. Do you think that would resolve your issue?

[ThomasByr]

Hi!

Thank you for your answer. A configurable minimum could be quite nice - and in fact would be better than my quick hack.

When running jobs in parallel I usually update the alive-progress bar from the parent thread ; which allows to make use the the pause mecanism or change the bar text if the throughput is lower than expected.
Allowing the spinner to completely stall will be a very nice solution for me at least.

[rsalmei]

Hey, it’s done! Unfortunately, I’m not sure if it will work for you anymore.

There are two main concerns I have now that were raised after the implementation:

1. The rate, which represents the throughput of items consumed, is an average since the beginning. This means that if you’ve already consumed a lot of items quickly, the average rate may take a long time to decrease until min_fps is reached --> the spinner will not stop easily.

2. The alive_progress refresh affects the entire line, including the spinner, monitor, elapsed time, rate, and ETA. This means that when the spinner is frozen, the information updates are also frozen. The current hard-coded minimum (which is actually 2, not 4) ensures that these important data are always displayed on the screen, and the spinner smoothly accompanies these refreshes, for better or worse. --> the spinner freezes the whole bar with it.

I’m currently studying what I can do to address these issues. I’ve tried creating another thread and sending additional ticks that would only update the information, not the spinner. However, this didn’t quite work because the wait time for refreshes is based on the FPS curve. When the wait time exceeds this new no spinner refresh, the next updates likely to be triggered are no spinner too, resulting in a stuck spinner. It won’t start running again unless you increase the rate significantly. 😞

[ThomasByr]

Hi!

Wow that is quite nice!

I saw a rate indicator somewhere that used a Moving average instead of a global one.
That might be yet another config idea, I don't know if it would adress point 2 though :(