From 415f77e24289cf0cb52d99116d485bf2ea582ccc Mon Sep 17 00:00:00 2001 From: Orkuncakilkaya Date: Thu, 27 Aug 2026 18:52:40 +0300 Subject: [PATCH] Phase 6b (cont.): fix ECS-construct 'system'->'handler' in COMPILING/BOOTSTRAP prose Co-Authored-By: Claude Opus 4.8 --- COMPILING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/COMPILING.md b/COMPILING.md index 567487f8..312f95e1 100644 --- a/COMPILING.md +++ b/COMPILING.md @@ -216,7 +216,7 @@ python3 -m http.server -d build/web 8000 # then open http://localhost:8000/ itch.io — and the game runs. It needs no server-side anything, and no cross-origin isolation headers. -**No game logic passes through JavaScript.** The systems, the queries, the +**No game logic passes through JavaScript.** The handlers, the queries, the fixed-point arithmetic, the PNG decoder, the TrueType rasteriser and the UI are all compiled Ludic executing as wasm. `platform.js` is 300 lines and implements the same five-function window protocol `cocoa.ll` implements, plus the host @@ -248,7 +248,7 @@ A browser tab cannot be held inside that loop — it would never paint, and the key events the loop is waiting on would never be delivered. So a web build exports those four functions instead of `main`, and `platform.js` calls `ludic_frame` from `requestAnimationFrame`. Both targets emit the four from the -same code in `ll_emit_loop_parts`, so the systems that run, and the phase order +same code in `ll_emit_loop_parts`, so the handlers that run, and the phase order they run in, are identical; only the owner of the loop differs. ### The floor