feat(site): "Symbian Wanted a Frame Function" — PocketJS on a Nokia E7 - #196
Merged
Conversation
The Symbian/Nokia E7 port writeup: what the active-object model is and why a one-frame-function runtime already fits it, pinning a 2011 GCCE/Qt toolchain to Debian snapshots, the live viewport that survives rotation without remounting, the day the port ran under 1 fps because nothing had asked the GPU, and the physical scan-code matrix behind WASD. Screenshots are the real Symbian guest bundles resolved against the E7 build profile and booted at 640x360 / 360x640 against the wasm core the pixel goldens use; the OpenStrike frame is labelled as the PSP build, which is the only capture we have of it. Also loads c/cpp into the Shiki language set — both were falling back to unhighlighted plain text, including the five existing ```c blocks. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The Nokia E7 / Symbian Belle port writeup, for pocketjs.dev/blog/pocketjs-on-symbian/. Covers what Symbian's active-object model actually is (with a full
CActivenext to itsasync/awaitequivalent), the 2011 GCCE/Qt toolchain pinned to Debian snapshots, per-app UIDs and the launcher catalog, the live viewport that survives rotation without remounting, the GLES2 backend that took the port from under 1 fps to fluid, the native extension ABI behind OpenStrike, and the physical scan-code matrix behind WASD.Sources: pocketjs #176, #183, #185, #186, #187, #188, plus open-strike #14 and pocket-figma #4/#5.
Contents
site/content/blog/pocketjs-on-symbian.md— the post: 8 inline SVG diagrams, 3 code blocks, 1 mapping tablesite/assets/blog/symbian-e7-*.png— 7 screenshotssite/nav.ts— blog registry entrysite/home.html— hero "New" ribbon retargeted (it was two posts stale, still pointing at Pocket Character);Symbianadded to the target chips as in progress, matching the post's boundary section and the privatesymbian-e7-devprofilesite/build.ts— loadc/cppinto the Shiki language set; both were silently falling back to unhighlighted plain text, which also affected the five existing ```c blocks in other postsScreenshot provenance
Every application screenshot is the real Symbian guest bundle — resolved against the E7 build profile, built with
--plan=, and booted at the E7's exact viewport (640x360/360x640) against the same wasm coretests/golden.tsuses. Captions say so. The OpenStrike frame is the existing PSP capture and is labelled as such in its caption, because no E7 capture of it exists.Validation
bunx tsc --noEmitbun run test— 450 passed, 0 failedbun tests/golden.tsfrom a cleaneddist/— 49/49bun run tape:check— 180/180bun run site:build— 11 posts, no warnings<svg>blocks, 9/9 images loaded, 3/3 code blocks highlighted and none horizontally scrolling, no page or console errors, no horizontal page overflow<text>in every diagram measured against its enclosing<rect>and the viewBox — no overflowNotes
A blank line inside an inline
<svg>ends the HTML block in Markdown; if the next line is not a lone tag,markedwraps it in<p>, which makes the HTML parser close the<svg>and dump the rest of the diagram into the page as prose. Every diagram here is blank-line free. Existing posts with blank lines inside SVGs (ui-runtime-that-cant-flake.md) are unaffected — their next lines are lone<rect …/>tags, which restart the block.🤖 Generated with Claude Code