[Toybox] Android binaries?

[Rob Landley]

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

Rob