fix: Clean up awkward user-facing tune/config output lines - #27
Merged
Conversation
- Remove stray spaces in ESTIMATED tuning header line Fixes vyncint#25 Signed-off-by: Vedant Madane <6527493+VedantMadane@users.noreply.github.com>
Signed-off-by: Vedant Madane <6527493+VedantMadane@users.noreply.github.com>
vyncint
requested changes
Aug 25, 2026
vyncint
left a comment
vyncint
left a comment
Owner
There was a problem hiding this comment.
Thanks for picking this up — both string changes are correct, and the sweep is complete: there is no user-facing (s) left anywhere in crates/.
Three things before it can land, and the first two are quick.
1. Two stray files. COMMITMSG and PRBODY.md are in the diff at the repo root. They look like local scratch files for composing the commit message and PR body — git rm them and they are gone.
2. The goldens need re-blessing — this is why the four checks are red. app.rs now emits configuration, but overview-80x24.txt and overview-110x32.txt still record configuration(s):
assertion `left == right` failed: overview: frame differs from golden overview-80x24.txt
- │1 REFUSED configuration(s) measured FASTER than the chosen one — view 3 │
+ │1 REFUSED configuration measured FASTER than the chosen one — view 3 │
One command, and I ran it against your branch to be sure of what it does:
LAUNCHBOUND_BLESS=1 cargo test -p launchbound-tui --test tuiIt changes exactly those two lines in those two files, and the suite then passes 6/6. Please read the diff before committing it, the way tests/tui.rs asks — blessing without looking is how a golden ends up recording a bug.
3. Optional, and genuinely not a blocker. The else branch is never exercised: the only fixture (run-flip) produces exactly one rejected-faster candidate, so "configurations" is unreached by any test. If adding a second one to the fixture is easy, it would cover both sides. If it turns out to be fiddly, leave it — I would rather not turn a two-line fix into a fixture project.
On the line-splitting I floated in #25: it was optional and the header reads fine as it is now. No need.
Three things from the review on vyncint#27, none of them the contributor's string changes, which were right. The diff carried COMMITMSG and PRBODY.md at the repository root — local scratch files for composing the commit message and the PR body. Removed. The goldens still recorded `configuration(s)`, so all four checks were red: `overview_at_80x24`, `resize_relayouts_the_frame` and `stress_100_runs_at_80x24`, on both runners, plus the same three inside `ci`. Re-blessed with LAUNCHBOUND_BLESS=1, and the diff is exactly the two banner lines in the two goldens that carry it — nothing else moved, which is the point of reading a bless before committing it. The `else` branch had no test and could not easily get one: the count comes from measured timings, and the single fixture the golden frames are built on yields exactly one rejected-faster candidate. Reaching the plural through a rendered frame would mean rebuilding that fixture and moving every golden in the suite to cover one word. So the banner is a function now, and both arities are asserted directly. That is a better shape for it anyway — a `format!` with an `if` inside it is harder to read than a named thing, and this one is the line the view exists to draw attention to. Rendering is unchanged, which the goldens confirm. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com>
vyncint
approved these changes
Aug 26, 2026
vyncint
approved these changes
Aug 26, 2026
vyncint
left a comment
vyncint
left a comment
Owner
There was a problem hiding this comment.
All three review items are done — I pushed the last commit to your branch since maintainerCanModify was on and the fix was mechanical.
COMMITMSG/PRBODY.mdremoved.- Goldens re-blessed. The diff is exactly the two banner lines, nothing else — worth checking, since a bless that moves more than you expected is how a golden ends up recording a bug.
- The banner is a small function now, with both arities asserted. Reaching the plural through a rendered frame would have meant rebuilding the fixture every golden is built on, to cover one word — not a trade worth making for a two-line fix, and this gets the coverage without it.
All 8 checks green (4 were red). Your string changes were right as they stood; thanks for taking the issue.
vyncint
added a commit
that referenced
this pull request
Sep 5, 2026
* fix: read what the analyzer wrote, and refuse what cannot be read Six findings that share a shape: something was consumed on a contract other than the one it is written to. **JSONL.** reconverge prints one findings document per analyzed *target*, and this reader handed the whole of stdout to a single `from_str` — so a kernel crate with a `src/main.rs` beside its library, the ordinary shape of a GPU crate, hard-stopped every candidate with `trailing characters at line 2 column 1`. The fail-safe held; it held against a format the analyzer documents. Stdout is read as JSONL now and the findings are unioned: a deny finding in any target is a reason to refuse, and the bin target's document is harmless to merge. A parse failure carries the first two hundred bytes of what was received, because the serde message told the reporter everything and would tell a user nothing. **The scratch copy.** It took only the entries of `src/` that are files, so `mod util;` with `src/util/mod.rs` produced a scratch crate that could not compile — and the gate reported `error: could not compile` against a crate whose own `cargo check` is clean, telling its author to fix errors they do not have or reinstall their toolchain, and never saying that what it compiled was not what they were looking at. It copies recursively now, carries `build.rs` (or whatever `package.build` names), and a tool error names the scratch directory so the next person can go and look. **The diagnosis filter.** rustc's primary diagnostics begin `error[E0583]:` — a code before the colon — so a filter on `error:` kept cargo's summary and dropped the line that names the failure. "See the errors above": the one above was the one the filter removed. Both forms are accepted, in the prune runner and in the compile executor, which had the tail-eight heuristic #19 removed next door for exactly this reason. **`--budget`.** `split_at(text.len() - 1)` on a trimmed-empty argument is `0usize - 1`, so `--budget ""` panicked at exit 101. Worse, `NaN` and `1e400` parsed: the guard is `elapsed >= budget`, which is false for every value against NaN and never true against infinity, so a value that looked accepted produced an unbounded sweep on real silicon — the one failure a budget exists to prevent. Rejected now, with the accepted forms named, and `min`/`hr` accepted alongside `m`/`h` because that is what people type. **`apply`.** Verification ran *after* the params.rs was printed, so "refusing to emit" arrived after the emission. It now decides first. On a Metal run — which has no convergence gate, deliberately — it refuses by name and points at `--no-verify` or `prune --cc <target>`, instead of handing the `metal` sentinel to reconverge and reporting the correct answer to the wrong question as a regression. `--verify` is a real switch with a `--no-verify` counterpart, so a machine without the analyzer can emit, with the notice carried into the output beside the Metal one. And `Verdict` has a `Display`, so no user-facing message is a struct literal. **`results.json`.** A truncated file, an empty one, `null`, `[]`, a `results.v2` and a *directory* all read as "the box has not run yet": exit 0, nothing on stderr, a schema-valid report saying `unmeasured`. The run directory is the hand-off between two machines and those two conditions call for opposite actions — wait, or go and look. Only `NotFound` is `Ok(None)` now; everything else names the path and the cause, the way `verdicts.v1` already did fifteen lines away. Also: the reconverge pin moves to 0.5.0 at all seven sites, and scripts/check-pins.sh asserts they agree with no network — 2.0.0 moved four of six, which left the watcher measuring drift from a version nothing installs and #17 describing a pin two releases old. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com> * fix(tui): stop cutting values and sentences at the panel border #24 fixed this on the chosen line and left it standing in the two views below. The ranking lost every closing bracket at eighty columns, so each interval read as a number with no upper bound and a dangling comma. The rejections view — the one the README calls the point of the tool — lost the half of the reason that says what to do: the reader got as far as `splits a 64-threa` and never reached `safe only at one warp (<= 32 threads)`. Nothing marked the cut, so it read as the whole reason. The two want different treatment and that is the substance of the fix. An interval is a field, so the ranking drops it whole when it does not fit, through the same helper the chosen line uses — shared so the two views cannot disagree about it again, which is how this came to be fixed once and missed twice. A rejection reason is a sentence whose actionable clause is at the end, so it wraps instead, and the panel spends the two or three rows. The guard is the scan that found both: no golden line may reach the panel border with a character that means the value continued — a digit, `,`, `[`, `(`, `=`, `-` — or with a cut word, unless an ellipsis marks it. Confirmed red against the shipped pre-fix golden, which is also what it would have done to #24. Alongside: `prune`'s verdict line now says what it checked and what it did not. The gate answers convergence and shared-memory capacity at a `--cc`; it has no view of instruction availability, so a crate using an `sm_80+` intrinsic under `needs_cc = "7.5"` prunes to `12 clean` at `--cc 7.5` and fails only when something finally lowers it. That is defensible and was nowhere stated, so "3 clean" read as "this kernel is fine at cc 7.5". docs/LIMITATIONS.md carries the long form, including why the two stronger fixes were not built. Tests: the JSONL union and every way it can fail, a scratch copy over a crate with `src/util/inner.rs` and a manifest-named build script, a `error[E0583]:` line surviving the diagnosis filter, and each of the six unreadable `results.json` shapes. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com> * test(tui): assert the wrapped reason survives a narrow terminal A property of the rendered grid rather than of a string: the reason is wrapped across rows now, so the sentence exists only as a sequence of cells. Sixty columns is where wrapping has to do real work and no golden covers it — which is also how the test found that `ready` cannot be used at that width, because the footer is cut before it reaches `q quit`. Confirmed red with the wrap removed. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com> * release: 2.1.0 Thirteen findings, all reported against 2.0.0 with a measured reproduction, and the lockstep pin bump to reconverge 0.5.0 that #46 and #17 were waiting on. Verified end to end against the *published* cargo-reconverge 0.5.0 rather than a local build: the two shapes that hard-stopped the gate — a kernel crate with a `src/main.rs`, and one with a `src/util/mod.rs` — now give `3 clean, 0 with caveats, 8 refused, 0 tool errors` at exit 0, identical to the control with neither. The whole corpus prunes unchanged, and the three gate tests pass, so the pin bump is behaviour-preserving where it should be. Also here: `prune`'s "what was and was not checked" note is printed once for the run rather than once per kernel — over a six-kernel corpus the per-kernel form was six repetitions of the same paragraph, which is the kind of user-facing noise #27 was about. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com> * fix(ci): make the pin gate run on macOS, and actually check what it claims Three defects in the gate I added, two of which it exists to prevent. `declare -A` and `local -n` are bash 4. macOS ships bash 3.2, where an associative array is silently an indexed one, so the script passed on Linux and died on the macOS runner with `rust: unbound variable` — the same defect as the GNU-only `sed -i` this project's sibling had in its own gate scripts. Rewritten with tab-separated lines and a pipeline, which is portable. `agree` runs in a pipeline and therefore a subshell, so setting `status=1` inside it would have been discarded: the gate would have printed the disagreement and exited 0. It returns a status now and the caller collects it. That is precisely the class of bug this gate is for. And the nightly was never compared at all. The action writes `default: nightly-2026-04-03` unquoted, the extractor required quotes, and the old code treated an unreadable site as nothing to check — so the one pin with only two recorded sites had neither of them verified. An extractor that silently matches nothing is a stale pin one level up, so an empty read is now a failure by name. Each of the three pin families verified red independently, with exit 1. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com> --------- Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Clean up awkward user-facing tune/config output lines
Changes
Fixes #25