@ai-ecoverse/slicc-kernel 1.138.1 → 1.139.1

package/README.md

@@ -402,6 +402,7 @@ The module's default export (or its `main` export) is called with a context and
   - **Only the named descriptors reach the child.** Others the program holds, the other end of a pair included, don't, and a grandchild gets fd 3 only if the child names it again.
   - **The parent's copy:** the program keeps `f` and closes it itself when it no longer needs it, so the child sees end of file once it's the only one left.
   - **Why a `Record`:** it can't name a child fd twice, and it reads like Node's `stdio` index, so it's this rather than a list of `{ fd, from }`.
+- `memory()`, synchronous and without a kernel call, measures the calling isolate: each `thread` answers for its own (#1240, slicc-jsh#397). It returns a fresh plain object of numbers in bytes, each field only where it's measured: `heapUsed`, `heapTotal`, `heapLimit` (V8's heap size limit), `external` and `arrayBuffers`. On the Node entry they come from V8's heap statistics and Node's memory usage, through functions the worker captured before its lockdown, so nothing reachable from the program leads back to `process` or `v8`; there is no `rss`, which is the whole host's. In a browser `memory()` answers `{}` for now.
 - **`thread`, kernel threads of the same process** ([#1094](https://github.com/ai-ecoverse/slicc-kernel/issues/1094)), the base for Node's `worker_threads` (tinypool, piscina, vitest's and jest's thread pools, eslint's concurrency). `thread.spawn({ data, transfer })` resolves with `{ tid, port, exited, terminate() }`.
   - **What a thread is:** a new process worker in the **same process**. It has the same pid, descriptor table, cwd, umask, credentials and lockdown, and a sync lane of its own, so `sync` calls in one thread don't hold another.
   - **What it runs:** the program's same default export, called with a context whose `thread` is `{ tid, port, data }`. In the main thread `thread.tid` is `0` and `thread.port` is `undefined`. Threads are numbered from 1 per process, and a thread can spawn threads too.
@@ -1234,7 +1235,7 @@ Releases are cut by semantic-release on every push to `main`, in two jobs, and o
 
 Every change is certified in its pull request, before it merges (`cert-review-pr.yml`, next section), and `cert-review` is a required check of the merge queue, so every commit on `main`, and every release built from it, was certified first. A release is then **verified on npm** (`release / verify on npm` in `release.yml`, `tools/cert-review/verify.mjs`), in code, for every tag the run made:
 
-- It waits up to an hour for npm to serve the version (an accepted publish can take a while to appear; 1.125.4 took 55 min). `release-recover` logs `npm publish`'s own output every time, and says PASS for a version it published only once npm serves it (the tarball answers) with `dist.integrity` equal to the tarball it packed; the reference is the `integrity` of `npm publish --json`'s own report, the bytes npm uploaded (a separate pack isn't byte-identical; 1.136.1 was served fine and still read as not served), and it publishes from the folder, never a tarball, so the packument keeps `gitHead`; an exit 0 without a report fails, and a version npm says is already published has no report, so it's only checked for being served; a version npm took but doesn't serve so after 25 min is `release-recover: INCOMPLETE`, and the publish job fails (#1228: 1.134.2 was taken, never served, and still read as PASS). A version semantic-release itself just published is handed to this job instead. A version npm still doesn't serve after the hour, and doesn't list, while a newer one of ours is its `latest`, ends with `verify: SKIPPED <name>@<version>: never served by npm; superseded by <latest>` (the gate takes SKIPPED like PASS); only after the whole wait, since a slow version can appear late and must not go unverified. SKIPPED writes no certified line, so nothing downstream reads it as certified; if npm serves a skipped version later, the coordinator's merge watchdog notes it within 10 min (any version that appears below npm's `latest`), and the coordinator re-runs `release / verify on npm` in that version's Release run for the normal verdict, the certified line or the supply-chain alert. One npm still doesn't serve, with nothing newer or a version list it can't read, is a "not served yet, re-run" failure, never a supply-chain alert. It then downloads the tarball and checks `dist.integrity` (sha512), the SLSA v1 provenance (the tarball's sha512 is its subject; `release.yml` on `refs/heads/main`, a GitHub-hosted builder; `gitCommit` = `gitHead` = the tag, on `main`), and `npm audit signatures`. npm serves a version's attestations a little after the version itself, so a 404 from the attestations, a missing `dist.attestations`, an `npm view` or network error while looking for them, or `npm audit signatures`' E404 on them, is retried within the same hour: it's a supply-chain alert only once the version has been served for 30 min, its packument has stopped changing for 10, and the attestations still answer 404, or the hour has run out. Any other status, or attestations that don't match, fail at once. A version that `release-recover.mjs` skipped because npm's `latest` is newer (#837) has nothing to verify.
+- It waits up to an hour for npm to serve the version (an accepted publish can take a while to appear; 1.125.4 took 55 min). `release-recover` publishes a version it has to recover with a plain `npm publish --provenance` from the folder (so the packument keeps `gitHead`) and logs npm's own exit code and output; it fails only on npm's own non-zero exit, and npm's "cannot publish over the previously published version" on a re-run counts as already done. Whether npm serves the version is this job's to check. A version npm still doesn't serve after the hour, and doesn't list, while a newer one of ours is its `latest`, ends with `verify: SKIPPED <name>@<version>: never served by npm; superseded by <latest>` (the gate takes SKIPPED like PASS); only after the whole wait, since a slow version can appear late and must not go unverified. SKIPPED writes no certified line, so nothing downstream reads it as certified; if npm serves a skipped version later, the coordinator's merge watchdog notes it within 10 min (any version that appears below npm's `latest`), and the coordinator re-runs `release / verify on npm` in that version's Release run for the normal verdict, the certified line or the supply-chain alert. One npm still doesn't serve, with nothing newer or a version list it can't read, is a "not served yet, re-run" failure, never a supply-chain alert. It then downloads the tarball and checks `dist.integrity` (sha512), the SLSA v1 provenance (the tarball's sha512 is its subject; `release.yml` on `refs/heads/main`, a GitHub-hosted builder; `gitCommit` = `gitHead` = the tag, on `main`), and `npm audit signatures`. npm serves a version's attestations a little after the version itself, so a 404 from the attestations, a missing `dist.attestations`, an `npm view` or network error while looking for them, or `npm audit signatures`' E404 on them, is retried within the same hour: it's a supply-chain alert only once the version has been served for 30 min, its packument has stopped changing for 10, and the attestations still answer 404, or the hour has run out. Any other status, or attestations that don't match, fail at once. A version that `release-recover.mjs` skipped because npm's `latest` is newer (#837) has nothing to verify.
 - It then writes `certified @ai-ecoverse/slicc-kernel@<v> sha256=<64 hex> (covers <first>–<v>; ci: <run>; pr-certified: <each merged pull request's cert-review at its merge>; known: <open known-issue issues>)` into the GitHub release's notes, between `<!-- cert-verify -->` markers. homescoop's ci reads exactly that prefix and re-hashes the npm tarball against it. `covers` starts after the last version npm serves, so a skipped version is covered by the next. Notes that already carry the identical line stay unchanged. A pull request's `cert-review` is the newest finished one (success, failure or error) on its head at or before its merge, or the newest pending one if none had finished. A re-review that a later `ready_for_review`, `reopened` or `cert-review-approved` event starts on the same head, still pending at the merge or ending after it, doesn't change what the merge queue saw, and a status posted after the merge can't change a release's line.
 - A mismatch writes no line. The job is red with a `supply-chain alert`, and so is a line already in the notes with another sha256.
 

package/dist/kernel-worker.js

@@ -7125,7 +7125,7 @@ function satisfies(version, range2) {
 }
 
 // src/version.ts
-var KERNEL_VERSION = true ? "1.138.1" : "0.0.0-dev";
+var KERNEL_VERSION = true ? "1.139.1" : "0.0.0-dev";
 var OS_RELEASE = "6.0.0-slicc";
 function procVersion() {
   return `Linux version ${OS_RELEASE} (slicc-kernel ${KERNEL_VERSION}) #1 SMP PREEMPT_DYNAMIC

package/dist/node-driver-worker.js

@@ -1390,6 +1390,10 @@ function refused(specifier) {
     code: "ERR_ACCESS_DENIED"
   });
 }
+var BASE64_MODULE = "data:text/javascript;base64,";
+var fromBase64 = Buffer.from.bind(Buffer);
+var toText = Function.prototype.call.bind(Buffer.prototype.toString);
+var PLAIN_BASE64 = /^[A-Za-z0-9+/]+={0,2}$/;
 function refuseModules() {
   registerHooks({
     resolve(specifier, context, next) {
@@ -1397,11 +1401,18 @@ function refuseModules() {
       const resolved = next(specifier, context);
       if (!resolved.url.startsWith("data:")) throw refused(resolved.url);
       return resolved;
+    },
+    load(url, context, next) {
+      const payload = url.startsWith(BASE64_MODULE) ? url.slice(BASE64_MODULE.length) : "";
+      if (payload.length % 4 !== 0 || !PLAIN_BASE64.test(payload)) return next(url, context);
+      const source = toText(fromBase64(payload, "base64"), "utf8");
+      return { format: "module", source, shortCircuit: true };
     }
   });
 }
 var locked = /* @__PURE__ */ new WeakSet();
 var nodeProcess = typeof globalThis.process === "object" && globalThis.process !== null ? globalThis.process : void 0;
+var memoryUsage = process.memoryUsage.bind(process);
 function nodeLockdown(scope = globalThis) {
   if (locked.has(scope)) return;
   locked.add(scope);