From 0efd692b4ce49b98e0318cb8eed44fddabb7bd9b Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Sat, 29 Aug 2026 04:02:34 +0000 Subject: [PATCH] docs: the suite is heavy, not hung -- correcting my own "cannot terminate" Last iteration I wrote that build-reborn test cannot finish in a working session, from having watched it run 3h26m. That was the stronger claim and I made it without measuring the work. Timing `mesh info` on each of the 166 .xpr containers with a 25 s cap: files scanned 166 exceeding 25 s 19 Hangar, 17 Stage_*, ptc_pack Stage_S02 to completion 144 s, rc = 0 Nothing hangs. Nineteen heavy containers at roughly two minutes each is about 45-60 minutes for one pass, before the 147 fast ones. The 3h26m observed was that hour of work running at a load average of 9-14 -- inflated by the two duplicate runs I had left going, which did not merely coexist with the slowness but multiplied it. The practical conclusion is unchanged and only the wording softens: an hour-scale suite is not an iteration-scale gate, and every "green" I reported from it this session was partial. But an hour-scale gate can be run deliberately, whereas a hung one cannot be run at all, so the distinction is worth having right. File list committed as reference data so the cost is attributable without re-scanning. METHOD: a slow thing observed under contention looks like a stuck thing; measure the work before choosing between "cannot finish" and "takes an hour". --- docs/re/METHOD.md | 8 ++++++++ docs/re/REFUTED.md | 6 ++++++ docs/re/data/slow-xpr-files.txt | 22 ++++++++++++++++++++++ docs/re/test-suite-runtime.md | 23 ++++++++++++++++++++++- 4 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 docs/re/data/slow-xpr-files.txt diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 736d260..754ecf7 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -734,3 +734,11 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the suite is stated to have terminated — so report the suite count and elapsed state rather than the word "green", which is what I should have been doing all session. +* **"Cannot finish" and "takes an hour" are different claims — measure before + choosing.** I wrote that the verification gate *cannot terminate*, from having + watched it run 3 h 26 m. Timing the work directly: 19 of 166 containers exceed + 25 s, `Stage_S02` completes in **144 s**, and one full pass is ~45–60 minutes. + Nothing hangs. The 3 h 26 m was that hour of work at a load average of 9–14, + inflated by my own duplicate runs. A slow thing observed under contention looks + like a stuck thing, and the correction matters: an hour-scale gate can be run + deliberately, a hung one cannot be run at all. diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index 4984c9f..70b1f87 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -516,3 +516,9 @@ neighbourhood, not just the line. flagged group violates it on a median **52.5 %** of pixels against **30.2 %** unflagged — both far from premultiplied, and the flagged group *further*. [`ui-paint-order-key.md`](structures/ui-paint-order-key.md) +* "`build-reborn test` cannot terminate" → **mine, and too strong; corrected the + next iteration.** It is heavy, not hung: 19 of 166 `.xpr` containers exceed + 25 s, `Stage_S02` completes in **144 s** with `rc = 0`, and one full pass is + ~45–60 minutes. The 3 h 26 m observed was that work at a load average of 9–14, + inflated by my own two duplicate runs. + [`test-suite-runtime.md`](test-suite-runtime.md) diff --git a/docs/re/data/slow-xpr-files.txt b/docs/re/data/slow-xpr-files.txt new file mode 100644 index 0000000..4517f6f --- /dev/null +++ b/docs/re/data/slow-xpr-files.txt @@ -0,0 +1,22 @@ +# .xpr files whose `mesh info` decode exceeds 25 s (debug build), of 166 scanned +# 2026-08-29. Stage_S02 measured at 144 s to completion, rc=0 -- heavy, not hung. + +Hangar.xpr +Stage_S02.xpr +Stage_S03.xpr +Stage_S04.xpr +Stage_S06.xpr +Stage_S07.xpr +Stage_S08.xpr +Stage_S09.xpr +Stage_S11.xpr +Stage_S12.xpr +Stage_S13.xpr +Stage_S15.xpr +Stage_S24.xpr +Stage_S25.xpr +Stage_S26.xpr +Stage_S27.xpr +Stage_S28.xpr +Stage_S29.xpr +ptc_pack.xpr diff --git a/docs/re/test-suite-runtime.md b/docs/re/test-suite-runtime.md index 0179250..c57e5c4 100644 --- a/docs/re/test-suite-runtime.md +++ b/docs/re/test-suite-runtime.md @@ -1,4 +1,4 @@ -# 🔴 `build-reborn test` cannot finish in a working session — and I left two runaways +# 🟡 `build-reborn test` takes about an hour — and I left two runaways **Status:** ✅ measured. Two facts, one of them my own mess. @@ -16,6 +16,27 @@ fn twin_pairs_do_not_share_a_buffer() { ``` Measured: one instance accumulated **3 h 26 m of CPU at 89 %** without finishing. + +### 🔴 "Cannot terminate" was too strong — corrected + +It terminates; it is merely heavy, and I said the stronger thing before measuring +it. Timing `sylpheed-cli mesh info` on each of the 166 files with a 25 s cap +([`data/slow-xpr-files.txt`](data/slow-xpr-files.txt)): + +| | | +|---|---| +| files scanned | 166 | +| exceeding 25 s | **19** — `Hangar`, 17 `Stage_*`, `ptc_pack` | +| `Stage_S02` timed to completion | **144 s**, `rc = 0` | + +So nothing hangs. Nineteen heavy containers at roughly two minutes each is +**~45–60 minutes** for one pass, before the 147 fast ones. The observed 3 h 26 m +was that work running at a **load average of 9–14** — inflated by my own two +duplicate runs competing with each other and with this one. The runaways did not +merely coexist with the slowness; they multiplied it. + +⚠️ The practical conclusion is unchanged and only the wording softens: an +hour-scale suite is not an iteration-scale gate. Its sibling in the same file, `shared_resources_decode_identically_in_every_container`, walks the same 166 files and *is* `#[ignore]`d (as known-failing), so the binary's cost is easy to underestimate from a glance at the file.