[Toybox] [PATCH] top: don't report GiB sizes in KiB.

[Rob Landley]

On 9/10/20 1:42 PM, enh wrote:
>     The design is short of shifting out from under human_readable(). The above
>     probably fixes it, but if this happens again I should step back and rethink the
>     objective here. (Specifying units instead of autodetecting them, 
> 
> fwiw, that's how both Android and Chrome's equivalents ended up: two variants,
> one with auto-detection and another where the caller passes in the units.

I added an argument to pass in the units. It can auto-adjust up from there if
there aren't enough digits, but not down. Not supplying enough digits to display
a number in the units you want is pilot error.

>     possibly a
>     version that operates on an array of values instead of one at a time. 
> 
> 
> (but that's an interesting idea too.)
>  
> 
>     There's a
>     lot of "measure all the output so it matches up" ala ls, and no generic plumbing
>     to handle that, but a design for efficient plumbing to handle that is not
>     immediately obvious to me. Hmmm...)
> 
> that's something i've wondered about a couple of  times too, but  i think that's
> an orthogonal  problem to this one. ls deliberately mismatches units, and
> despite what i've said here about consistency in tables, i think that's the
> right behavior for ls. you don't have any reason to  expect that the entries in
> ls' output are likely to be at all similar, whereas with top you're basically
> carving up your available RAM, so the entries are effectively "percentages that
> humans can grok better" :-)

The "top" entries are already auto-adjusting units:

  PID USER         PR  NI VIRT  RES  SHR S[%CPU] %MEM     TIME+ ARGS
13347 landley      20   0 6.1M 1.7M 1.5M R 35.1   0.0   0:00.05 top
31919 landley      20   0 1.5G 238M  94M S  5.4   1.4  34:45.26 chromium --type+
11907 landley      20   0 4.7G 1.3G 119M S  5.4   8.3 935:00.04 chromium --show+

Chromium is being its usual self, and we have 4 characters per memory field.

Right now I have a patch to make the commas just care about "1,234.5" vs
"1.234,5" as a binary choice (which covers the vast majority of the planet, and
will never matter on android anyway because you nerfed that), vs a patch to
revert the whole mess back to how it was before I started meddling with it.

(I looked at removing and commas but keeping the megabyte forcing, which gets
back to "with 8 digits of space 64 gigs would still show as kilobytes, which is
what you were objecting to in the first place, despite that being what debian
does for me with 16 gigs of ram I.E. 8 digits"...)

Rob