<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 11:41 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/10/20 1:42 PM, enh wrote:<br>
>     The design is short of shifting out from under human_readable(). The above<br>
>     probably fixes it, but if this happens again I should step back and rethink the<br>
>     objective here. (Specifying units instead of autodetecting them, <br>
> <br>
> fwiw, that's how both Android and Chrome's equivalents ended up: two variants,<br>
> one with auto-detection and another where the caller passes in the units.<br>
<br>
I added an argument to pass in the units. It can auto-adjust up from there if<br>
there aren't enough digits, but not down. Not supplying enough digits to display<br>
a number in the units you want is pilot error.<br>
<br>
>     possibly a<br>
>     version that operates on an array of values instead of one at a time. <br>
> <br>
> <br>
> (but that's an interesting idea too.)<br>
>  <br>
> <br>
>     There's a<br>
>     lot of "measure all the output so it matches up" ala ls, and no generic plumbing<br>
>     to handle that, but a design for efficient plumbing to handle that is not<br>
>     immediately obvious to me. Hmmm...)<br>
> <br>
> that's something i've wondered about a couple of  times too, but  i think that's<br>
> an orthogonal  problem to this one. ls deliberately mismatches units, and<br>
> despite what i've said here about consistency in tables, i think that's the<br>
> right behavior for ls. you don't have any reason to  expect that the entries in<br>
> ls' output are likely to be at all similar, whereas with top you're basically<br>
> carving up your available RAM, so the entries are effectively "percentages that<br>
> humans can grok better" :-)<br>
<br>
The "top" entries are already auto-adjusting units:<br>
<br>
  PID USER         PR  NI VIRT  RES  SHR S[%CPU] %MEM     TIME+ ARGS<br>
13347 landley      20   0 6.1M 1.7M 1.5M R 35.1   0.0   0:00.05 top<br>
31919 landley      20   0 1.5G 238M  94M S  5.4   1.4  34:45.26 chromium --type+<br>
11907 landley      20   0 4.7G 1.3G 119M S  5.4   8.3 935:00.04 chromium --show+<br>
<br>
Chromium is being its usual self, and we have 4 characters per memory field.<br>
<br>
Right now I have a patch to make the commas just care about "1,234.5" vs<br>
"1.234,5" as a binary choice (which covers the vast majority of the planet, and<br>
will never matter on android anyway because you nerfed that), vs a patch to<br>
revert the whole mess back to how it was before I started meddling with it.<br>
<br>
(I looked at removing and commas but keeping the megabyte forcing, which gets<br>
back to "with 8 digits of space 64 gigs would still show as kilobytes, which is<br>
what you were objecting to in the first place, despite that being what debian<br>
does for me with 16 gigs of ram I.E. 8 digits"...)<br></blockquote><div><br></div><div>do you have an older or newer top than me? i gave my version number before (procps-ng 3.3.16) but didn't explicitly say i was doing so in order for you to be able to compare. i get MiB even on a box with only 16GiB.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>