[pacman-dev] [PATCH 1/2] pacman: fix alignment when download eta > 1h
When the download estimate is over an hour the format displayed changes from mm:ss to hh:mm:ss. This causes everything to be out of alignment die to the extra characters. So intead, when the estimate is over an our change to the format 4h33m. Do note that before pacman would display --:-- as the estimate if the download was >= 100 hours. Now this is displayed if the downlaod is => 10 hours. --- src/pacman/callback.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/pacman/callback.c b/src/pacman/callback.c index 7468ed7e..279338e7 100644 --- a/src/pacman/callback.c +++ b/src/pacman/callback.c @@ -865,8 +865,8 @@ static void draw_pacman_progress_bar(struct pacman_progress_bar *bar) } if(eta_h == 0) { printf("%02u:%02u", eta_m, eta_s); - } else if(eta_h < 100) { - printf("%02u:%02u:%02u", eta_h, eta_m, eta_s); + } else if(eta_h < 10) { + printf("%01uh%02um", eta_h, eta_m); } else { fputs("--:--", stdout); } -- 2.30.0
Sometimes when downloading packages the transfer rate drops in to the negative. Not only is this incorrect, but it messes with the allignment of the progress bars. So lets make sure it's always >= 0. --- This may not be the best fix as it does not address the root issue. But I have no idea what the root issue is so it's on somebody else to fix that. --- src/pacman/callback.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/pacman/callback.c b/src/pacman/callback.c index 279338e7..15317220 100644 --- a/src/pacman/callback.c +++ b/src/pacman/callback.c @@ -851,6 +851,10 @@ static void draw_pacman_progress_bar(struct pacman_progress_bar *bar) rate_human = humanize_size((off_t)bar->rate, '\0', -1, &rate_label); xfered_human = humanize_size(bar->sync_xfered, '\0', -1, &xfered_label); + if(rate_human < 0) { + rate_human = 0; + } + printf(" %ls%-*s ", wcfname, padwid, ""); /* We will show 1.62 MiB/s, 11.6 MiB/s, but 116 KiB/s and 1116 KiB/s */ if(rate_human < 9.995) { -- 2.30.0
On 01/16/21 at 04:32pm, morganamilo wrote:
Sometimes when downloading packages the transfer rate drops in to the negative. Not only is this incorrect, but it messes with the allignment of the progress bars. So lets make sure it's always >= 0.
---
This may not be the best fix as it does not address the root issue. But I have no idea what the root issue is so it's on somebody else to fix that.
-1. The issue is that when alpm falls over to a new mirror the download counter restarts. pacman goes from seeing X bytes downloaded to 0 and thinks -X bytes were just downloaded. I'm not sure how alpm should be presenting that event to frontends, but I would say clamping to 0 is just masking problems.
On 17/1/21 5:34 am, Andrew Gregory wrote:
On 01/16/21 at 04:32pm, morganamilo wrote:
Sometimes when downloading packages the transfer rate drops in to the negative. Not only is this incorrect, but it messes with the allignment of the progress bars. So lets make sure it's always >= 0.
---
This may not be the best fix as it does not address the root issue. But I have no idea what the root issue is so it's on somebody else to fix that.
-1. The issue is that when alpm falls over to a new mirror the download counter restarts. pacman goes from seeing X bytes downloaded to 0 and thinks -X bytes were just downloaded. I'm not sure how alpm should be presenting that event to frontends, but I would say clamping to 0 is just masking problems.
Is this a recent regression with the parallel downloads? This has been fixed in the past - see commit e83e868a77865d42a33076605f9a90a165f7c93a A
On 01/17/21 at 08:50am, Allan McRae wrote:
On 17/1/21 5:34 am, Andrew Gregory wrote:
On 01/16/21 at 04:32pm, morganamilo wrote:
Sometimes when downloading packages the transfer rate drops in to the negative. Not only is this incorrect, but it messes with the allignment of the progress bars. So lets make sure it's always >= 0.
---
This may not be the best fix as it does not address the root issue. But I have no idea what the root issue is so it's on somebody else to fix that.
-1. The issue is that when alpm falls over to a new mirror the download counter restarts. pacman goes from seeing X bytes downloaded to 0 and thinks -X bytes were just downloaded. I'm not sure how alpm should be presenting that event to frontends, but I would say clamping to 0 is just masking problems.
Is this a recent regression with the parallel downloads? This has been fixed in the past - see commit e83e868a77865d42a33076605f9a90a165f7c93a
Yup.
On 16/01/2021 22:50, Allan McRae wrote:
On 17/1/21 5:34 am, Andrew Gregory wrote:
On 01/16/21 at 04:32pm, morganamilo wrote:
Sometimes when downloading packages the transfer rate drops in to the negative. Not only is this incorrect, but it messes with the allignment of the progress bars. So lets make sure it's always >= 0.
---
This may not be the best fix as it does not address the root issue. But I have no idea what the root issue is so it's on somebody else to fix that.
-1. The issue is that when alpm falls over to a new mirror the download counter restarts. pacman goes from seeing X bytes downloaded to 0 and thinks -X bytes were just downloaded. I'm not sure how alpm should be presenting that event to frontends, but I would say clamping to 0 is just masking problems.
Is this a recent regression with the parallel downloads? This has been fixed in the past - see commit e83e868a77865d42a33076605f9a90a165f7c93a
A
Thanks for showing me the commit. Made a proper fix.
On 17/1/21 2:32 am, morganamilo wrote:
When the download estimate is over an hour the format displayed changes from mm:ss to hh:mm:ss. This causes everything to be out of alignment die to the extra characters.
So intead, when the estimate is over an our change to the format 4h33m.
Do note that before pacman would display --:-- as the estimate if the download was >= 100 hours. Now this is displayed if the downlaod is => 10 hours. ---
How about, we just display the time if it is less than 100 minutes? On any reasonable connection (even by Australian standards), the vast majority of packages should download within that timeframe. And times are not particularly accurate beyond that.
src/pacman/callback.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/pacman/callback.c b/src/pacman/callback.c index 7468ed7e..279338e7 100644 --- a/src/pacman/callback.c +++ b/src/pacman/callback.c @@ -865,8 +865,8 @@ static void draw_pacman_progress_bar(struct pacman_progress_bar *bar) } if(eta_h == 0) { printf("%02u:%02u", eta_m, eta_s); - } else if(eta_h < 100) { - printf("%02u:%02u:%02u", eta_h, eta_m, eta_s); + } else if(eta_h < 10) { + printf("%01uh%02um", eta_h, eta_m); } else { fputs("--:--", stdout); }
On 28/01/2021 03:09, Allan McRae wrote:
On 17/1/21 2:32 am, morganamilo wrote:
When the download estimate is over an hour the format displayed changes from mm:ss to hh:mm:ss. This causes everything to be out of alignment die to the extra characters.
So intead, when the estimate is over an our change to the format 4h33m.
Do note that before pacman would display --:-- as the estimate if the download was >= 100 hours. Now this is displayed if the downlaod is => 10 hours. ---
How about, we just display the time if it is less than 100 minutes? On any reasonable connection (even by Australian standards), the vast majority of packages should download within that timeframe. And times are not particularly accurate beyond that.
On my awful connection times going above an hour is common place. I see it multiple times a week. However it never actually takes an hour to download. Just my connection speed bounces up and down. So I guess you're right when you say it's not accurate. Your call.
src/pacman/callback.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/pacman/callback.c b/src/pacman/callback.c index 7468ed7e..279338e7 100644 --- a/src/pacman/callback.c +++ b/src/pacman/callback.c @@ -865,8 +865,8 @@ static void draw_pacman_progress_bar(struct pacman_progress_bar *bar) } if(eta_h == 0) { printf("%02u:%02u", eta_m, eta_s); - } else if(eta_h < 100) { - printf("%02u:%02u:%02u", eta_h, eta_m, eta_s); + } else if(eta_h < 10) { + printf("%01uh%02um", eta_h, eta_m); } else { fputs("--:--", stdout); }
participants (4)
-
Allan McRae
-
Andrew Gregory
-
Morgan Adamiec
-
morganamilo