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

[Jarno Mäkipää]

On Sun, Sep 6, 2020 at 12:34 PM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 9/5/20 1:42 AM, Jarno Mäkipää wrote:
> > On Fri, Sep 4, 2020 at 9:22 AM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 9/3/20 9:56 AM, enh wrote:
> >>> I think hard-coded MiB would be fine for me right now,
> >>
> >> I'm worried that on embedded systems that _don't_ have gigs of memory, kilobytes
> >> may be the desired units, so auto-adjusting makes sense. (If you have 16 megs
> >> ram you care about a 300k fluctuation which you can't even SEE if the units are
> >> megabytes.)
> >>
> >>> but -- re-reading the
> >>> full discussion from last time rather than relying on my memory -- it seems like
> >>> your main complaint the first time I tried to fix this was that you didn't like
> >>> the possibility of not using the same unit for every value.
> >>
> >> I don't, but it's a lesser of two evils kind of thing.
> >>
> >>> So hard-coding MiB
> >>> might be better in that it would be more likely to stick rather than getting
> >>> reverted.
> >>
> >> Given that I'd be the one doing the reverting and I'm suggesting this solution... :)
> >>
> >> Ok, human_readable_long() is more or less only used directly by ps.c. (The other
> >> 2 files are demo_number.c and lib/lib.c wrapping it in human_readable()
> >> providing defaults for the micromanagement fields.) So instead of detecting
> >> "units" from 0 I can feed it a minimum units (k=1, M=2, and so on). So I can
> >> have the ps.c check the total size field and if it's 10 gig or larger force
> >> megabytes, and otherwise do kilobytes. (It's gotta be at least kilobytes because
> >> the granularity of the input is kilobytes anyway...)
> >>
> >> I pushed a change. On my laptop it now looks like:
> >>
> >>   Mem:   15,955M total,   15,426M used,      528M free,      151M buffers
> >>  Swap:   16,286M total,      523M used,   15,763M free,     1594M cached
> >
> > Comma is a decimal separator in Finland and also in some other parts
> > of Europe. So quick glance I thought you have 16megs of ram.
>
> Yet this wasn't a problem before on all other human_readable() output using "."
> as the decimal separator? (I.E. you consider it a _new_ problem?)

Problem for me is not using "." as decimal separator, both "." and ","
are easily understandable. But having thousands separator makes things
different when command spits out 16,256 or 16.256

>
> I can call some sort of lc_eldrich_nonsense() function, although reading
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html is not
> immediately providing usable example code...
>
> > https://docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html
>
> Oratroll's a patent troll at this point, on the SCO level. (Dying business
> models explode into a cloud of IP litigation.) I'm reluctant to follow a link to
> anything on their website because it feels like entrapment.

Sorry perhaps oracle website is not best source of information. But it
happened to be first link on google search to show table of some
numbering systems.

>
> > I would drop thousands separators since it's probably more confusing
> > than helpful.
>
> 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.
SI system uses spaces as thousands separator, comma and period both
being valid decimal separator.
123 456.789 or 123 456,789

>
> > Ubuntu with my locale settings actually gives me this, and i'm not
> > even sure what is the meaning of the number after comma :)
> > MiB Mem :  15936,4 total,  13507,9 free,   1196,7 used,   1231,9 buff/cache
> > MiB Swap:   2048,0 total,   2048,0 free,      0,0 used.  14407,5 avail Mem
>
> Tenths. It's your decimal separator.
>
> Your inability to read your OWN locale, in the existing ubuntu output, kind of
> undermines your objection that the new format is freshly problematic. But I
> agree it should use the locale separator... Except musl is hardwired to return a
> constant structure regardless of locale, and doesn't actually support them:
>
>   https://git.musl-libc.org/cgit/musl/tree/src/locale/localeconv.c
>
> 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. Date formatting is different and
LC_NUMERIC=C.UTF-8 does not have thousands separator?

~$ export LC_ALL=C.UTF-8
~$ locale -ck LC_NUMERIC
LC_NUMERIC
decimal_point="."
thousands_sep=""
grouping=-1
numeric-decimal-point-wc=46
numeric-thousands-sep-wc=0
numeric-codeset="UTF-8"

~$ export LC_ALL=en_US.UTF-8
~$ locale -ck LC_NUMERIC
LC_NUMERIC
decimal_point="."
thousands_sep=","
grouping=3;3
numeric-decimal-point-wc=46
numeric-thousands-sep-wc=44
numeric-codeset="UTF-8"

>
> However, if the commas go, why doesn't the period in human_readable() go? I
> don't see how they're conceptually different?
>
> Rob

-Jarno