Loka 0.0.5

Loka v0.0.5

Core hardened, then a runtime on top: the allocation-zero update path (hole B), the paint-damage ledger (#518 rally 2), the write-seat state family, and SmirkyCard, an experimental HyperCard-style example whose cards are written in JavaScript with the same names as Loka's C++ node DSL, loaded from a MAIN.JS beside the application and reloadable without relaunch.

Highlights

• SmirkyCard (experimental): QuickJS-ng on every rail including Classic 68K. Cards are JS classes (card('first', class { … compose() { return VStack(…) } })), state seats via state(), Reload MAIN.JS re-reads the file with engine generations so a broken file never replaces a working card. Runs on a PowerBook 180c (68030, 8 MB) and in Infinite Mac's Macintosh Plus configuration (68000, 4 MB, System 7.1; browser emulation, speed not claimed).
• Allocation-free update cycle (hole B): the pool allocator is the main line; MineSweeper mount 7.7 s → 0.6 s and LazyList cold 18 s → 1.4 s on the MAME rig.
• Paint damage ledger (#518 rally 2): descriptors, exact damage answers, Win32 damage translation.
• Write seats: WriteSeat<T> replaces raw MutableState* in control props; the transaction-owning Boundary is the only writer.
• macOS UB1 (Tiger, ppc + i386) ships for the first time beside the UB2 (arm64 + x86_64) archive; Classic ships 68K + PPC MacBinaries with ScrapbookUI's package beside its binaries.

Archives

• Loka-v0.0.5-classic.zip — 68K and PPC MacBinary applications, ScrapbookUI with ASSETS.LRP, experimental/SmirkyCard/ (68K bin + MAIN.JS).
• Loka-v0.0.5-macos-ub2.zip — five standalone presentation loops + SimpleViewer, arm64 + x86_64.
• Loka-v0.0.5-macos-ub1-tiger.zip — the same six as ppc + i386 universal binaries built with Xcode 3.2.6 / GCC 4.0 against the 10.4u SDK (build-verified; no Tiger/Leopard runtime claim).
  Each archive has a .manifest.txt beside it (tag, commit, allowlist hash, per-file SHA-256, build commands).

Verified at the release candidate

Classic MAME maciix 24/24 cells (bake + confirm); macOS Tahoe 26.7 16/16 (stage + verify, audits 16/16); Win32 VM 16/16 (bake + verify); Linux/macOS/Windows/Toolbox CI green; PowerBook 180c hands-on (all examples + SmirkyCard); Mavericks 10.9 flow run and Tiger UB1 stage; MacBook Neo (macOS 27.0) tests 9/9 and audits 16/16 as a reference rail.

Known issues

• #496 Win32 MineSweeper settles with the bottom rows unpainted on bare metal (omen 11/20, Zenbook SORA 3/10); the VM rig never shows it. Cells blocked; root cause on the #518 rally-3 track.
• #580 ScrollView is vertical-only; SimpleViewer's actual-size mode clips wide images.
• #490 Classic Standalone Loop applications share LOG.TXT if flattened into one folder (keep one folder per app; the .dsk images are separate volumes).
• #503 stale frame when backgrounded; #501 audit flush cadence on 68030; #725/#727 Win32 white window contained.
• LazyList is a measurement bench and feels slow on a real 68030.
• SmirkyCard: state is not carried across reload; 8 seats per card; two named cards; MAIN.JS must be UTF-8 (Classic editors: see README).

Environment notes

macOS reference rig moved to Tahoe 26.7 (25G229). The -Werror legacy legs (Mavericks GCC 4.0) caught two C++98 nested-access shapes (#795, #797) that modern compilers accept.

Screenshots

Known issue found after publishing

macOS UB2 note (#803): the standalone loop applications refuse to start when launched straight from the unzipped download. macOS quarantines the folder and runs the app read-only (App Translocation), so the loop cannot write its LOG.TXT beside itself and exits without a window. Move the applications out of the download folder with the Finder, or run xattr -dr com.apple.quarantine <App>.app. SimpleViewer is unaffected. A visible refusal and a README note are on the 0.0.6 track.