Re: [Toybox] [PATCH] top: don't report GiB sizes in KiB.
On 9/8/20 12:20 AM, Jarno Mäkipää wrote: > Im sorry didint want to cause argument. I was happy with the big long strings of numbers we had to start with. I just don't consider "make the strings shorter with no other change/reason" to be a fix. > But atleast 1/3 of world teach > to use comma as decimal separator (most old french colonies etc...) so > someone else might have got confused and report this sooner or later. Indeed. If libc grows support for distinguishing these, toybox should use it. I'd like to put the code in speculatively so it's not my problem it's wrong. :) I haven't done it _yet_ because I'm trying to teach toysh how to properly parse case statements. I got the all-on-one-line version working but when you start throwing newlines in there the parser gets confused at the variable granularity of input and when to request line continuations. The fundamental problem is case statements have unbalanced ) in them which the generic parser barfs on so I have to special case that: case i in i) echo hello ;; esac is equivalent to: case i in i) echo hello esac But for SOME reason I can replace THAT newline with a ; but can't put a ; anywhere before the ) BECAUSE REASONS. (And yes the terminating ;; was optional in the last position. And the other variants like ;& are considered equivalent there rather than errors. And yes I still need to catch "case i in i) echo hello | esac" or && but & is fine, you can put a & after a break and bash takes it because reasons... Oh, and I _probably_ fly back to Japan around the 19th for work. Not sure yet, still filing paperwork. Anyway: distracted. :) >>> 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? > > Eh? not sure are you joking. Honest ignorance. You were saying you use period, now you're saying you use space. This is not my area of expertise. I'm happy to ask libc. >> 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.) > > Yeah I agree fixing it properly would move the problem out of toybox > context. Im sure we dont want to be arguing what is comma used for. It's an aesthetic issue, therefore there is endless bikeshedding which cannot be terminated by normal open source development practices other than A) maintainer fiat, B) appeal to some standards body that puts out "an ISO standard cup of tea" and ISO standard peanut butter. Yes, both exist: https://www-s.nist.gov/srmors/view_detail.cfm?srm=2387 https://en.wikipedia.org/wiki/ISO_3103 And yes there's reasons for it: https://www.youtube.com/watch?v=nAsrsMPftOI Everything is domain expertise and it's all fractal: https://xkcd.com/1095/ And often you have to learn enough about something to determine you don't have to care and can chuck it all in the bin. https://blog.w1r3.net/2018/01/06/rob-landley-about-usr-split.html This is sometimes called the "grandma's roasting pan fallacy": https://predictablesuccess.com/3-ways-youre-trapped-by-past-success/ The whole POINT of busybox and toybox was to ask "yes, but do we need to do that" to make things smaller and simpler. In this case it sounds like yes, we need to do that. The options are Don't Go There (Elliott says long strings of numbers are unhappy-making), feed everybody commas (makes 1/3 the population of the planet unhappy), or fish it out of libc's internationalizatoin setting (which is small in this instance, at least nominally standardized, and I can fall back to #2 if libc doesn't implement it). (People will then bitch about date formats and I will probably ignore them because they didn't complain about it when it went in an the fix ISN'T small in that case.) >> 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 >>
Re: [Toybox] [PATCH] SIGHUP to init.c triggers inittab reload
Thanks Rob, and no worries- I've been able to use the init.c for a few months now, with only that patch. So hopefully cleanup won't be so bad! :) +Chris On Tue, Sep 1, 2020 at 11:16 PM Rob Landley wrote: > On 9/1/20 9:22 PM, Chris Sarra via Toybox wrote: > > --- > > toys/pending/init.c | 25 - > > 1 file changed, 24 insertions(+), 1 deletion(-) > > Applied, but this command is in pending. Caviar Emperor and all that... > > https://github.com/landley/toybox/blob/master/toys/pending/README#L6 > > (Yes, I should https://landley.net/toybox/cleanup.html all the pending > stuff, > alas this is still not my day job, doing what I can...) > > Thanks for the patch, > > Rob > ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] top: don't report GiB sizes in KiB.
On Mon, Sep 7, 2020 at 1:29 PM Rob Landley wrote: > On 9/6/20 6:45 AM, Jarno Mäkipää wrote: > > On Sun, Sep 6, 2020 at 12:34 PM Rob Landley 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 > ___ Toybox mailing list Toybox@lists.landley.net
Re: [Toybox] Android binaries?
On Thu, Sep 3, 2020 at 11:34 PM Rob Landley wrote: > On 9/3/20 10:02 AM, enh wrote: > > Isn't it 6 digits now? 99 processes? (Didn't we have this > discussion already > > about ps? In theory top inherits that code...) > > > > > > Yes, but my desktop has 7 digits (now at least --- I don't know whether > my > > desktop and laptop always differed like this, or this is from the ubuntu > -> > > debian switch). > > Are you willing to admit threads were a mistake yet? :) > to be clear, i only have 412 different pids on this machine. but the current largest is 4116808. (the "mistake" is that pids are meant to be a unique identifier but come from a small pool --- not having something like pidfd since the 1970s.) > > We could bump the hard-coded value again, but that seems like a lot of > wasted > > empty columns for small systems? > > I have confidence that a truly threaded system can hit 8 anyway. > well, someone will configure a system to use the full range of an int at some point, yes. > Alright, am I writing to the typos array already? That really looks like it > should be in read-only memory but currently isn't, I forget why. (Vague > "tried > it and it didn't work" vibes but what specifically happened? I almost > certainly > have a todo item for it somewhere...) > > Pushed. Try now? > yeah, lgtm on both a phone and a "real computer". thanks! > Rob > ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
[Toybox] [PATCH] logger.c was failing to properly log local0-local6 facilities, due to a string parsing error. This patch enables proper local facility handling.
---
toys/posix/logger.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/toys/posix/logger.c b/toys/posix/logger.c
index 3bcfb174..d1cc7291 100644
--- a/toys/posix/logger.c
+++ b/toys/posix/logger.c
@@ -64,9 +64,10 @@ void logger_main(void)
else {
*s1++ = len = 0;
facility = arrayfind(TT.p, facilities, ARRAY_LEN(facilities));
- if (facility == -1 && strncasecmp(TT.p, "local", 5)) {
-facility = s1[5]-'0';
-if (facility>7 || s1[6]) facility = -1;
+ if (facility == -1 && strncasecmp(TT.p, "local", 5) == 0) {
+s2 = TT.p;
+facility = s2[5]-'0';
+if (facility>7 || s2[6]) facility = -1;
if (facility>=0) facility += 16;
}
if (facility<0) error_exit("bad facility: %s", TT.p);
--
2.28.0.526.ge36021eeef-goog
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] logger.c was failing to properly log local0-local6 facilities, due to a string parsing error. This patch enables proper local facility handling.
On 9/8/20 2:16 PM, Chris Sarra via Toybox wrote:
> ---
> toys/posix/logger.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/toys/posix/logger.c b/toys/posix/logger.c
> index 3bcfb174..d1cc7291 100644
> --- a/toys/posix/logger.c
> +++ b/toys/posix/logger.c
> @@ -64,9 +64,10 @@ void logger_main(void)
> else {
>*s1++ = len = 0;
>facility = arrayfind(TT.p, facilities, ARRAY_LEN(facilities));
> - if (facility == -1 && strncasecmp(TT.p, "local", 5)) {
> -facility = s1[5]-'0';
> -if (facility>7 || s1[6]) facility = -1;
> + if (facility == -1 && strncasecmp(TT.p, "local", 5) == 0) {
> +s2 = TT.p;
> +facility = s2[5]-'0';
> +if (facility>7 || s2[6]) facility = -1;
Sigh, why did I promote this out of pending? arrayfind() initializes matchlen to
0 and then never sets it to anything ELSE, so it ONLY returns exact matches not
longest unambiguous match (which is the point of the function I think?)
Applied your patch, but I have some cleanup to do to this command...
Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
