From 4df4de7f7969ed6c29de73d87e5e5925da2d659c Mon Sep 17 00:00:00 2001 From: giles Date: Sun, 28 Jun 2026 21:00:25 +0000 Subject: [PATCH] =?UTF-8?q?host:=20doc=20=E2=80=94=20SPA=20WASM=20bundle?= =?UTF-8?q?=20rebuild=20attempt=20failed=20(Char.chr=20crash),=20reverted?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 --- plans/host-spa.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/plans/host-spa.md b/plans/host-spa.md index c7533fd9..67d19698 100644 --- a/plans/host-spa.md +++ b/plans/host-spa.md @@ -43,6 +43,20 @@ graceful degradation to plain server-rendered pages with no JS. WASM kernel (sx.rose-ash.com avoids this because its Docker image ships a consistent bundle and it navigates via client-router page-routes, not boost). +## Rebuild attempt (2026-06-28) — FAILED, reverted + +Tried it: `dune build browser/sx_browser.bc.wasm.js` succeeded (with many +`integer-overflow` warnings — "generated code might be incorrect"), and +`node hosts/ocaml/browser/compile-modules.js shared/static/wasm` recompiled all +35 `.sxbc` cleanly. But the freshly-built kernel **crashes on init** in the +browser: `Fatal error: exception Invalid_argument("Char.chr")` — so `SxKernel` +never initialises (worse than before). The integer-overflow truncation during +wasm codegen is the likely culprit (a SHA/char constant). Reverted +`shared/static/wasm/` to the main-worktree bundle (which boots cleanly — +verified SxKernel + data-sx-ready). So a naive in-worktree rebuild is NOT the +fix; the wasm build itself needs investigating (wasm_of_ocaml version? the merged +sx-vm-extensions/resolver changes interacting with codegen?). + ## Next step — rebuild a consistent WASM bundle `scripts/sx-build-all.sh` does: build the browser wasm target → sync web `.sx`