On 9/6/20 6:45 AM, Jarno Mäkipää wrote: > On Sun, Sep 6, 2020 at 12:34 PM Rob Landley <r...@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. 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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net