That patch is reasonable, and shouldn't break anything as long as the list you provide is a subset of the possible list.

fill in the details a bit.

• Fix stderr vs stdout mixup.

After D21796:

(one orthogonal bug I found is that bin/drydock lease discards any blueprints provided in an attributes JSON)

(one orthogonal bug I found is that bin/drydock lease discards any blueprints provided in an attributes JSON)

Grab a test lease on the host with:

Harbormaster needs a "Working Copy" blueprint, not just a "Host" blueprint.

Here's a fairly simple way to reproduce this:

How do modern servers written in C/C++ handle parallelizing requests?

Just for my own notes:

FWIW I've found by far the easiest way to work with microcontrollers is using micropython / circuitpython on any of these chips: ESP32, ATSAMD21/ATSAMD51 and RP2040. The esp32 is in many ways the easiest and most practical because it's extremely cheap and includes a wifi radio.

What are the practical limits of multi-system or multi-architecture binaries?

Just for visibility, this is I believe the change that broke Diffusion (which was fixed in rP52df4ff515b7), where the error message is something like

I generated D21794 with a native binary that has no dependency on system PHP (but does depend on system cURL).

Another open question is: before we call posix_isatty(STDOUT), how do we test whether STDOUT is a valid handle?

1. PHP doesn't link cURL statically and doesn't appear (?) to provide any easy way to link it statically.
   1. • Possible solution: build static cURL.
      • Possible solution: link cURL dynamically.
      • Possible solution: replace cURL with mbedTLS + a first-party HTTP client, since we don't care about 99% of what cURL does. Or implement first-party TLS hahaha except I'm half-serious? If HTTP/HTTPS is going to happen from an embedded context on my coffee maker I need a healthy embeddable TLS + HTTP stack anyway.
   2. The STDERR and STDOUT constants are defined by the CLI SAPI, and not present in the embed SAPI.
      • Possible solution: define them in the C wrapper.
      • Possible solution: polyfill them at startup in PHP (I'm not entirely sure this is possible).
      • Possible solution: abstract around them and use php://stderr and php://stdout instead. See also T13556. This is likely desirable anyway.
   3. When arc tries to load PHP code, it needs to read data out of the executable binary in some set of conditions (e.g., "if we miss on disk").
      • Possible solution: hook zend_compile_file(), which seems to be the expected way to approach this. The flow in phar_compile_file() seems similar.
   4. To run unit tests, arc depends on the presence of a php binary on the system.
      • Possible solution: accept that you must also have PHP to run arc's tests (and that system PHP may differ from arc php).
      • Possible solution: also include the PHP CLI wrapper and invoke it when arc is executed as php, providing what is essentially a fallback toolset.
      • Possible solution: provide a "unit test helper" fallback toolset.
      • Possible solution: rewrite the 5 trivial cases where we need this (support/unit/*) in shell script (but: the reason to do these in PHP in the first place was so that they're portable to Windows).

Can we build a single binary with a bunch of data in it (e.g., a picture of a cat) without breaking anything?

See T5479.

See T5479.

See T5479.

I removed Phragment in D21793.

My initial linter implementation didn't actually catch all of these so there were a few more than I expected, but I think I got essentially all of them.