Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GDALTermProgress: display estimated remaining time for tasks >= 10 seconds #11152

Merged
merged 4 commits into from
Oct 29, 2024

Conversation

rouault
Copy link
Member

@rouault rouault commented Oct 28, 2024

Refreshed every tick (so 2.5%)

(only on interactive terminals. Tested with bash on Linux and cmd on Windows, but should work for all reasonable terminals)

Before 5 seconds:
0...10...20...

After 5 seconds:
0...10...20...30...40...50                           - estimated remaining time: 00:00:07

Upon completion:
0...10...20...30...40...50...60...70...80...90...100 - done in 00:00:13.

Fixes #11100

@rouault rouault added this to the 3.11.0 milestone Oct 28, 2024
@rouault rouault added the funded through GSP Work funded through the GDAL Sponsorship Program label Oct 28, 2024
port/cpl_progress.cpp Outdated Show resolved Hide resolved

if (nThisTick <= nLastTick)
return TRUE;

const time_t nCurTime = time(nullptr);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the "modern" version would be std::chrono::system_clock::now() but any advantage in this case is not not obvious...

@dbaston
Copy link
Member

dbaston commented Oct 28, 2024

Some changes suggested at rouault#62

This changes output for me somewhat, e.g. gdalwarp in master would print

Processing /home/dan/Downloads/adaptor.mars.internal-1724252977.7562788-9817-17-5c4869a4-66ce-451e-a86e-66afc72a3873.nc [1/1] : 0..

but when the time estimate kicks in, the first part of the line (Processing...[1/1] : ) is overwritten.

@rouault
Copy link
Member Author

rouault commented Oct 28, 2024

but when the time estimate kicks in, the first part of the line (Processing...[1/1] : ) is overwritten.

fixed. I've changed the strategy to output as many \b as emitted during last call

rouault and others added 4 commits October 28, 2024 23:01
…conds

Refreshed every tick (so 2.5%)

(only on interactive terminals. Tested with bash on Linux and cmd on Windows,
but should work for all reasonable terminals)

```
Before 5 seconds:
0...10...20...

After 5 seconds:
0...10...20...30...40...50                           - estimated remaining time: 00:00:07

Upon completion:
0...10...20...30...40...50...60...70...80...90...100 - done in 00:00:13.
```

Fixes OSGeo#11100

Co-authored-by: Daniel Baston <[email protected]>
@coveralls
Copy link
Collaborator

Coverage Status

coverage: 69.452% (-0.001%) from 69.453%
when pulling 67f18e2 on rouault:fix_11100
into 0332c83 on OSGeo:master.

@rouault rouault merged commit 71535b5 into OSGeo:master Oct 29, 2024
37 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
funded through GSP Work funded through the GDAL Sponsorship Program
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Terminal progress bar: add estimated remaining time
3 participants