improve human readable output#459
Conversation
67d6240 to
42238c9
Compare
|
As there is a new pre-release... Can I have a quick feedback and state on this? |
|
The current release only has bugfixes in the main code (it's only the adjunct scripts & manpages that got enhancements). I'm very cautious in making output-affecting changing, but will be giving this a closer look. |
|
I can understand you are cautious about making output-affecting changing, guess this is due to breaking scripts that expect specific output? |
|
@eworm-de could you add a description of the before and after of what this change does? Needs a bit more context than "improve" :-) |
|
The commit messages have the details. Are you missing something there or just here in the pull request? |
933dc1f to
75ea671
Compare
|
This is the output of |
0ca5744 to
6abcd9b
Compare
|
Just added another commit: |
a20c3e6 to
cb0b932
Compare
I still stand by my point: This is about human readable output. We should not be worried too much about compatibility with parsers. |
|
Any news on this? Does it help if I split this across several pull requests? |
9bcdb1b to
050399c
Compare
46d2d98 to
a5a0fa6
Compare
8a3cf64 to
d6590e2
Compare
bfd68be to
3c73315
Compare
bbe72ad to
1ce460f
Compare
92ae807 to
0a8a9a1
Compare
3f15dd9 to
f277657
Compare
677d70d to
8a2efa4
Compare
This drops a lot of `else if` blocks and extends units by "E" (Exa), which is 2^60 and thus the last to fit into int64.
Let's lower precision for huge numbers. The output used to be: 3.45M -> 46.73M -> 523.11M -> 1.24G -> ... With this change the code always gives the three most significant digits: 3.45M -> 46.7M -> 523M -> 1.24G -> ...
... just make sure no precision is added.
Let's also simplify the code for rate in progress, and benefit from same functionality.
Calculate in a loop, use dynamic precision.