basedpl 0.1.76__tar.gz → 0.1.78__tar.gz

{basedpl-0.1.76 → basedpl-0.1.78}/.github/workflows/ci.yml

@@ -18,7 +18,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     env:
       # The Python-free `bpl` goes in the wheel, through `cargo stage`, and in the GitHub release.
-      STAGE_BPL: cargo stage --profile dist && mkdir -p bin && cp wheel/scripts/bpl bin/${{ matrix.binary }}
+      STAGE_BPL: cargo stage --profile dist --no-default-features && mkdir -p bin && cp wheel/scripts/bpl bin/${{ matrix.binary }}
     steps:
       - uses: actions/checkout@v7
       - uses: dtolnay/rust-toolchain@stable
@@ -27,17 +27,15 @@ jobs:
         with:
           python-version: '3.12'
       - if: runner.os != 'Linux'
-        run: pip install 'fastws-cli>=0.0.25' && ${{ env.STAGE_BPL }}
+        run: pip install 'fastws-cli>=0.0.29' && ${{ env.STAGE_BPL }}
       - uses: PyO3/maturin-action@v1
         with:
           args: --profile dist --no-default-features --compression-level 9 --out dist -i python3.11 -i python3.12 -i python3.13
           manylinux: auto
           # This runs inside the manylinux container, whose old glibc lets the binary run on older Linux distributions.
-          before-script-linux: export PATH="/opt/python/cp311-cp311/bin:$PATH" && python3.11 -m pip install 'fastws-cli>=0.0.25' && ${{ env.STAGE_BPL }}
-      # The release build's own costs, for comparison with CI's. `basedpl.bpltests.logged_costs` reads this log. Timing never fails the release.
+          before-script-linux: export PATH="/opt/python/cp311-cp311/bin:$PATH" && python3.11 -m pip install 'fastws-cli>=0.0.29' && ${{ env.STAGE_BPL }}
       - name: Time the release build
         continue-on-error: true
-        timeout-minutes: 20
         run: bin/${{ matrix.binary }} --costs tests/speed
       - uses: actions/upload-artifact@v7
         with:

{basedpl-0.1.76 → basedpl-0.1.78}/.github/workflows/speed.yml

@@ -14,8 +14,8 @@ jobs:
       - uses: actions/setup-python@v7
         with:
           python-version: '3.12'
-      # This job times the `bpl` that releases ship, which `cargo stage --profile dist` builds, as the `Release` workflow does. `bpl --costs` prints every case's cost and budget for `basedpl.bpltests.logged_costs`. A case over its budget doesn't fail it. The job builds without a cache. The `Test` workflow's caches hold only test-profile builds.
-      - run: pip install 'fastws-cli>=0.0.25' && cargo stage --profile dist
+      # This job times the `bpl` that releases ship, which `cargo stage --profile dist --no-default-features` builds, as the `Release` workflow does. `bpl --costs` prints every case's cost and budget for `basedpl.bpltests.logged_costs`. A case over its budget doesn't fail it. The job builds without a cache. The `Test` workflow's caches hold only test-profile builds.
+      - run: pip install 'fastws-cli>=0.0.29' && cargo stage --profile dist --no-default-features
       - run: wheel/scripts/bpl --costs tests/speed
       # `bpl-tests thread_scaling` times a large product, a 512×512 SVD and Hermitian eigendecomposition, a stack of QR decompositions and a large elementwise function on one thread and on as many threads as the runner has physical cores, up to 4. It fails when a case reaches less than half its expected gain. Speed budgets are single-thread measurements, so this is the check of multithreaded speed. It comes last, so that a failure here still leaves every cost logged. `lscpu` shows whether the VM reports which vCPUs share a physical core, which is how `thread_scaling` counts cores on Linux.
       - run: lscpu
@@ -28,6 +28,10 @@ jobs:
       - uses: dtolnay/rust-toolchain@stable
         with:
           targets: wasm32-unknown-unknown
+      # These wasm costs come from the V8 of the Node that `.node-version` pins, as in the `Test` workflow's `wasm` job.
+      - uses: actions/setup-node@v7
+        with:
+          node-version-file: .node-version
       - run: cargo generate-lockfile
       - uses: Swatinem/rust-cache@v2
         with:

{basedpl-0.1.76 → basedpl-0.1.78}/.github/workflows/test.yml

@@ -9,6 +9,7 @@ permissions:
   contents: read
 
 # In each job, every test step after the first runs even when an earlier step fails, to report every test's result in one run.
+# A build step that runs past 10 minutes has stalled. These builds normally take about 3.
 jobs:
   test:
     runs-on: ubicloud-standard-4-ubuntu-2604
@@ -47,6 +48,10 @@ jobs:
       - uses: dtolnay/rust-toolchain@stable
         with:
           targets: wasm32-unknown-unknown
+      # V8's frame sizes decide the recursion test's margin. Each Node major keeps one V8 version. `.node-version` pins the major that both wasm jobs use.
+      - uses: actions/setup-node@v7
+        with:
+          node-version-file: .node-version
       - run: cargo generate-lockfile
       # The `Speed` workflow's `wasm` job restores this cache, by its `shared-key`.
       - uses: Swatinem/rust-cache@v2

basedpl-0.1.78/.node-version

@@ -0,0 +1 @@
+26

{basedpl-0.1.76 → basedpl-0.1.78}/CONTRIBUTING.md

@@ -27,7 +27,7 @@ ship-rs-build
 
 After Rust changes, run `cargo test` for the Rust tests, then `cargo develop` to install what `cargo test` built: the extension, and the native `bpl` command in your environment. Both use one compilation of each crate. `cargo develop` comes from `fastws-cli`, one of the development tools. Run `pip install -e '.[dev]'` again only when the package metadata changes. Use `cargo fastfmt`, not `cargo fmt`.
 
-Before a release, run `python scripts/prep.py` from the repository root. It writes the syntax highlighters' glyph lists and the macOS keyboard layout bundle. It then runs nbdev's `prepare` to export, test and clean the notebooks and render this README.
+Before a release, run `bpl-tests prerelease` from the repository root. Among its steps, it writes the syntax highlighters' glyph lists and the macOS keyboard layout bundle, saves the notebooks' outputs, and runs nbdev's `prepare` to export, test and clean the notebooks and render the README. DEV.md's "Release" section lists every step.
 
 ## Did you find a bug?
 

{basedpl-0.1.76 → basedpl-0.1.78}/Cargo.lock

@@ -99,7 +99,7 @@ checksum = "ac07cdecf99051d9a5238b80f35af32cdeba5b336e55d957b318b50137e18da5"
 
 [[package]]
 name = "basedpl"
-version = "0.1.76"
+version = "0.1.78"
 dependencies = [
  "base64 0.23.1",
  "bytemuck",
@@ -148,7 +148,7 @@ dependencies = [
 
 [[package]]
 name = "basedpl-cli"
-version = "0.1.76"
+version = "0.1.78"
 dependencies = [
  "async-trait",
  "basedpl",
@@ -162,14 +162,17 @@ dependencies = [
 
 [[package]]
 name = "basedpl-py"
-version = "0.1.76"
+version = "0.1.78"
 dependencies = [
  "basedpl",
+ "ctrlc",
+ "kernmini",
  "num-bigint",
  "num-complex",
  "num-rational",
  "pyo3",
  "pyo3-build-config",
+ "rustyline",
  "rustymath",
  "rustymath-buffer",
  "serde_json",
@@ -177,7 +180,7 @@ dependencies = [
 
 [[package]]
 name = "basedpl-wasm"
-version = "0.1.76"
+version = "0.1.78"
 dependencies = [
  "basedpl",
  "js-sys",
@@ -1680,9 +1683,9 @@ dependencies = [
 
 [[package]]
 name = "rustymath"
-version = "0.1.51"
+version = "0.1.52"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "4de1a9a4c9e23e3f6ed6b6cf156a1629e9afd9f24d14150b4faeebc7198444b9"
+checksum = "9eb8e5ce5edc62d2314664c772662b48992258f6a42ea076053f2169b229c45e"
 dependencies = [
  "foldhash",
  "half",
@@ -1701,9 +1704,9 @@ dependencies = [
 
 [[package]]
 name = "rustymath-buffer"
-version = "0.1.51"
+version = "0.1.52"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "12681be376d5e5fc653fbf274098ed58ea04e3e4413931e2844f8b2a0a5b451a"
+checksum = "45f92e085b223eb9048ad95befcff11b849d4fa728d2dd31eb6ca76fc7c4390a"
 dependencies = [
  "pyo3",
  "rustymath",
@@ -2057,9 +2060,9 @@ checksum = "c6f5d3c3b1bf09027a88a6bc961fc00497d651009560b5463668dc81b0fa87a8"
 
 [[package]]
 name = "unicode-width"
-version = "0.2.2"
+version = "0.2.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "b4ac048d71ede7ee76d585517add45da530660ef4390e49b098733c6e897f254"
+checksum = "ca718471876992059f251e33aafc334346ada08042b7661dd1fe313a9bced557"
 
 [[package]]
 name = "utf16_iter"
@@ -2447,7 +2450,7 @@ checksum = "3ad82d2a33cdc9674dc7465672f271e096168fcdbe0f799d9e6db8c5892679dc"
 
 [[package]]
 name = "xtask"
-version = "0.1.76"
+version = "0.1.78"
 dependencies = [
  "anyhow",
  "rustymath",

{basedpl-0.1.76 → basedpl-0.1.78}/Cargo.toml

@@ -5,16 +5,20 @@ members = ["py"]
 join_comments = true
 
 [workspace.package]
-version = "0.1.76"
+version = "0.1.78"
 edition = "2024"
 rust-version = "1.98"
 license = "Apache-2.0"
 
 [workspace.dependencies]
-rustymath = { version = ">=0.1.51, <1", default-features = false }
-rustymath-buffer = ">=0.1.51, <1"
+rustymath = { version = ">=0.1.52, <1", default-features = false }
+rustymath-buffer = ">=0.1.52, <1"
 pyo3 = ">=0.29.2, <1"
 pyo3-build-config = ">=0.29.2, <1"
+ctrlc = ">=3.5.2, <4"
+kernmini = ">=0.1.22, <1"
+# Custom bindings override Emacs Alt-digit prefixes in this fork.
+rustyline = { git = "https://github.com/AnswerDotAI/rustyline.git", branch = "master", default-features = false, features = ["custom-bindings", "with-file-history"] }
 
 [package]
 name = "basedpl"

{basedpl-0.1.76 → basedpl-0.1.78}/DEV.md

@@ -58,6 +58,8 @@ pytest -q
 
 Use `cargo develop` to rebuild and install the native extension and `bpl` after Rust changes. It uses the `test` profile shared with `cargo test`. Cargo tests compile missing code but don't install it. Run plain `cargo test` while you work; use one test binary for a focused check. From a kernel, `fastws.cargo.run_tests(root, *args)` runs `cargo test` and returns the build's compiler messages and each test binary's results. Run `pytest -q` at the end of a piece of work. Before you report a `pytest` failure in code you didn't touch, run `cargo develop` and rerun it. Give builds three minutes and test runs one minute; Cargo serializes builds in the same target directory.
 
+Before a stage's closing review and before a release, run the full checks: what CI runs, and the builds for the targets that this Mac's daily builds leave out. Run `cargo develop`, `cargo test`, `pytest -q`, `bpl-nb`, `nbdev-test`, `node tests/input.mjs` and `node tests/highlighting.mjs`. Then run `bpl-tests target_builds /tmp/<prefix>_wasm`, followed by `wasm_test(DIR)` and `wasm_test(DIR, speed=True)` on that directory. `target_builds` builds basedpl's and rustymath's libraries for Linux x86-64 and the browser package at once. "Codegen and rebuilds" says how to find the function that holds up a build that stays on one core for minutes.
+
 Build nothing else without discussion: no scratch crates, alternate target directories, `--release`, `-p` or other-target builds. The documented build diagnostics, browser work and x86-64 inspection below are exceptions. Don't use `maturin develop`; its configuration does not reuse the normal local build.
 
 When another agent's unfinished edits stop the shared tree compiling, run `cargo wait` with the Bash tool's `run_in_background`, then build after it exits. `cargo wait` comes from `fastws-cli`, as `cargo develop` does. It runs `cargo check` on every target of the workspace each time a source file or manifest of a local package changes, rustymath's included. It exits once the tree compiles, or after 30 minutes with the remaining errors. `cargo wait --path ~/aai-ws/rustymath` waits for rustymath's own workspace, its Python extension included. Use it rather than writing a wait loop.
@@ -122,11 +124,11 @@ Rust 1.98 or later supplies algebraic float operations. `test` inherits `release
 
 `fastws`'s `cargo develop` builds profile `test`, installs the extension and stages `bpl` into the venv. `py/` enables PyO3's `extension-module` and supplies its link arguments without libpython. Editable installs use `fastws.build_backend`; they install metadata and a path to `python/` without compiling Rust. After a standalone `uv sync` or editable pip install, run `cargo develop`. `ws-sync` performs that rebuild after syncing. Wheels use maturin for the extension and `cargo stage` for the Python-free CLI. Linux staging runs inside the manylinux container.
 
-Basedpl's crates pass on rustymath's default `native` feature, which rustymath's DEV.md describes. Each depends on the crate below it with `default-features = false` and makes `native` its own default. The release job builds wheels with `--no-default-features`. `cargo stage` always builds without default features. The released Mac builds therefore leave out rustymath's own linear algebra. On Apple targets, `flate2` uses the system zlib. Other targets keep its Rust backend, `miniz_oxide`.
+Basedpl's crates pass on rustymath's default `native` feature, which rustymath's DEV.md describes. Each depends on the crate below it with `default-features = false` and makes `native` its own default. Release staging and wheel builds both pass `--no-default-features`. The released Mac builds therefore leave out rustymath's own linear algebra. The Python binding inherits the CLI's pure-Rust frontend dependencies to keep shared dependency features identical for release builds. On Apple targets, `flate2` uses the system zlib. Other targets keep its Rust backend, `miniz_oxide`.
 
 Use published dependency ranges with the lower bounds required by the APIs in use. `Cargo.toml` names a published rustymath range; the `~/aai-ws` Cargo patch selects the sibling checkout locally. CI resolves published crates. Release rustymath changes before relying on them in basedpl CI. Don't edit fastws-generated Cargo patches, `.git/fastws-cargo-key` or workspace configuration, and don't commit the workspace-generated `Cargo.lock`. `meta/` is ignored planning material, not contributor documentation. `[tool.uv] cache-keys` tracks packaging manifests, not Rust sources.
 
-`Test` runs native and wasm jobs on pushes to main and pull requests. Native CI runs `cargo test`, editable installation, `cargo develop`, pytest, `bpl-nb` and `nbdev-test`. Python tests use the same test-profile build. The wasm job builds with `cargo wasm --strip` and runs both Node suites. Both jobs use `ubicloud-standard-4`; speed budgets are set for that runner. They generate a lockfile before restoring `Swatinem/rust-cache`, making dependency changes part of the cache key. `Speed` is manually triggered. Its `wasm` job restores the `Test` workflow's wasm cache. Its native job builds the `dist` profile without one.
+`Test` runs native and wasm jobs on pushes to main and pull requests. Native CI runs `cargo test`, editable installation, `cargo develop`, pytest, `bpl-nb` and `nbdev-test`. Python tests use the same test-profile build. The wasm job builds with `cargo wasm --strip` and runs both Node suites. Both jobs run on `ubicloud-standard-4-ubuntu-2604`, which is Ubuntu 26.04 on the `ubicloud-standard-4` VM size that speed budgets are set for. A build step that runs past 10 minutes fails. These steps normally take about 3. They generate a lockfile before restoring `Swatinem/rust-cache`, making dependency changes part of the cache key. `Speed` is manually triggered. Its `wasm` job restores the `Test` workflow's wasm cache. Its native job builds the `dist` profile without one.
 
 `Release` runs separately on `v*` tags on GitHub's runners. It builds dist wheels, sdist, standalone CLI artifacts and the Windows keyboard archive, then publishes Python artifacts and the GitHub release. Its npm job publishes the stripped browser package through trusted publishing and purges jsDelivr's package files to avoid stale unversioned URLs. Release neither runs tests nor waits for the Test workflow.
 
@@ -140,6 +142,8 @@ Generic loop instances can concentrate in the defining module's codegen unit. A
 
 Use `cargo build --lib --bins --profile test --timings` to inspect the normal build. Its report under `target/cargo-timings/` separates frontend and codegen time. `BASEDPL_UNITS=1 cargo test --test units -- --nocapture` lists large units and their functions. `BASEDPL_SIZES=pattern cargo test --test units -- --nocapture` measures machine code matching a demangled-name regex. `BASEDPL_SIZES` sees only basedpl's own codegen units. `BASEDPL_SIZES_DIFF=old:new cargo test --test units machine_code_growth -- --nocapture` compares two binaries, such as copies of `bpl` from before and after a change, by generic function across every crate. `BASEDPL_CALLS=pattern cargo test --test units -- --nocapture` lists each call from a function whose demangled name matches to a function in another codegen unit, in basedpl's build and in the rustymath rlib it links. Those calls stayed out of line through thin LTO. rustymath's DEV.md says which calls do, under "Loops and codegen". After an edit, `BASEDPL_RECOMPILED=pattern cargo test --test units -- --nocapture` lists the units that the rebuild compiled again, each with its biggest functions whose demangled names match. These commands diagnose the current compilation arrangement; don't create scratch builds to approximate it.
 
+A build that stays on one core for minutes is usually waiting on one function that an LLVM pass takes minutes over. LLVM's loop vectorizer chooses each loop's vector width and interleave count from the target's cost model. A loop that it vectorizes in seconds for arm64 can take it minutes for x86-64. On macOS, `sample <pid> 5 -file /tmp/<prefix>_sample.txt` on the busy `rustc` shows the pass, such as `LoopVectorizePass` unrolling a loop by its interleave factor (`VPlanTransforms::unrollByUF`). The nightly toolchain names the function. `cargo +nightly rustc -p CRATE --lib --release --target x86_64-unknown-linux-gnu --target-dir /tmp/<prefix>_x86 --config 'build.rustc-wrapper=""' -- -Z llvm-time-trace` writes LLVM's time for each pass on each function to `CRATE-<hash>.llvm_timings.json` under the target directory. With sccache on, a cached crate writes no trace. A crate with C code also needs `CC_x86_64_unknown_linux_gnu=clang`. `rg -o '"dur":[0-9]{8,},"name":"[^"]*"(,"args":\{"detail":"[^"]*"\})?' FILE` lists the passes that took 100 s or more, with each function's mangled name. One crate's trace can be gigabytes. `cargo llvm-lines -p rustymath --lib --release --target x86_64-unknown-linux-gnu` lists each function's lines of unoptimized LLVM IR, with its copies. It shows where generic instances multiply, but not what LLVM does after inlining. `cargo wasm` builds `xtask` for the host, rustymath included. On CI's x86-64 runner, the wasm job therefore waits on any stall in rustymath's x86-64 build. After a change to inlining or to loops, time an x86-64 build of the crate. rustymath's DEV.md, under "Build time and code size", gives the command and describes the stall found in October 2026.
+
 ## Code map
 
 | Files | Responsibility |
@@ -323,6 +327,8 @@ Browser `Session.run` streams MIME events and returns a protocol error or null.
 
 The playground and gallery load released assets from jsDelivr, or local `nbs/playground/` assets on localhost. Shared `bpl.js` owns editors, worker startup and output. Restarting a trapped/stopped worker loses its state. `worker.js`, `page.js` and `gallery.js` own their respective protocols/UI; `nbs/driver.js` documents canvas drawing data. Gallery demos are `.bpl` sources with shared preferences, checked natively by `language_examples`. Browser recursion tests cover both V8 compilers and fail with LIMIT before stack exhaustion.
 
+CI's two `wasm` jobs, in the `Test` and `Speed` workflows, take Node's version from `.node-version`. TurboFan's frame sizes vary between V8 versions by enough to decide whether a recursion test overflows. On 28 October 2026, one build's `each` shape needed 0.68 MB of stack to reach 171 levels under Node 24's TurboFan, against 0.62 MB under Node 26's. `tests/wasm.mjs` runs its depth checks with Node's 192 KB reserve plus 80% of the roughly 470 KB that a Chrome worker gives, 0.5575 MB in all. A build whose frames grow into the remaining 20% fails the test. In wasm, `Binder::reduce` and `Bindings::enter` stay out of line, to keep their locals out of the frames that stay on the stack at every level of recursion. To find a frame that grew, print each function's TurboFan frame size, in "stack slots", with `node --no-liftoff --print-wasm-code-function-index=N`. Measure with the test's own sequence in a fresh worker: code compiled once and shared across workers gets different frames.
+
 ## System functions and rendering
 
 `system.rs` owns the system table: one `SystemFunction` for each system function, holding its case-insensitive name, call, valence, extension, result prototype and inverse. Its extension (`primitive::Extension`) is the field that each primitive's form holds too. A system function takes its right argument whole, or takes items (`primitive::Item`) and maps over a right argument that holds several, with its left argument whole for each. A function that takes text also maps over each row of a character matrix, as `⍎` does. A function that acts asks the running levels where it acts (`Context::acts`), as output and input do: where it reads or writes files, the network, the clock or the terminal, or makes something new on each call, as `•index` and `•rand` do. Any other system function asks nothing, and a batched run calls it once for each cell. The parser resolves a known system name to its table entry (`system::Entry`) through `Builtin::find`, which finds a glyph's primitive too, and `primitive::Builtin` holds either. A system name is therefore a `NodeKind::Function` node, compiles to a constant and resolves to the function that one process-wide table holds for each builtin (`Builtin::function`), as a glyph does. An unknown system name stays a `NodeKind::System` node, which is a VALUE error when evaluated. Code identifies a table function by the `Entry` that its `SystemFunction` records, as in `Entry::PREFS`, never by its name. A function that a factory made, such as `•element "div"`, has no entry, although it shares its factory's name. Native records use ordinary function nodes and calls. Empty native item mapping returns its declared prototype without calling the function. `data::Options` is the shared keyed-option decoder; formats don't invent separate option parsers.
@@ -356,9 +362,9 @@ nbdev-test nbs/dyalog.ipynb --flags dyalog
 nbdev-preview
 ```
 
-Quarto renders saved outputs. `bpl-nb --save` updates notebook outputs without changing execution counts. Use it for BPL examples/figures and `nbdev-test` for Python notebook code. Rust `language_examples` checks BPL page/gallery examples; pytest checks Python page examples. Use `BASEDPL_PAGE` to focus page checks. Don't run a full documentation build for routine output updates. Release preparation runs `scripts/prep.py` after `cargo develop`; it calls editor generation and nbdev's export/test/clean/README preparation.
+Quarto renders saved outputs. `bpl-nb --save` updates notebook outputs without changing execution counts. Use it for BPL examples/figures and `nbdev-test` for Python notebook code. Rust `language_examples` checks BPL page/gallery examples; pytest checks Python page examples. Use `BASEDPL_PAGE` to focus page checks. Don't run a full documentation build for routine output updates. Before a release, `bpl-tests prerelease` runs editor generation and nbdev's preparation, as "Release" describes.
 
-`basedpl.editors.write()` generates syntax grammars/highlighters, editor templates, keyboard sources/bundles and glyph metadata from shared Rust symbols and keyboard data. It also writes JetBrains assets and Windows `editors/windows/layout.h`. After a Rust change, run `python -m basedpl.editors` from the shell, because a running kernel keeps its old extension. `layout.json` owns composed input; captured `keyboards.json` supports generation without macOS. `basedpl.keyboards.capture()` refreshes native data when needed, and `keyboards.write()` generates regional macOS bundles/maps. Regenerate keyboard sources through these functions, not one-off kernel code. `basedpl-install` copies packaged fonts and macOS bundles from `python/basedpl/assets` to the user's directories. See `editors/jetbrains/README.md` and `editors/windows/README.md` for target-specific work. Rebuild the common icon only when its design changes.
+`basedpl.editors.write()` generates syntax grammars/highlighters, editor templates, keyboard sources/bundles and glyph metadata from shared Rust symbols and keyboard data. It also writes JetBrains assets and Windows `editors/windows/layout.h`. It writes the browser editor module to `wasm/bpl-editor.js`. `cargo wasm` copies that module and `nbs/fonts/SAX2B.woff2` into the npm package and the playground. After a Rust change, run `python -m basedpl.editors` from the shell, because a running kernel keeps its old extension. `layout.json` owns composed input; captured `keyboards.json` supports generation without macOS. `basedpl.keyboards.capture()` refreshes native data when needed, and `keyboards.write()` generates regional macOS bundles/maps. Regenerate keyboard sources through these functions, not one-off kernel code. `basedpl-install` copies packaged fonts and macOS bundles from `python/basedpl/assets` to the user's directories. See `editors/jetbrains/README.md` and `editors/windows/README.md` for target-specific work. Rebuild the common icon only when its design changes.
 
 `nbs/bpl.xml`, the APL/BQN grammars and vim rules share generated glyph classes. `hpl.xml` includes BPL and adds Hanzi aliases from the same symbol table. Use `hpl` fences for Hanzi highlighting, `bpl` for Hanzi names. For Hanzi notebooks, set `kernelspec.language` to `hpl` and keep `kernelspec.name` as `bpl`. These labels do not enable runtime Hanzi aliases. TextMate exports feed Monaco/Shiki. `fonts.css` owns the BPL/APL font choices; rerun affected magics after changing them. `tests/highlighting.mjs`, `input.mjs`, keylayout/Windows tests and glyph-page checks cover their respective generated interfaces. All artifact generation belongs in repository functions/scripts, not ad hoc kernel transformations.
 
@@ -366,6 +372,8 @@ Quarto renders saved outputs. `bpl-nb --save` updates notebook outputs without c
 
 Before approval, verify successful tests for the release commit and the relevant installed artifacts. Reserve isolated wheel installs for packaging-sensitive work or release preparation, using a small relevant subset of existing tests. `ship-rs-build --profile dist` builds the distributed configuration; bare `ship-rs-build` uses release for local checks.
 
-Run `cargo test --profile checked` once before each release. That profile is the test profile with debug assertions on, which adds `session()`'s turn check and the standard library's checks in unsafe code. Those checks cost 12 to 55% per call, too much for the test profile that the budgets measure. The speed and scaling tests mark themselves ignored under debug assertions, so the run checks correctness only.
+Before each release, run `bpl-tests prerelease` from basedpl's root, in a shell rather than a kernel, while no one else is editing either repository. It runs both repositories' release checks and saves. First come the builds, tests and saves, in parallel, with each step starting once the steps whose output it reads have passed. In each repository these are `cargo develop`, `pytest -q`, `nbdev-prepare`, and `cargo test --profile checked` in a target directory of its own. basedpl adds editor generation, the Node input and highlighting tests, and `bpl-nb --save`. `target_builds` runs beside them, followed by `wasm_test` on its browser build. Then the timings run one at a time, with nothing else running: `cargo test` in each repository with `<NAME>_COSTS` set, rustymath's Python speed test, `thread_scaling` and the browser speed test. Last, `nbdev-clean` runs in both repositories, even after a failure. The first failure ends the run, unless `--keep-going` is given. The summary gives each step's status, time and log. `--dry-run` lists the steps in their order without running them. Before it starts, the run stops if `node_modules` or the Node version that `.node-version` names is missing. It also notes when basedpl needs an unreleased rustymath version, because rustymath then ships first. The run never commits, pushes or tags.
+
+The run's `cargo test --profile checked` uses the test profile with debug assertions on, which adds `session()`'s turn check and the standard library's checks in unsafe code. Those checks cost 12 to 55% per call, too much for the test profile that the budgets measure. The speed and scaling tests mark themselves ignored under debug assertions, so that run checks correctness only.
 
 Confirm the clean tree and `[workspace.package].version`, then run `ship-release` without flags. Python gets that version through `dynamic = ["version"]`. Fastship pushes/tags the current version, leaves publication to the Release workflow and bumps Cargo without rebuilding. There is no changelog step. Never commit, push, tag or publish without approval.

{basedpl-0.1.76 → basedpl-0.1.78}/PKG-INFO

@@ -1,13 +1,13 @@
 Metadata-Version: 2.4
 Name: basedpl
-Version: 0.1.76
+Version: 0.1.78
 Classifier: Programming Language :: Rust
 Classifier: Programming Language :: Python :: Implementation :: CPython
 Requires-Dist: fastcore
 Requires-Dist: jupyter-core
 Requires-Dist: fastship>=0.0.11 ; extra == 'dev'
-Requires-Dist: fastws-cli>=0.0.26 ; extra == 'dev'
-Requires-Dist: maturin>=1.9.4,<2.0 ; extra == 'dev'
+Requires-Dist: fastws-cli>=0.0.29 ; extra == 'dev'
+Requires-Dist: maturin>=1.13,<2.0 ; extra == 'dev'
 Requires-Dist: pytest ; extra == 'dev'
 Requires-Dist: pytest-timeout ; extra == 'dev'
 Requires-Dist: numpy ; extra == 'dev'

{basedpl-0.1.76 → basedpl-0.1.78}/editors/jetbrains/README.md

@@ -40,4 +40,4 @@ The XML uses JetBrains' `OTHER` (Everywhere) context. To limit applicability, re
 
 ## Generation
 
-`basedpl.editors.write()`, called by `scripts/prep.py`, generates the templates from BPL's shared glyph names and aliases and copies the shared grammar into the bundle. Edit the generators or source metadata, not the generated files.
+`basedpl.editors.write()`, which `bpl-tests prerelease` runs, generates the templates from BPL's shared glyph names and aliases and copies the shared grammar into the bundle. Edit the generators or source metadata, not the generated files.

{basedpl-0.1.76 → basedpl-0.1.78}/editors/windows/README.md

@@ -22,7 +22,7 @@ Remove the layout from your keyboard list before updating it. If Windows reports
 
 ## Build
 
-`basedpl.editors.write()` generates `layout.h` from `python/basedpl/layout.json` during `scripts/prep.py`. `keyboard.c` supplies the standard US scan-code and modifier tables.
+`basedpl.editors.write()` generates `layout.h` from `python/basedpl/layout.json` during `bpl-tests prerelease`. `keyboard.c` supplies the standard US scan-code and modifier tables.
 
 Install Microsoft's [C++ Build Tools](https://visualstudio.microsoft.com/visual-cpp-build-tools/) with **C++ core build tools**, **MSVC x64/x86**, **MSVC ARM64**, **MSVC ARM64EC** and a **Windows SDK**. From the repository, run:
 

{basedpl-0.1.76 → basedpl-0.1.78}/nbs/.gitignore

@@ -4,6 +4,9 @@
 /playground/input.js
 /playground/layout.json
 /playground/bpl.tmLanguage.json
+/playground/hpl.tmLanguage.json
 /playground/basedpl_wasm.js
 /playground/basedpl_wasm_bg.wasm
 /playground/canvas.js
+/playground/bpl-editor.js
+/playground/SAX2B.woff2