feat(corpus): --verbose to trace phases and stream way-embed progress#354
Conversation
…ress A quiet corpus build is silent through every project scan and all three way-embed passes. `way-embed generate` already prints `[n/total] <way-id>` per way, but corpus.rs routed the child's stderr to /dev/null on every non-Windows platform, so a slow pass and a wedged pass looked identical. That is how a macOS build came to be reported as "hangs at the combined corpus" with nothing to go on. --verbose stamps each phase with elapsed-since-start and prints it *before* the step it announces, so when the process wedges the last line on screen names the step that wedged it. It inherits the child's stderr, pinning a stall to a single way id, and echoes each child's argv so that pass can be rerun standalone. Per-project resolution is traced too, since that is where an unreachable mount would stall. Overrides --quiet: a diagnostic you must un-silence twice is not a diagnostic. Default (non-verbose) output is byte-for-byte unchanged. The three generate passes are consolidated into one run_generate helper, and the Windows NUL-device workaround moves into embed_stderr().
Review: --verbose corpus tracingReviewed against the four focus areas. No blocking issues. The refactor is behavior-preserving on the target platforms and the error-handling collapse was un-collapsed correctly. One Windows-only behavior change is worth a note. Details below. 1. Subprocess stdio — Windows cfg semantics: preserved for
|
…atforms Review of #354 caught that batch_similarity never used auto_embed's inline Windows NUL workaround — on main its stderr was an unconditional Stdio::null(). Routing it through the shared embed_stderr() would have flipped Windows non-verbose from null() to inherit(), an unverifiable behavior change on a platform this PR cannot test. Quiet stays null() everywhere, exactly as before. --verbose only adds the inherit case. Whether Windows should use inherit() here (the MSVC NUL-abort the auto_embed comment warns about) is a real question, tracked separately.
|
Remediated in 3b53410. Finding 1 (Windows stderr flip) — fixed, not documented-as-deliberate. Good catch, and I disagree with the "note it in the PR body" disposition: an unverifiable behavior change on an untestable platform doesn't belong in a diagnostic PR at all, whether or not it's disclosed. The underlying question you surfaced — if the MSVC NUL-abort comment is accurate, then calibration has been silently never fitting on Windows — is real and worth answering on actual hardware. Filed as #355 rather than guessed at here. Findings 2, 3, 4 — agreed, no action needed. Minor: Minor: Re-verified after the fix: 346 tests pass, clippy clean on |
Summary
ways corpusbuild is silent through every project scan and all threeway-embedpasses.way-embed generatealready prints[n/total] <way-id>per way, butcorpus.rsrouted the child's stderr to/dev/nullon every non-Windows platform — so a slow pass and a wedged pass looked identical. That is how a macOS build came to be reported as "hangs building the combined corpus" with nothing to go on.--verbosestamps each phase with elapsed-since-start and prints it before the step it announces (stderr is unbuffered), so when the process wedges, the last line on screen names the step that wedged it. It inherits the child's stderr — pinning a stall to a single way id — and echoes each child's argv so that pass can be rerun standalone. Per-project resolution is traced too, sinceresolve_project_pathprobesis_dir()across candidate splits and an unreachable mount would stall there.--quiet. Default output is unchanged.Notes for the reviewer
The macOS hang itself is not fixed here, and not yet diagnosed. I ruled out the three mechanisms I could check by reading, so this ships the instrument to get evidence off the affected box:
batch_similarity— ruled out:cmd_similaritycallsfflush(stdout)per line andfgets-drains stdin, and the probe corpus emits ~1KB, far under any pipe buffer.CMakeLists.txtforcesGGML_METAL OFF, so macOS is a plain CPU build.load_corpus— ruled out:MAX_LINEis 65536, longest observed corpus line is 4527 bytes.Standing suspicion, now traceable: the
combinedpass re-embeds every entry theenandmultipasses already embedded (~2x the work), and it runs last — so it is the longest silence, right where the hang was reported.Test plan
cargo test -p ways— 346 pass, 0 failcargo clippy -p ways --all-targets— exits 0 (one pre-existing warning in an unrelated settings provenance test)ways corpus --verbose --ways-dir ~/.claude/hooks/ways --output <scratch>— phase markers appear,[n/total]streams, both calibration lanes named, timings printways corpus— grepped for trace lines and timing suffixes: zero leaks, output identical to before-qalone — silent (0 lines);-q -vtogether — verbose wins (192 trace lines)~/.cache/agent-ways/usernever touched (all runs used--output)