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

[Rob Landley]

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?)

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.

> 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.

> 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.

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

Rob