shoney.arickathil
02b4b13a52
The branch was 17 ahead / 25 behind with 11 conflicting files, and drifting further: db.c had been rewritten twice on master since (group commit, then compaction). Resolved rather than rebased so both histories stay legible. Conflicts, and how each was settled: - db.c: BOTH semantics kept. Master's fatal path and compaction check now sit behind the branch's `table_is_durable` predicate, in all three inline arms — a volatile table reaches neither the barrier nor the compaction check - db-bench sample: every mode from both sides (growth, growth-verify, randread, replayseed, wmix) and ONE `boot` mode, which both sides had added independently - db-bench.py: all six legs kept. Both sides had also grown the same WAL-size helper under different names; collapsed into one - perf-targets: the branch's §5 (RAM ceiling) then master's §6/§7 — master's numbering had already assumed a §5 it did not have - story frontmatter: master's `status` (the landing truth) plus the branch's `readiness` axis. 03 would have read `done` + `refine`, which is a contradiction — it was brainstormed and landed on master, so `ready` - board: both standup blocks newest-first; master's chain rows (a superset); the branch's databasev2 1-2 rows with master's 3-4. Fixed a stray `|` in master's row 3 - baseline: master's, then REGENERATED from a full campaign — 143 metrics, 132 checks, 0 failures with both sides' legs present TWO HALF-EXPOSED FEATURES FIXED, because the merge rule is that master gets no feature that is honoured in name only: - `resident: keys` PARSED, set a .wob flag, and did nothing: rows stayed fully resident. A developer could declare a 120 GB table keys-resident, watch it compile, and be OOM-killed. The loader now REFUSES it with a message naming what to write instead, until tasks 5c/5d land. The compiler still parses it and its AST golden still passes, so the grammar work stays tested - `durable: false` was honoured ONLY on the inline path. wo_db_exec_req had no guard at all, so a volatile table written from an actor on a worker shard would still be logged — precisely porch's session-table case, and precisely what iteration 2 exists to provide. All three request-path arms now carry the same predicate. Found by reading the merged code, not by a test: the obvious probe runs main() on the primary and therefore only exercises the inline path Verified on the merged tree: wovm-test 0, woc-test 0, oop-e2e 122/0, residency-accept 8/0, db-bench 132/0, linkcheck clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| actor | ||
| compile-fail | ||
| db | ||
| gc | ||
| lang | ||
| run | ||
| sample-logwatcher | ||
| sys | ||
| trap | ||
| README.md | ||
tests/corpus/ — the conformance spine
Fixture kinds, exact-outcome matching (byte-equal stdout / exact WO-E### / exact trap code / exact gc step+freed counts):
| dir | kind | landed by plan |
|---|---|---|
run/ |
compiles + runs, expected stdout | 3 |
compile-fail/ |
must fail with expected WO-E### |
3–4 |
trap/ |
must trap with expected code | 3–4 |
gc/ |
cycle collection scenarios | 3 |
actor/ |
shard/spawn/send (ASan+TSan) | 4 |
db/ |
insert/select + crash/replay | 5 |
lang/ |
Haxe-parity adoptions | 8 |
sys/ |
fs/proc/net/time/json stdlib | 9 |
sample-logwatcher/ |
ported log-watcher fixtures | 10 |
Runner: scripts/oop-e2e.sh (plan 3, task 2 — includes the how-to-add-a-fixture doc pointer docs/plan/oop-vm/02-corpus.md).