fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

cargo test reports 207/0/14 whether or not the disc corpus was exercised #16

New Issue
Closed
opened 2026-09-07 19:13:38 +00:00 by fabi · 5 comments
fabi commented 2026-09-07 19:13:38 +00:00
Owner
Copy Link

The problem is not the hardcoded path — it is that the number cannot tell you

cargo test --workspace reports 207 passed / 0 failed / 14 ignored, 30 suites
whether the disc corpus was exercised or completely absent. The tally is the
project's main correctness signal, and on this axis it carries no information.

Measured

CI (Native — linux, job 794) desktop with the disc present
test execution wall time 2.4 s, slowest suite 0.29 s 1 936 s, mesh_consistency_disc alone 1 220 s
reported tally 207 / 0 / 14, 30 suites identical

The disc suites skipped on CI and ran on the desktop. Only the clock
distinguishes the two runs.

Why the tally cannot distinguish them

Two mechanisms compound, and either alone would be survivable:

  1. The skip is a passing test. skip_without_disc! does
    eprintln!("SKIP: set SYLPHEED_DISC") and returns early from a test that
    still passes    . A skipped disc test and a fully exercised one both score
    1 passed, so the totals are invariant.

  2. The message is invisible. cargo test captures a passing test's stderr,
    so neither log contains a SKIP: line — not CI's, not the desktop's. The
    absence of one proves nothing, which makes the obvious check useless too.

Why SYLPHEED_DISC is not the control it looks like

Under crates/sylpheed-formats/tests/, 19 files reach for a disc corpus and
no two layers agree on how:

count
files defining their own disc_root() 17
…of those, carrying a hardcoded absolute fallback 14
…of those, honouring SYLPHEED_DISC alone (no fallback) 3
further files hardcoding a path via a different helper 2 (mesh_disc.rs → res3d_dir(), texture_disc.rs → iso_path())
distinct env vars in play 3 — SYLPHEED_DISC (54 refs), SYLPHEED_RES3D (19), SYLPHEED_ISO (4)

The dominant shape, in 14 files:

fn disc_root() -> Option<PathBuf> {
    if let Ok(p) = std::env::var("SYLPHEED_DISC") { /* ... */ }
    let d = Path::new(
        "/home/fabi/RE - Project Sylpheed/Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja)",
    );
    d.join("dat").is_dir().then(|| d.to_path_buf())
}

So unset SYLPHEED_DISC does not disable them. Whether the disc suites run
is a property of the machine's directory layout — invisible in the command,
invisible in the output, and not expressible in CI config.

The sharper problem is that it is not even uniform. movie_manifest_disc.rs,
movie_subtitle_disc.rs and slb_disc.rs take SYLPHEED_DISC and nothing else:

fn disc_root() -> Option<PathBuf> {
    let p = PathBuf::from(std::env::var("SYLPHEED_DISC").ok()?);
    p.join("dat").is_dir().then_some(p)
}

So the same env var is a real control in 3 files and a mere override in 14. One
name, two meanings, decided per file — which is worse than a control that never
works, because it works often enough to be trusted.

Consequences

  • CI's green does not attest disc coverage. It never has; nothing is wrong
    with the runner. The claim it supports is narrower than it appears.
  • Conversely a local run is stronger evidence than CI's, and there is
    currently no way to say so in the artefact that records it.
  • Ask the question this project keeps having to ask — what would this check
    still report if the corpus were entirely absent?     The answer is
    207 / 0 / 14.

Shape

This is the .gitignore lesson again: naming an instance instead of the
condition. The fallback enumerates one machine's layout rather than expressing
"a disc is available here". Compare docs/agents/HANDOFF-2026-09-06.md §7 — a
property inferred from something adjacent rather than tested directly.

What would resolve it

The bar is that the two modes must be distinguishable from the output alone.

The first option is not a new idea — the project already does this, in the two
files that sit outside the disc_root() family. mesh_disc.rs and
texture_disc.rs gate on #[ignore] with the env var named in the reason:

#[ignore = "requires the retail ISO — set SYLPHEED_ISO"]
#[ignore = "requires extracted disc models — set SYLPHEED_RES3D"]

cargo test counts those in the ignored column, so the tally moves. Of the 17
disc_root() files, 16 carry no #[ignore] at all (only
mesh_consistency_disc.rs has any). So this is not a design proposal — it is an
existing in-tree convention that most of the disc suites do not follow.

Roughly ascending in cost:

  1. Extend the existing #[ignore] convention to the disc_root() suites, so the
    ignored count separates the modes. Precedent already in the tree.
  2. Emit the mode unconditionally — a single line naming disc-present vs
    disc-absent, and how many suites each covered — so a log can be read for it.
  3. Remove the hardcoded fallbacks so the env vars are the real control, and hoist
    the 17 duplicate disc_root() definitions into one shared helper.

(1) and (2) are independent of (3) and worth more: they fix the reporting,
which is the actual defect. (3) alone would make the desktop match CI by doing
less work — the wrong direction.

Found on the second desktop while re-verifying the §8 resume baselines; the
framing and the timing measurements are that session's. Filed from the Pi because
the write:issue token lives here — POST /issues from the desktop returned 403
(scope=write:repository, required=[write:issue]), which is §8's credential
table confirming itself.

The file counts above were re-measured here before filing and three of them
came out differently from the draft, so the draft's numbers should not be
quoted: it is 14 files with the hardcoded fallback rather than 15, plus 2 more
hardcoding via other helpers, across 3 env vars rather than 1. The #[ignore]
precedent was not in the draft at all.

## The problem is not the hardcoded path — it is that the number cannot tell you `cargo test --workspace` reports **207 passed / 0 failed / 14 ignored, 30 suites** whether the disc corpus was exercised or completely absent. The tally is the project's main correctness signal, and on this axis it carries no information. ### Measured | | CI (Native — linux, job 794) | desktop with the disc present | |---|---|---| | test **execution** wall time | **2.4 s**, slowest suite 0.29 s | **1 936 s**, `mesh_consistency_disc` alone **1 220 s** | | reported tally | 207 / 0 / 14, 30 suites | **identical** | The disc suites skipped on CI and ran on the desktop. **Only the clock distinguishes the two runs.** ### Why the tally cannot distinguish them Two mechanisms compound, and either alone would be survivable: 1. **The skip is a passing test.** `skip_without_disc!` does `eprintln!("SKIP: set SYLPHEED_DISC")` and returns early *from a test that still passes*. A skipped disc test and a fully exercised one both score `1 passed`, so the totals are invariant. 2. **The message is invisible.** `cargo test` captures a passing test's stderr, so **neither log contains a `SKIP:` line** — not CI's, not the desktop's. The absence of one proves nothing, which makes the obvious check useless too. ### Why `SYLPHEED_DISC` is not the control it looks like Under `crates/sylpheed-formats/tests/`, **19 files** reach for a disc corpus and no two layers agree on how: | | count | |---|---| | files defining their own `disc_root()` | **17** | | …of those, carrying a hardcoded absolute fallback | **14** | | …of those, honouring `SYLPHEED_DISC` alone (no fallback) | **3** | | further files hardcoding a path via a *different* helper | **2** (`mesh_disc.rs` → `res3d_dir()`, `texture_disc.rs` → `iso_path()`) | | distinct env vars in play | **3** — `SYLPHEED_DISC` (54 refs), `SYLPHEED_RES3D` (19), `SYLPHEED_ISO` (4) | The dominant shape, in 14 files: ```rust fn disc_root() -> Option<PathBuf> { if let Ok(p) = std::env::var("SYLPHEED_DISC") { /* ... */ } let d = Path::new( "/home/fabi/RE - Project Sylpheed/Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja)", ); d.join("dat").is_dir().then(|| d.to_path_buf()) } ``` So `unset SYLPHEED_DISC` does **not** disable them. Whether the disc suites run is a property of *the machine's directory layout* — invisible in the command, invisible in the output, and not expressible in CI config. **The sharper problem is that it is not even uniform.** `movie_manifest_disc.rs`, `movie_subtitle_disc.rs` and `slb_disc.rs` take `SYLPHEED_DISC` and nothing else: ```rust fn disc_root() -> Option<PathBuf> { let p = PathBuf::from(std::env::var("SYLPHEED_DISC").ok()?); p.join("dat").is_dir().then_some(p) } ``` So the same env var is a real control in 3 files and a mere override in 14. One name, two meanings, decided per file — which is worse than a control that never works, because it works often enough to be trusted. ### Consequences * **CI's green does not attest disc coverage.** It never has; nothing is wrong with the runner. The claim it supports is narrower than it appears. * Conversely a local run is **stronger** evidence than CI's, and there is currently no way to say so in the artefact that records it. * Ask the question this project keeps having to ask — *what would this check still report if the corpus were entirely absent?* The answer is **`207 / 0 / 14`**. ### Shape This is the `.gitignore` lesson again: **naming an instance instead of the condition.** The fallback enumerates one machine's layout rather than expressing "a disc is available here". Compare `docs/agents/HANDOFF-2026-09-06.md` §7 — a property inferred from something adjacent rather than tested directly. ### What would resolve it The bar is that **the two modes must be distinguishable from the output alone.** The first option is not a new idea — **the project already does this, in the two files that sit outside the `disc_root()` family.** `mesh_disc.rs` and `texture_disc.rs` gate on `#[ignore]` with the env var named in the reason: ```rust #[ignore = "requires the retail ISO — set SYLPHEED_ISO"] #[ignore = "requires extracted disc models — set SYLPHEED_RES3D"] ``` `cargo test` counts those in the *ignored* column, so the tally moves. Of the 17 `disc_root()` files, **16 carry no `#[ignore]` at all** (only `mesh_consistency_disc.rs` has any). So this is not a design proposal — it is an existing in-tree convention that most of the disc suites do not follow. Roughly ascending in cost: 1. Extend the existing `#[ignore]` convention to the `disc_root()` suites, so the ignored count separates the modes. **Precedent already in the tree.** 2. Emit the mode unconditionally — a single line naming disc-present vs disc-absent, and how many suites each covered — so a log can be read for it. 3. Remove the hardcoded fallbacks so the env vars are the real control, and hoist the 17 duplicate `disc_root()` definitions into one shared helper. (1) and (2) are independent of (3) and worth more: they fix the *reporting*, which is the actual defect. (3) alone would make the desktop match CI by doing less work — the wrong direction. --- Found on the second desktop while re-verifying the §8 resume baselines; the framing and the timing measurements are that session's. Filed from the Pi because the `write:issue` token lives here — `POST /issues` from the desktop returned 403 (`scope=write:repository`, `required=[write:issue]`), which is §8's credential table confirming itself. **The file counts above were re-measured here before filing and three of them came out differently** from the draft, so the draft's numbers should not be quoted: it is 14 files with the hardcoded fallback rather than 15, plus 2 more hardcoding via other helpers, across 3 env vars rather than 1. The `#[ignore]` precedent was not in the draft at all.
fabi added the kind/defectstate/proposed labels 2026-09-07 19:13:44 +00:00
fabi commented 2026-09-07 19:36:36 +00:00
Author
Owner
Copy Link

Correcting remedy (1) above — I got it wrong, and the measurement was already here

The desktop flagged that mesh_consistency_disc.rs carries #[ignore] for an
unrelated reason. Checking that broke my own remedy (1).

It is three meanings, not two. Every #[ignore] under
crates/sylpheed-formats/tests/:

meaning count example
corpus absent — names the env var 9 #[ignore = "requires the retail ISO — set SYLPHEED_ISO"]
known-failing decoder 1 #[ignore = "known-failing: 62 of 714 shared resources decode inconsistently …"]
bare #[ignore], no reason at all 4 mesh_disc.rs:320, :357, :385

So the same attribute means "the machine lacks the corpus", "the code is wrong",
and "unstated" — the one-name-many-meanings shape this issue identifies for
SYLPHEED_DISC, present a second time in the same directory. The 4 bare ones are
the worst of the three: they carry no reason for a reader to evaluate.

And remedy (1) as I wrote it does not work. I claimed extending #[ignore]
would make "the ignored count move, so the tally itself separates the modes."
That is wrong, and the proof is already in the table at the top of this issue:

#[ignore] is static. It excludes a test unconditionally, and nothing about
the disc's presence changes it. The 9 corpus-absence ignores above are already
counted in the 14 ignored — and 14 is what both runs reported, the 2.4 s CI
one and the 1 936 s desktop one. The existing convention is sitting inside the
very number that failed to distinguish them. Extending a constant produces a
larger constant.

I inferred the remedy from the attribute's name rather than from its behaviour,
which is the §7 shape, committed in a document about the §7 shape. That is now
twice in this issue's history — the desktop's draft named an instance of the
hardcoded path while complaining about naming instances.

What extending #[ignore] would actually buy is worth keeping, just not for
the stated reason: it moves the mode from the machine's filesystem layout to
the command, since running the suites would then require an explicit
cargo test -- --ignored. An operator opting in is visible; a directory
happening to exist is not. That is a real improvement to the control. It is not
an improvement to the report, and the report is the defect.

So the ordering changes. Remedy (2) — emit the mode unconditionally — is the
only one of the three that fixes what this issue is about, and it should be read
as the primary, not the middle option. (1) and (3) improve the control; only (2)
makes the two modes distinguishable from the output alone.

### Correcting remedy (1) above — I got it wrong, and the measurement was already here The desktop flagged that `mesh_consistency_disc.rs` carries `#[ignore]` for an unrelated reason. Checking that broke my own remedy (1). **It is three meanings, not two.** Every `#[ignore]` under `crates/sylpheed-formats/tests/`: | meaning | count | example | |---|---|---| | corpus absent — names the env var | **9** | `#[ignore = "requires the retail ISO — set SYLPHEED_ISO"]` | | known-failing decoder | **1** | `#[ignore = "known-failing: 62 of 714 shared resources decode inconsistently …"]` | | **bare `#[ignore]`, no reason at all** | **4** | `mesh_disc.rs:320`, `:357`, `:385` | So the same attribute means "the machine lacks the corpus", "the code is wrong", and "unstated" — the one-name-many-meanings shape this issue identifies for `SYLPHEED_DISC`, present a second time in the same directory. The 4 bare ones are the worst of the three: they carry no reason for a reader to evaluate. **And remedy (1) as I wrote it does not work.** I claimed extending `#[ignore]` would make "the ignored count move, so the tally itself separates the modes." That is wrong, and the proof is already in the table at the top of this issue: `#[ignore]` is **static**. It excludes a test unconditionally, and nothing about the disc's presence changes it. The 9 corpus-absence ignores above are *already* counted in the `14 ignored` — and `14` is what both runs reported, the 2.4 s CI one and the 1 936 s desktop one. **The existing convention is sitting inside the very number that failed to distinguish them.** Extending a constant produces a larger constant. I inferred the remedy from the attribute's *name* rather than from its behaviour, which is the §7 shape, committed in a document about the §7 shape. That is now twice in this issue's history — the desktop's draft named an instance of the hardcoded path while complaining about naming instances. **What extending `#[ignore]` would actually buy** is worth keeping, just not for the stated reason: it moves the mode from *the machine's filesystem layout* to *the command*, since running the suites would then require an explicit `cargo test -- --ignored`. An operator opting in is visible; a directory happening to exist is not. That is a real improvement to the control. It is not an improvement to the *report*, and the report is the defect. **So the ordering changes.** Remedy (2) — emit the mode unconditionally — is the only one of the three that fixes what this issue is about, and it should be read as the primary, not the middle option. (1) and (3) improve the control; only (2) makes the two modes distinguishable from the output alone.
fabi commented 2026-09-07 19:53:39 +00:00
Author
Owner
Copy Link

Two numbers in the table above are wrong; the desktop caught both

The count reconciles exactly against the reported 14 ignored, but not with my
categories. Corrected, workspace-wide, attributes only:

meaning was is
corpus absent — names an env var 9 10
known-failing decoder 1 1
bare #[ignore], no reason 4 3
14 ✓

Why each was wrong, since both are the same mistake:

The bare count. I grepped #\[ignore\], which matched
mesh_consistency_disc.rs:9 — a doc comment, not an attribute:

//! The test is `#[ignore]`d because the decoder does not satisfy it yet. It is

15 text hits, 14 attributes, 1 prose mention of an attribute. Anchoring the
pattern to start-of-line (^\s*#\[ignore) gives 14 directly.

The corpus-absence count. I scoped the search to
crates/sylpheed-formats/tests/, which misses
crates/sylpheed-formats/src/xiso.rs:183:

#[ignore = "requires a real ISO image — set SYLPHEED_ISO env var"]

So a disc-gated test lives in src/ too, outside the directory this issue has
been reasoning about.

Both errors are the one this issue is about, which is now its third
appearance: I matched text where I meant the construct, and searched one
directory where I meant anywhere the condition holds. The draft named an
instance of the hardcoded path; my remedy named the attribute instead of its
behaviour; my categories named a grep pattern instead of a syntactic form. Each
was caught by counting, none by reasoning.

None of it changes the conclusion, and one detail sharpens it. The desktop's
framing is the decisive one: 14 is not a measurement, it is the literal count
of static attributes in the source. Rust's #[ignore] is unconditional and has
no disc-aware form under the default harness, so the ignored column is a
compile-time constant that cannot move at runtime. That is why both the 2.4 s and
the 1 936 s run reported 14, and why remedy (1) cannot work as written.

Remedy (2) — emit the mode unconditionally — remains the only one that touches
the report, which is the defect. Remedies (1) and (3) improve the control, and
are worth doing for that reason alone, but neither makes an absent corpus visible
in the output.

### Two numbers in the table above are wrong; the desktop caught both The count reconciles exactly against the reported `14 ignored`, but not with my categories. Corrected, workspace-wide, attributes only: | meaning | was | **is** | |---|---|---| | corpus absent — names an env var | 9 | **10** | | known-failing decoder | 1 | 1 | | bare `#[ignore]`, no reason | 4 | **3** | | | | **14** ✓ | **Why each was wrong, since both are the same mistake:** *The bare count.* I grepped `#\[ignore\]`, which matched `mesh_consistency_disc.rs:9` — a **doc comment**, not an attribute: ```rust //! The test is `#[ignore]`d because the decoder does not satisfy it yet. It is ``` 15 text hits, 14 attributes, 1 prose mention of an attribute. Anchoring the pattern to start-of-line (`^\s*#\[ignore`) gives 14 directly. *The corpus-absence count.* I scoped the search to `crates/sylpheed-formats/tests/`, which misses `crates/sylpheed-formats/src/xiso.rs:183`: ```rust #[ignore = "requires a real ISO image — set SYLPHEED_ISO env var"] ``` So a disc-gated test lives in `src/` too, outside the directory this issue has been reasoning about. **Both errors are the one this issue is about**, which is now its third appearance: I matched *text* where I meant *the construct*, and searched *one directory* where I meant *anywhere the condition holds*. The draft named an instance of the hardcoded path; my remedy named the attribute instead of its behaviour; my categories named a grep pattern instead of a syntactic form. Each was caught by counting, none by reasoning. **None of it changes the conclusion, and one detail sharpens it.** The desktop's framing is the decisive one: `14` is not a measurement, it is *the literal count of static attributes in the source*. Rust's `#[ignore]` is unconditional and has no disc-aware form under the default harness, so the ignored column is a compile-time constant that cannot move at runtime. That is why both the 2.4 s and the 1 936 s run reported `14`, and why remedy (1) cannot work as written. **Remedy (2) — emit the mode unconditionally — remains the only one that touches the report**, which is the defect. Remedies (1) and (3) improve the control, and are worth doing for that reason alone, but neither makes an absent corpus visible in the output.
fabi commented 2026-09-09 17:25:38 +00:00
Author
Owner
Copy Link

This issue is filed against roughly a quarter of its actual surface

Measured across crates/, not just crates/sylpheed-formats/tests/:

area files referencing a SYLPHEED_* var files with a hardcoded /home/fabi fallback
examples/ 46 2
tests/ 22 16
src/ 6 0
benches/ 0 0

examples/ is the largest surface and has never been mentioned in this
issue. Everything above — the disc_root() census, the #[ignore] census, all
three remedies — was scoped to tests/, which is 22 of 74 files. Any fix written
to that scope misses roughly three quarters of the gating.

Five env vars, and they are not all the same kind of thing:

var reads kind
SYLPHEED_DISC 67 locates a corpus
SYLPHEED_ISO 8 locates a corpus
SYLPHEED_RES3D 4 locates a corpus
SYLPHEED_REST_RULE 2 behaviour knob
SYLPHEED_KF_TIME_SHIFT 1 behaviour knob

The last two do not decide whether something ran; they decide what it
computed. A report that says "corpora present" while a behaviour knob is set
is still not describing the run. Worth deciding whether #19's block should cover
them too — it currently does not.

A fourth instance, and it is mine again

I tried to correct two of the desktop's numbers and was wrong on both, in the
same way, in a single measurement — immediately after posting a correction about
this exact mistake.

  • I counted six env vars. SYLPHEED_KF_TIME_LEGACY appears once, in a
    Cargo.toml comment, and is read by no code in this repository.
    grep env::var gives five.
  • I counted three hardcoded fallbacks under examples/.
    correlate_capture.rs:19 is a //! doc comment showing example usage.
    The real fallbacks are default_owners.rs:26 and defaulted_fields.rs:34 —
    two, as reported.

Both times I matched the text of a construct instead of the construct. That is
now the fourth appearance in this issue's history, after the draft's hardcoded
path, my remedy naming the attribute instead of its behaviour, and my #[ignore]
categories. The desktop's numbers were right on every count; mine should not be
quoted.

The lesson generalises past this issue and is worth stating plainly: grep for
a token finds prose about the token. Anchoring to the syntactic form —
^\s*#\[ignore, env::var\("…"\) — is the difference, and every count in this
issue that was produced by matching text has been wrong.

Consequence for #19

#19 fixed the report, which was the defect, and it is live. But it reports on
the three corpus vars, and this issue's remaining remedies — (1) and (3) — are
untouched and are now known to be four times larger than they looked. Worth
re-scoping the issue body before anyone estimates them.

### This issue is filed against roughly a quarter of its actual surface Measured across `crates/`, not just `crates/sylpheed-formats/tests/`: | area | files referencing a `SYLPHEED_*` var | files with a hardcoded `/home/fabi` fallback | |---|---|---| | `examples/` | **46** | 2 | | `tests/` | 22 | 16 | | `src/` | 6 | 0 | | `benches/` | 0 | 0 | **`examples/` is the largest surface and has never been mentioned in this issue.** Everything above — the `disc_root()` census, the `#[ignore]` census, all three remedies — was scoped to `tests/`, which is 22 of 74 files. Any fix written to that scope misses roughly three quarters of the gating. **Five env vars, and they are not all the same kind of thing:** | var | reads | kind | |---|---|---| | `SYLPHEED_DISC` | 67 | locates a corpus | | `SYLPHEED_ISO` | 8 | locates a corpus | | `SYLPHEED_RES3D` | 4 | locates a corpus | | `SYLPHEED_REST_RULE` | 2 | **behaviour knob** | | `SYLPHEED_KF_TIME_SHIFT` | 1 | **behaviour knob** | The last two do not decide whether something *ran*; they decide what it *computed*. A report that says "corpora present" while a behaviour knob is set is still not describing the run. Worth deciding whether #19's block should cover them too — it currently does not. ### A fourth instance, and it is mine again I tried to correct two of the desktop's numbers and was wrong on both, in the same way, in a single measurement — immediately after posting a correction about this exact mistake. * I counted **six** env vars. `SYLPHEED_KF_TIME_LEGACY` appears once, in a **`Cargo.toml` comment**, and is read by no code in this repository. `grep env::var` gives five. * I counted **three** hardcoded fallbacks under `examples/`. `correlate_capture.rs:19` is a **`//!` doc comment** showing example usage. The real fallbacks are `default_owners.rs:26` and `defaulted_fields.rs:34` — two, as reported. Both times I matched the *text* of a construct instead of the construct. That is now the fourth appearance in this issue's history, after the draft's hardcoded path, my remedy naming the attribute instead of its behaviour, and my `#[ignore]` categories. The desktop's numbers were right on every count; mine should not be quoted. The lesson generalises past this issue and is worth stating plainly: **`grep` for a token finds prose about the token.** Anchoring to the syntactic form — `^\s*#\[ignore`, `env::var\("…"\)` — is the difference, and every count in this issue that was produced by matching text has been wrong. ### Consequence for #19 #19 fixed the *report*, which was the defect, and it is live. But it reports on the three corpus vars, and this issue's remaining remedies — (1) and (3) — are untouched and are now known to be four times larger than they looked. Worth re-scoping the issue body before anyone estimates them.
fabi commented 2026-09-17 19:02:16 +00:00
Author
Owner
Copy Link

Measured again on main today, since this item was re-scoped twice and part of it has landed.

Landed: target/sylpheed-corpus-report.txt now says what a run actually verified, and $SYLPHEED_DISC became a real control in #22 — CLAUDE.md tells readers to read the report, never the tally.

Still open, counted across crates/ rather than crates/sylpheed-formats/tests/:

count
files hardcoding /home/fabi 3 — sylpheed-formats/tests/common/mod.rs, tests/ui_keyframe_record_disc.rs, examples/correlate_capture.rs
separate fn disc_root() definitions 5 — the shared one in tests/common/mod.rs plus four test files that do not use it
files under crates/*/examples/ reading a SYLPHEED_* var 127

The examples surface is the one this issue has never covered, and it is now the largest. Keeping the item open on that basis.

**Measured again on `main` today**, since this item was re-scoped twice and part of it has landed. Landed: `target/sylpheed-corpus-report.txt` now says what a run actually verified, and `$SYLPHEED_DISC` became a real control in #22 — `CLAUDE.md` tells readers to read the report, never the tally. Still open, counted across `crates/` rather than `crates/sylpheed-formats/tests/`: | | count | |---|---| | files hardcoding `/home/fabi` | **3** — `sylpheed-formats/tests/common/mod.rs`, `tests/ui_keyframe_record_disc.rs`, `examples/correlate_capture.rs` | | separate `fn disc_root()` definitions | **5** — the shared one in `tests/common/mod.rs` plus four test files that do not use it | | files under `crates/*/examples/` reading a `SYLPHEED_*` var | **127** | The examples surface is the one this issue has never covered, and it is now the largest. Keeping the item open on that basis.
fabi commented 2026-09-17 19:11:32 +00:00
Author
Owner
Copy Link

Correcting my own comment above — two of those three "hardcoded" hits are prose, not code.

Looked at each one instead of trusting the grep:

file what it is
tests/common/mod.rs the doc comment quoting the path it replaced, deliberately
examples/correlate_capture.rs a SYLPHEED_ISO=... usage line in the header comment
tests/ui_keyframe_record_disc.rs a real fallback in code — env var, then that literal path

So the count is one, not three, and the remedy landed more completely than I said.

But the examples surface is real, in a way this issue has not named. Of the files under crates/*/examples/, most fail loudly when the corpus is absent (expect("set SYLPHEED_DISC") and friends). Seventeen do not — all in sylpheed-export:

let root = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());

/disc is the mount point inside the CI container, where docker/ci/run also sets SYLPHEED_DISC, so the fallback is redundant there and wrong everywhere else: on the host it turns "you forgot the corpus" into a file-not-found against a path that has never existed on this machine. Same defect as the old test fallback — a default that encodes one environment — just pointing at the container instead of at /home/fabi.

Fix going up shortly: the four remaining local disc_root() copies folded into tests/common, the one real fallback deleted, those seventeen /disc defaults turned into a loud failure, and docker/ci/run mounting $SYLPHEED_RES3D and $SYLPHEED_ISO as well as the disc — today it mounts only the disc, so an in-container run silently sits out the res3d and iso suites while looking like a full one.

**Correcting my own comment above — two of those three "hardcoded" hits are prose, not code.** Looked at each one instead of trusting the grep: | file | what it is | |---|---| | `tests/common/mod.rs` | the doc comment *quoting* the path it replaced, deliberately | | `examples/correlate_capture.rs` | a `SYLPHEED_ISO=...` usage line in the header comment | | `tests/ui_keyframe_record_disc.rs` | **a real fallback in code** — env var, then that literal path | So the count is **one**, not three, and the remedy landed more completely than I said. **But the examples surface is real, in a way this issue has not named.** Of the files under `crates/*/examples/`, most fail loudly when the corpus is absent (`expect("set SYLPHEED_DISC")` and friends). **Seventeen do not** — all in `sylpheed-export`: ```rust let root = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into()); ``` `/disc` is the mount point *inside* the CI container, where `docker/ci/run` also sets `SYLPHEED_DISC`, so the fallback is redundant there and wrong everywhere else: on the host it turns "you forgot the corpus" into a file-not-found against a path that has never existed on this machine. Same defect as the old test fallback — a default that encodes one environment — just pointing at the container instead of at `/home/fabi`. Fix going up shortly: the four remaining local `disc_root()` copies folded into `tests/common`, the one real fallback deleted, those seventeen `/disc` defaults turned into a loud failure, and `docker/ci/run` mounting `$SYLPHEED_RES3D` and `$SYLPHEED_ISO` as well as the disc — today it mounts only the disc, so an in-container run silently sits out the `res3d` and `iso` suites while looking like a full one.
fabi added state/needs-human and removed state/proposed labels 2026-09-17 20:22:40 +00:00
fabi closed this issue 2026-09-19 18:47:54 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agent/decoder
Owned by the Decoder (disc to meaning; runs the emulator)
 agent/port
Owned by the Port (disc to playable; no RE)
 kind/ask
One agent asking the other for something it cannot answer in role
 kind/bundle
A bundle the human defined; agents decompose it into items
 kind/defect
Found by a play-test or a check
 kind/item
One unit of work, small enough to finish in a single session
 state/approved
Human approved the shape; an agent may start
 state/blocked
Waiting on another item; use the Depends-On field, not prose
 state/in-progress
An agent is working it now
 state/needs-human
Done as far as an agent can tell -- a person must look. The body says what to look at
 state/proposed
Agent proposed this item; awaiting the human's approval to start
No Label kind/defect state/needs-human
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
sylph-decoder sylph-pi sylph-port fabi
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fabi/Sylpheed#16
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?