Show elapsed time in minutes if >= 60 secs #5456
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
That's what I get for using the GitHub web editor to hack on Cargo... Anyway, now I fixed the problem and ran |
|
@bors r+ Thanks! I think that this might break some tools that try to parse this time, but this is a human-readable output, and we don't guarantee its stability. |
|
📌 Commit f7773d8 has been approved by |
|
⌛ Testing commit f7773d88eb2befee1cdd0cb67c0fce2c726e0847 with merge b21b44a09ea657e42bd6749d6c4a009747d15d5e... |
|
💔 Test failed - status-travis |
|
@bors: retry |
|
☔ The latest upstream changes (presumably #5432) made this pull request unmergeable. Please resolve the merge conflicts. |
In large projects with long compile times, seeing "400.65 secs" isn't as clear as seeing the number of minutes (and seconds).
|
Rebased |
|
@bors: r=matklad |
|
📌 Commit 3572813 has been approved by |
Show elapsed time in minutes if >= 60 secs In large projects with long compile times, seeing "428.65 secs" isn't as clear to humans as seeing the number of minutes (and seconds). **Old**: ``` Finished dev [unoptimized + debuginfo] target(s) in 2.23 secs Finished dev [unoptimized + debuginfo] target(s) in 63.94 secs Finished dev [unoptimized + debuginfo] target(s) in 428.65 secs ``` **New**: ``` Finished dev [unoptimized + debuginfo] target(s) in 2.23s Finished dev [unoptimized + debuginfo] target(s) in 1m 3.94s Finished dev [unoptimized + debuginfo] target(s) in 7m 8.65s ``` Note that I also changed `secs` to `s`, because `7 mins 8.65 secs` and `7m 8.65 secs` both look strange IMO. But if you disagree and you'd prefer `secs`, just tell me and I'll change it. I *didn't* add a check for `secs >= 3600` to print the time in hours. I *hope* this is not necessary...
|
☀️ Test successful - status-appveyor, status-travis |
|
The seconds' fraction is redundant with minutes, imho, but it's too late. |
It's never to late for a PR :) |
|
@pravic agreed, without the fractions it would look cleaner! |
|
I agree, too. |
Does not print seconds fraction with minutes As discussed in #5456 (comment), seconds fraction seems unnecessary when the elapsed time is reported in minutes.
In large projects with long compile times, seeing "428.65 secs" isn't as clear to humans as seeing the number of minutes (and seconds).
Old:
New:
Note that I also changed
secstos, because7 mins 8.65 secsand7m 8.65 secsboth look strange IMO. But if you disagree and you'd prefersecs, just tell me and I'll change it.I didn't add a check for
secs >= 3600to print the time in hours. I hope this is not necessary...