@ai-ecoverse/slicc-kernel 1.108.1 → 1.108.3

package/README.md

@@ -333,7 +333,7 @@ A WASI command can name an ES module of its package that provides imports of its
 
 ### JS programs
 
-A command can be an ES module instead of a wasm program: `"abi": "js"` and `module` name the module in the package, which must be one self-contained file (no relative or bare imports), and `args`, `argv0` and `env` work as for other commands. An entry with `"abi": "js"` but no `module` (or one outside the package) is not a command, like a wasm entry without its module, so running it fails with 127.
+A command can be an ES module instead of a wasm program: `"abi": "js"` and `module` name the module in the package, which must be one self-contained file (no relative or bare imports), and `args`, `argv0` and `env` work as for other commands. An entry with `"abi": "js"` but no `module` (or one outside the package) is not a command, like a wasm entry without its module, so running it fails with 127. Every run gets its own process worker, so each process evaluates the module afresh: module-level state never carries over from one run to the next. The kernel keeps an importable URL per module source (a `blob:` URL in the browser, a base64 `data:` URL under Node) for the 16 sources it ran last, so a command run in a loop doesn't encode its module again each time ([#846](https://github.com/ai-ecoverse/slicc-kernel/issues/846)). A changed file is a new source and gets a new URL. An evicted URL is revoked once every run it was handed to has exited, so a run that is still loading its module never loses it.
 
 ```json
 { "slicc": { "commands": { "jstool": { "abi": "js", "module": "dist/jstool.mjs" } } } }
@@ -922,7 +922,7 @@ The Biome, TypeScript, lefthook, Renovate and CI configuration comes from [slicc
 
 `tools/big-file.mjs [bytes]` is a manual check, not part of any suite. It writes a file of that size (64 MiB by default) through a tmpfs mount with the unit-test launcher, reads it back, and prints the peak RSS and its ratio to the file size. A 256 MiB file peaks at about 1.8 times its size. Before ranged I/O (#127), a 1.1 GiB file peaked at 18 GB of RSS. **Do not run it past 1 GiB on a workstation.** It refuses anything over 256 MiB unless `SLICC_BIG_FILE_I_HAVE_THE_RAM=1` is set. Measure a small file and extrapolate instead. The unit suite checks a 32 MiB file the same way, and allows a fixed 192 MiB for garbage V8 has yet to collect, which dominates at that size.
 
-Releases are cut by semantic-release on every push to `main`, in two jobs, and only on `main`. The first job runs on the bench pool, so it starts within a minute of the push, before `main` has moved on. It computes the version, tags the commit and creates the GitHub release, with `npmPublish: false`. A run that starts after `main` has moved skips; the run for the newer commit releases it. The second job runs on a GitHub-hosted runner, because npm's trusted publishing and provenance accept no self-hosted runner. It publishes the tagged commit with `tools/release-recover.mjs`. However long it waits for a runner, it publishes exactly the commit the run started on, so the provenance, the tag and the package's `gitHead` agree. For any version tagged at HEAD, `tools/release-recover.mjs` pushes the tag if origin lacks it, publishes the version if npm lacks it (with retries), and creates its GitHub release if that is missing too. So a failure after the version is tagged (a rejected push, a failed `npm publish`) doesn't strand it, and re-running the Release workflow completes it the same way.
+Releases are cut by semantic-release on every push to `main`, in two jobs, and only on `main`. The first job runs on the bench pool, so it starts within a minute of the push, before `main` has moved on. It computes the version, tags the commit and creates the GitHub release, with `npmPublish: false`. A run that starts after `main` has moved skips; the run for the newer commit releases it. The second job runs on a GitHub-hosted runner, because npm's trusted publishing and provenance accept no self-hosted runner. It publishes the tagged commit with `tools/release-recover.mjs`. However long it waits for a runner, it publishes exactly the commit the run started on, so the provenance, the tag and the package's `gitHead` agree. For any version tagged at HEAD, `tools/release-recover.mjs` pushes the tag if origin lacks it, publishes the version if npm lacks it (with retries) and it is newer than npm's `latest` (an older one stays unpublished, so `latest` never moves back to it, and an `npm view` error fails the job instead of guessing; #837), and creates its GitHub release if that is missing too. So a failure after the version is tagged (a rejected push, a failed `npm publish`) doesn't strand it, and re-running the Release workflow completes it the same way.
 
 ### Certification (`cert-review`)
 
@@ -1002,9 +1002,9 @@ A WASIX C program for `test/integration/sigpipe.test.mjs` (#810). `pipetest MODE
 
 ### `reaptest`
 
-A WASIX C program for `test/integration/sigchld-reap.test.mjs` (#820). `reaptest MODE` forks a child that exits with 3 at once and checks after 300 ms whether `waitpid(WNOHANG)` still finds it, then forks two that exit after 100 and 250 ms and reports what `wait` returns and when. `MODE` is `ign` (`SIGCHLD` `SIG_IGN`), `nocldwait` (`SIG_DFL` with `SA_NOCLDWAIT`), `reset` (`SIG_IGN`, then `SIG_DFL`), `dfl`, or `inherited`, which first prints what `slicc.sigaction_inherited` reports for `SIGPIPE`, `SIGCHLD` and `SIGTERM`.
+A WASIX C program for `test/integration/sigchld-reap.test.mjs` (#820). `reaptest MODE` forks a child that exits with 3 at once and polls `waitpid(WNOHANG)` until the child is no longer running, then reports whether it was waitable or already reaped, then forks two that exit after 100 and 250 ms and reports what `wait` returns and when. `MODE` is `ign` (`SIGCHLD` `SIG_IGN`), `nocldwait` (`SIG_DFL` with `SA_NOCLDWAIT`), `reset` (`SIG_IGN`, then `SIG_DFL`), `dfl`, or `inherited`, which first prints what `slicc.sigaction_inherited` reports for `SIGPIPE`, `SIGCHLD` and `SIGTERM`.
 
-**Build:** `WASIX_SYSROOT_29=/path/to/wasix-sysroot ./build.sh`, with `wasixcc` 0.4.7 (legacy exceptions) and binaryen's `wasm-opt` (`--asyncify` for `proc_fork`) on `PATH`. `bin/reaptest.wasm` is 46837 bytes, sha256 `8e2718273edef94cb3882ee63ce6a9e53f03ba83ef2b2dd9759422d47fae89c7`.
+**Build:** `WASIX_SYSROOT_29=/path/to/wasix-sysroot ./build.sh`, with `wasixcc` 0.4.7 (legacy exceptions) and binaryen's `wasm-opt` (`--asyncify` for `proc_fork`) on `PATH`. `bin/reaptest.wasm` is 46,919 bytes, sha256 `b351d53b1a3b317a37642baceb731aef62a1bee387aa8972cba5d9949e1a9a3f`.
 
 ### `epolltest`
 
@@ -1084,9 +1084,9 @@ A threaded WASIX C program for `test/integration/thread-signal.test.mjs` (#520).
 
 A WASIX C program for `test/integration/long-timers.test.mjs` (#767).
 - `longwait alarm` sets `alarm(3000000)` (about 35 days), sleeps 0.5 s, and prints how many alarms came and how many seconds were left.
-- `longwait select|ppoll|nanosleep` waits 3,000,000 s on a pipe that never gets data, until a 300 ms interval timer interrupts the wait.
+- `longwait select|ppoll|nanosleep` waits 3,000,000 s on a pipe that never gets data, until a 300 ms interval timer interrupts the wait, and prints `not before it` when the wait lasted at least 300 ms (`early` otherwise). It sets no upper bound, so a loaded CI host can't fail the row; a wait that never ends times the test out.
 
-**Build:** `WASIX_SYSROOT_28=/path/to/wasix-sysroot ./build.sh`, with `wasixcc` 0.4.7 and binaryen's `wasm-opt` on `PATH`. `bin/longwait.wasm` is 44,010 bytes, sha256 `70ae2adfb46864fad3af0241fe26f401a62a5176ccd25ab82fe6588178cfb5c8`.
+**Build:** `WASIX_SYSROOT_28=/path/to/wasix-sysroot ./build.sh`, with `wasixcc` 0.4.7 and binaryen's `wasm-opt` on `PATH`. `bin/longwait.wasm` is 44,004 bytes, sha256 `e69d03f01479693666078297e781f5373719700c8534d1f2933749f5b3cee903`.
 
 ### `epollmask`