Closed appi147 closed 3 years ago
Hey, thank you man!
I didn't quite understand what the problem is. The code seems ok, and you are updating bar()
in all issues.
You could even make it simpler:
with alive_bar(title="Fetching existing Github issues: ") as bar:
while True:
response = SESSION.get(url, params={'per_page': 100})
if response.status_code == 200:
for issue in response.json():
bar()
if not 'next' in response.links:
break
url = response.links['next']['url']
So the thing is, the progress bar, does not update like 1,2,3,4,etc.
Since, per page 100 issues are there, even though I call bar() 100 times, progress bar updates at 100 intervals.
Let's say there are 372 issues, so the progress bar will update like 100 -
200 - > 300 - > 372.
On Wed, 13 Jan 2021, 08:03 Rogério Sampaio de Almeida, < notifications@github.com> wrote:
Hey, thank you man!
I didn't quite understand what the problem is. The code seems ok, and you are updating bar() in all issues. You could even make it simpler:
with alive_bar(title="Fetching existing Github issues: ") as bar: while True: response = SESSION.get(url, params={'per_page': 100}) if response.status_code == 200: for issue in response.json(): bar() if not 'next' in response.links: break url = response.links['next']['url']
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rsalmei/alive-progress/issues/74#issuecomment-759163665, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHYBERU5IV4CIKNRUZN7S5TSZUBADANCNFSM4V7MOQ4A .
Since, per page 100 issues are there, even though I call bar() 100 times, progress bar updates at 100 intervals.
I still can't understand this. If you call bar()
100 times, it will update 100 times, not once every 100.
What do you want to achieve? If you want to update once per page, you can move bar()
out of the for loop.
If you do want to update it once per issue, it is already ok.
Humm, maybe I understand what you said:
Let's say there are 372 issues, so the progress bar will update like 100 - 200 - > 300 - > 372.
You mean the bar goes forward very fast until 100, then stops for awhile and again speeds to 200, etc Is that it? If it is, I think it is very right, since it is what your program is actually doing. What other behavior would you like it to have?
Progress bar doesn't update with step 1. It updates with step value 100.
I will try to capture the output.
On Wed, 13 Jan 2021, 22:41 Rogério Sampaio de Almeida, < notifications@github.com> wrote:
Since, per page 100 issues are there, even though I call bar() 100 times, progress bar updates at 100 intervals.
I still can't understand this. If you call bar() 100 times, it will update 100 times, not once every 100.
What do you want to achieve? If you want to update once per page, you can move bar() out of the for loop. If you do want to update it once per issue, it is already ok.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rsalmei/alive-progress/issues/74#issuecomment-759591191, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHYBERVTL7LFZCGH6YFYEF3SZXH2XANCNFSM4V7MOQ4A .
Wait...do you mean that the progress bar doesn't update with step one, or you don't want it to update withs tep 1? There's a large difference.
Sorry, looks like I missed one of the comments as I was on mail.
with alive_bar as bar:
while True:
for i in range(100):
bar()
if condition:
break
Is it intended behaviour of progress bar to update at 100 steps?
If so, is it any way so that progress bar updates at every step?
Guys, don't mind my above comments. I am stupid :).
No problem man.
A closed loop like that, with only bar()
inside it, runs so wildly fast (in a few microseconds) that the bar doesn't have any time to update itself. And this is a great feature of alive-progress
!! It is not "directly connected", there's a calibration curve that enables you to update MILLIONS of times per second, and the bar updates itself in a fraction of that, at most 60 frames per second. More than that the human eye do not perceive any difference, and is just wasted CPU cycles.
In your case you should have some work being done before calling bar()
👍
Yep. In actual code, there were lines, but I was amazed, how fast all 100 were processed.
On Thu, 14 Jan 2021, 22:16 Rogério Sampaio de Almeida, < notifications@github.com> wrote:
No problem man. A closed loop like that, with only bar() inside it, runs so wildly fast (in a few microseconds) that the bar doesn't have any time to update itself. And this is a great feature of alive-progress!! It is not "directly connected", there's a calibration curve that enables you to update MILLIONS of times per second, and the bar updates itself in a fraction of that, at most 60 frames per second. More than that the human eye do not perceive any difference, and is just wasted CPU cycles. In your case you should have some work being done before calling bar() 👍
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/rsalmei/alive-progress/issues/74#issuecomment-760318831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHYBERUUV2PBYTXAG3NLO2TSZ4NWVANCNFSM4V7MOQ4A .
In this problem of yours, you could create a deque
, and let one thread fetching the issues, while the main thread receives and processes them. Only here in the main thread you would instantiate alive_bar
, and would not have those "skips".
You could even use a ThreadPool and fetch all pages in parallel, and receive the issues via the same deque
, it would be much better.
Great work.
I am facing some issue on nested loops.
In this sample piece of code, bar updates after 100 items. If I have 250 items, it will update 100 > 200 > 250