On Thu, Sep 3, 2020, 01:04 Rob Landley <r...@landley.net> wrote: > On 9/2/20 12:01 PM, enh wrote: > > if you choose sdk_arm64 (or sdk_x86_64) off ci.android.com > > <http://ci.android.com>, click on the little "download" icon on most > recent > > green build (or whichever build you want), the list of artifacts should > now > > contain toybox-static32 and toybox-static64. > > Yay! Ish. Hmmm... Ah, I was looking at sdk_x86, not sdk_x86_64. Yay, found > it. > > > so some human effort required (afaik there's no URL that gives you the > latest > > green build), but a lot less effort than building AOSP... > > > https://ci.android.com/builds/submitted/6810156/sdk_x86_64-sdk/latest/toybox-static64 > works but https://ci.android.com/builds/submitted/ is 404 which means > this isn't > a real web page but a database lookup emitted by CGI parsing the whole > URL. So > having a "latest" symlink under submitted isn't a question of a dumb little > script to ln -sf after a successful build, instead somebody has to find the > person who understands code that's never shipped to the outside world to > dig > through to where a new feature would need to be added in the plumbing. > > Sigh. If you hover over the top level cell that says "sdk" the hover text > says > "show last known good build", so there IS awareness that this is a feature > people would want... but of course it's not a URL. It's javascript to > redisplay > the table showing just one row. Extra code to be LESS flexible. > > > ~/Downloads$ chmod a+x ./toybox-static64 > > ~/Downloads$ ./toybox-static64 date > > Wed Sep 2 16:44:54 GMT 2020 > > > > i'm not going to run anything else on this "real computer" or i'll be > back > > complaining that we should change top to not use KiB on a machine with > 64GiB of > > RAM, > > My current laptop (Dell Latitude E6230, I spent almost $200 on this thing > _before_ upgrading the memory and hard drive) has 16 gigs of ram, same > number of > digits. > > The human_readable_long() plumbing will adjust the units to show the > appropriate > number of digits, the thing is we're telling it "8 digits" and 16229720K > is 8 > digits (plus a unit). > > I think you want commas, which would take up digits and bump it down to > 16,230M? > > > and that we need to examine /proc/sys/kernel/pid_max to know how wide pid > > fields need to be again :-) > > Isn't it 6 digits now? 999999 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). We could bump the hard-coded value again, but that seems like a lot of wasted empty columns for small systems? > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net