Linear-time diagnostic codes, the PineForge Source License 1.1, and the scoreboard README at pineforge-release 03b8dcc

[luisleo526]

Summary

This PR puts three pending codegen changes in one branch, so the pr-gate measures them in one sweep. It supersedes #169 and #170. Each change is its own commit (the first has two), in this order, on main 285ac03:

1. Diagnostic codes read off their text in linear time (was Read diagnostic codes off their text in linear time #169)
   • 3ba9edf is Read diagnostic codes off their text in linear time #169's head, unchanged.
     • diagnostic_codes.classify fullmatched each catalog template as a regex with lazy arguments. Text a user's script spells reaches those arguments, and the regex backtracked over every split: a crafted PF-W1544 text took 0.6 s at 1.8 KB and 30 s at 3.4 KB.
     • It is now a literal-split matcher. Each literal goes to its leftmost place, which is the split the lazy regex returns.
     • For the 56 templates that name an argument twice, later places are tried in the regex's order, within a budget of 4,096 places. Text that exhausts the budget gets PF-E0000 / PF-W0000.
     • No API, catalog, pin or message change. The emitted C++ is untouched.
   • 69d368f changes tests only: two tests no longer depend on a loaded host's clock.
     • test_array_history.py::test_many_bindings_are_walked_once_each budgeted 40 s of wall clock. It takes 13–14 s alone on our shared Linux test hosts, yet every full-suite xdist run there since Stable diagnostic codes, an ICU message catalog, and first error in source order #166 failed it, at 50–60 s.
     • One such run timed three transpiles: 58, 57 and 78 s of wall clock for 27, 27 and 33 s of CPU, at load 45–74.
     • The test now budgets 60 s of CPU time (time.process_time()), 1.8 times the most measured under that load.
     • The regression it guards costs about eight times today's time: about 110 s on hosts like these, which fails. On the workstation where this run takes 7 s, the regression took 57 s, which now passes. A follow-up lowers the budget to 45 s so a fast workstation fails it too.
     • test_diagnostic_codes.py::test_every_spelled_template_has_a_code runs the catalog generator's own check in a subprocess. Loaded into the test process, the generator's parse of the whole package stayed in that xdist worker for the rest of the suite. That move alone left the timing test at 50.3 s.
2. The PineForge Source License 1.1 (e42f9c7)
   • Distributing the software, changed or not, embedded in or bundled with a product or service made available to others is Commercial Use, unless it is for a permitted purpose.
   • 1.0's Distribution License said "Distributing copies under this section is not Commercial Use". A vendor shipping the unmodified transpiler inside a product could read that as owing nothing.
   • Every other distribution of copies stays free and is not Commercial Use. Personal Trading, noncommercial use, the Notices duty and Output are unchanged.
   • Files: the LICENSE header and text, README (the license name and the Commercial Use bullet), LEGAL.md, the pyproject.toml comment, AGENTS.md and CLAUDE.md. Releases up to and including 1.1.0 keep the license text they shipped with.
3. The scoreboard README at pineforge-release 03b8dcc (was docs: render the active scoreboard from the facts tokens at pineforge-release 03b8dcc #170; 6904c30)
   • Re-renders the README's marked scoreboard values from the release hub's canonical facts at 03b8dcc8c6f0d60531309bf0abbb3fcad749ec55.
   • That scoreboard is pineforge-parity-baseline-20261004-engine-6b77f061: 7,970 excellent and 19 strong of 7,989 graded, none below strong. Only values inside pf markers change.

3ba9edf keeps #169's SHA. e42f9c7 and 6904c30 carry the reviewed commits' patches unchanged (git range-diff reports them identical).

Evidence

• pr-gate: PASS (no-improve-no-regression) for engine a80c623e0d2f and codegen 6904c3064dd2, against the active baseline pineforge-parity-baseline-20261004-engine-a80c623e. Recorded.

  • eventKey verdict-a80c623e0d2f-6904c3064dd2-d97b8579f85f, receipt e2b703f8….
  • Hard lane: 1009 probes, 0 regressions, rank sum 4032 → 4032, no moves.
  • Target lane: 6980 probes, score 0, no entrant or leaver.
  • Coverage: 7,989 of 7,989 probes measured.

• Full suite on a remote Linux test host (this head, engine a80c623e):

  • pytest: 5,678 passed, 41 skipped, 0 failed. The skips are environmental: reference commits missing from the shipped history, no clang++, empty parameter sets.
  • test_many_bindings_are_walked_once_each passed within its CPU budget. Its wall clock there was 60.4 s, which the old 40 s wall-clock budget would have failed.
  • compile-corpus: 314/314.
  • Pyodide gate: PARITY OK over 277 fixtures (ok 264/264, err 13).
  • The same run on the previous head, before the CPU budget, failed only that test (50.3 s of wall clock).

• Linear matcher on this branch:

  • Same code and args as main's regex matcher on 669/669 real texts and 7,512/7,512 generated samples.
  • Crafted PF-W1544 text from 1.8 KB to 6.6 MB classifies in 5 ms or less; main takes 0.6 s at 1.8 KB and 30 s at 3.4 KB.
  • The worst template that names an argument twice, flooded about 2,000 times, takes 0.026 s.

• Local (macOS, engine a80c623e headers, syntax-only compiles):

  • tests/test_diagnostic_codes.py and tests/test_array_history.py: 749 passed, 0 skipped. This includes test_classification_is_the_lazy_regex_split and test_classification_is_linear_on_crafted_text.
  • tests/test_compile_corpus.py: 314/314 passed, 0 skipped.
  • test_many_bindings_are_walked_once_each with the CPU budget: passes in 7.9 s.
  • Fail check for the subprocess test: with PF-E0001 dropped from a copy of the catalog, it fails and names the template at pineforge_codegen/lexer.py:333.
  • ruff check: the changed Python files are clean, and the repository's 170 existing findings are the same as on main.
  • lab facts check against the facts pinned to 03b8dcc: PASS, 15 markers, 0 drift.

🤖 Generated with Claude Code