On Fri, Sep 11, 2020 at 11:41 AM Rob Landley <r...@landley.net> wrote:
> 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"...) > 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. > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
