Status of Progress Bar

[Stephen McDowell]

Hello,

I was searching around to see if I should add a new issue on GitHub related to the progress bar. Searching the mailing lists, the questions are mostly about “how do I get it working” stuff, but from the CONTRIBUTING guide I found the following TODO 22.7: remove progress meter from lib curl: https://curl.haxx.se/docs/todo.html#remove_progress_meter_from_libcu <https://curl.haxx.se/docs/todo.html#remove_progress_meter_from_libcu>

applications can and should do their own progress meters using the progress callback

Is this referring to `curl` the command-line tool, or is this referring to the developer interface?

If the intent is to remove the progress bar from `curl` the command line tool, then no issue is warranted. If the progress bar is going to be kept in the `curl` command-line tool, then I will raise the issue explaining one way to reproduce the problem. Short version is that it sometimes skips the carriage return, which on Travis CI can lead to killed jobs.

Thank you for any insight :)

-Stephen

[Daniel Stenberg]

Post by Stephen McDowell
from the CONTRIBUTING guide I
https://curl.haxx.se/docs/todo.html#remove_progress_meter_from_libcu

Note that this is in the section of things to consider doing at "Next major
release". We can't do this without bumping the soname etc.

Post by Stephen McDowell

applications can and should do their own progress meters using the progress callback

Is this referring to `curl` the command-line tool, or is this referring to
the developer interface?

The "internal progress meter" is the progress meter that curl shows (by
default) that is output by libcurl.

Post by Stephen McDowell
If the intent is to remove the progress bar from `curl` the command line
tool, then no issue is warranted.

Again: that's idea is for next major version. We're talking several years into
the future and that's just an idea, nothing that's written in stone.

But also, removing the internal progress meter would basically mean that we'd
re-implement it in the curl tool code since I think curl needs a progress
meter.

Post by Stephen McDowell
If the progress bar is going to be kept in the `curl` command-line tool,
then I will raise the issue explaining one way to reproduce the problem.
Short version is that it sometimes skips the carriage return, which on
Travis CI can lead to killed jobs.

Please do.

Just keep in mind that if you use "native" curl on travis, you probably use a
rather outdated version that very well might not work like that anymore. We
rarely have bandwidth enough to investigate problems on old versions if they
don't reproduce in the latest.

[Stephen McDowell]

Hi Daniel,

Thank you for the response and explaining the implications of the TODO document :)

Yes, the Travis cURL is probably very very old. I will spend a few more days information gathering on this in a public repo so the build logs can be viewable for others, and install the newest cURL.

We can reproduce the effect locally by using a small terminal size (e.g., < 40 chars wide), but the Travis specific failure is likely caused by something else. It’s an unfortunate heisenbug (doesn’t happen always, just frequently), so I will try my best to see if I can find a reliable way to reproduce it.

-Stephen

Post by Stephen McDowell
from the CONTRIBUTING guide I found the following TODO 22.7: remove progress meter from lib curl: https://curl.haxx.se/docs/todo.html#remove_progress_meter_from_libcu

Note that this is in the section of things to consider doing at "Next major release". We can't do this without bumping the soname etc.

Post by Stephen McDowell

applications can and should do their own progress meters using the progress callback

Is this referring to `curl` the command-line tool, or is this referring to the developer interface?

The "internal progress meter" is the progress meter that curl shows (by default) that is output by libcurl.

Post by Stephen McDowell
If the intent is to remove the progress bar from `curl` the command line tool, then no issue is warranted.

Again: that's idea is for next major version. We're talking several years into the future and that's just an idea, nothing that's written in stone.
But also, removing the internal progress meter would basically mean that we'd re-implement it in the curl tool code since I think curl needs a progress meter.

Post by Stephen McDowell
If the progress bar is going to be kept in the `curl` command-line tool, then I will raise the issue explaining one way to reproduce the problem. Short version is that it sometimes skips the carriage return, which on Travis CI can lead to killed jobs.

Please do.
Just keep in mind that if you use "native" curl on travis, you probably use a rather outdated version that very well might not work like that anymore. We rarely have bandwidth enough to investigate problems on old versions if they don't reproduce in the latest.
--
/ daniel.haxx.se
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html

[Daniel Stenberg]

Post by Stephen McDowell
We can reproduce the effect locally by using a small terminal size (e.g., <
40 chars wide), but the Travis specific failure is likely caused by
something else. It’s an unfortunate heisenbug (doesn’t happen always, just
frequently), so I will try my best to see if I can find a reliable way to
reproduce it.

If you check the code [1], you'll see that the default progress meter output
doesn't care about the screen width but just assumes it'll be >= 80 columns
and will fit the output...

[1] = https://github.com/curl/curl/blob/e953475de59407051d45b46634fd2d8ddc725e9e/lib/progress.c#L581-L598