Proper implementation of memory_unit and mem_precision #52
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
I can't believe that
hyfetch
has been showing wrong (inaccurate at best) values for used/total memory for this long. And the memory precision feature seems broken from the beginning.The problem: if we had 15,361 to 16,383 KiB of memory,
hyfetch
would show15.00 MiB
instead of the correct decimal value, because it represented memory values in integral MiB internally. If we had 8,192 MiB of memory,hyfetch
would show 0.819 TiB (!) instead of 0.008 TiB (if you chose that unit), because the algorithm for digits after the decimal point was incorrect.To fix the problem, we change to KiB internal representation (basically remove one division by 1024 from raw values), and we rewrite the assignment for final
mem_used
andmem_total
strings. Still noawk
involved!Features
Issues
bar_length
were very large (>4000), it might overflow on 32-bit machines.mem_precision
were large (>=10 on 32-bit or >=19 on 64-bit), it would overflow.TODO