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

Tue Sep 8 11:55:33 PDT 2020

On Mon, Sep 7, 2020 at 1:29 PM Rob Landley <rob at landley.net> wrote:

> On 9/6/20 6:45 AM, Jarno Mäkipää wrote:
> > On Sun, Sep 6, 2020 at 12:34 PM Rob Landley <rob at landley.net> wrote:
> >> Elliott says there's a maximum limit on the number of digits users are
> willing
> >> to parse, and you're saying it's better to just have large blank gaps
> between
> >> the numbers than to use that space for anything, AND that the cap on
> the maximum
> >> number of digits is insurmountable rather than using separators like
> people have
> >> been doing for hundreds of years to cope with long numbers in "human
> readable"
> >> output?
> >>
> >> It's certainly a point of view.
> >
> > Groups of 3 are indeed easier for eye. I would suggest using something
> > more sensible like spaces.
>
> Which is not what any country uses by default and thus makes everyone
> equally do
> a double take? Egalitarian badness?
>
> Hardwiring it to the esperanto of formats is certainly a suggestion.
>
> > SI system uses spaces as thousands separator, comma and period both
> > being valid decimal separator.
> > 123 456.789 or 123 456,789
>
> Ok, I'll bite: which countries teach SI to their kids in primary school?
>
> >> Bravo. And bionic's libc/bionic/locale.gratuitouslycppbutactuallyc says:
> >>
> >>   // We only support two locales, the "C" locale (also known as
> "POSIX"),
> >>   // and the "C.UTF-8" locale (also known as "en_US.UTF-8").
> >>
> >> So they don't support it either.
> >
> > C.UTF-8 and en_US.UTF-8 are not same.
>
> I cut and pasted that out of the bionic source.
>
> >> However, if the commas go, why doesn't the period in human_readable()
> go? I
> >> don't see how they're conceptually different?
>
> I'm waiting for an opinion from Elliott, which might be a "meh?" because
> it's
> not exactly his area either.
>

i actually felt that 5 digits was small enough to not need separators.

a couple of things do stand out though. here's toybox and procps-ng 3.3.16
on Debian on my middling "real computer":

  Mem:   63,978M total,   53,696M used,   10,282M free,     1870M buffers
 Swap:   56,095M total,      0.0M used,   56,088M free,   35,929M cached

MiB Mem :  63978.8 total,  10287.4 free,  13083.5 used,  40607.9 buff/cache
MiB Swap:  56096.0 total,  56088.2 free,      7.8 used.  49419.2 avail Mem

on the whole i prefer the toybox output, apart from the bug that gets us
"1870M" rather than "1,870M" to match the others, and the weird "0.0M". i'd
always use decimals or never use decimals.

toybox doesn't do as good a job on the smallest system available to me
right now (a phone from a couple of years ago):

  Mem:     3931M total,     2149M used,     1782M free,     6336K buffers
 Swap:     2948M total,      0.0K used,     2948M free,     1485M cached

there's the same 0.0 issue (though the ',' bug cancels itself out here
because all the fields are consistent and -- imho -- 4 digits is definitely
readable without separators anyway). i still dislike that "buffers" is
using K where the others are using M. that to me still seems like the worst
issue: i think we should always use the same units (which procps at least
seems to do, even if they are sometimes KiB and other times MiB). which is
basically a stronger version of the decimals complaint --- it's a
table, and it's really weird when different fields in the table are in
different units.

i don't think on a 3GiB system that i actually want to know whether i have
6.2MiB or 6.3MiB of buffers --- "6" is fine. but even if i did know, i'd
want to see 6.2 vs 3931.0 rather than switch units mid-row.

> A proper fix would be a localeconv() in libc that DOESN'T return constant
> stub
> info, which is out of scope for toybox. (And is as much an ADB thing as a
> bionic
> thing since android seems to be using adb instead of ssh, so that would
> have to
> marshall the locale environment variables from the host into the target.
> But I
> often "wait for somebody to complain", you complained, and therefore I
> want to
> fix it PROPERLY.)
>
> In the meantime, I can add a call to localeconv() that would use "," if
> that
> returns "" which means right now it would be a NOP but then it's not my
> fault
> it's getting it wrong. And I can test against glibc which does have an
> overengineered version of this in it. Way back when uClibc had a much
> compressed
> format for the localeconv data, but didn't have a database of countries
> and thus
> copied its data from glibc, which it couldn't distribute for licensing
> reasons:
>
>   https://lists.uclibc.org/pipermail/uclibc/2015-June/049000.html
>
> Rob
>
> P.S. I ranted about this sort of aesthetic issue being something the open
> source
> development model can't deal with 10 years ago, almost to the day:
>
>   https://landley.net/notes-2010.html#13-08-2010
>
> And included it in my 2013 talk:
>
>   https://www.youtube.com/watch?v=SGmtP5Lg_t0#t=11m30s
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20200908/24a55e72/attachment-0001.htm>