Three of gig-up's four standing NO-GO blockers were one file and one buffering
bug. Cleared them, verified each by planting the failure back.
**something_about_drums.tidal — two typos, both silent by design of the tooling**
:13 `(<| "~ <s s <s!3 ~> <~!7 [~ s]>>")d1` — a stray `d1` pasted straight
after the closing paren, no operator, no newline. GHC reported it as
"Variable not in scope: d1" at 13:56, and because a parse error takes the
whole do-block with it, the reported line belonged to the GROUP, not to
the break. The d2 block never ran.
:81 `d8 $ gF1 $ gM1` — d8 copy-pasted from d1's block without updating the
family macro. The authored map puts d8 in gM2 with d2 and d3, so d8 was
wired to the wrong mute family: pressing d8's mute would have taken d1
with it, live, and nothing about the code looked wrong.
after: `silent-eval --seeded` OK (every declared orbit emits events),
`fix-mute-roles --check` WOULD REWRITE: 0 lines, `pvlint (setlist)` ok.
**check-boot-blocks.py — the check was the third defect**
`tools/check-boot.sh` run alone passed clean, every line green, while gig-up
called the same check FAIL. The difference was not the rig. Under gig-up the
checker crashed:
ValueError: invalid literal for int() with base 10: '6C1o'
`'6C1o'` is two output lines interleaved character-wise. The cause is in the
capture: stdout and stderr are deliberately ONE merged pipe (separate capture
would put every marker before every error and attribute each error to the last
block — the mis-attribution this tool exists to prevent), but GHC block-buffers
stdout while writing errors to stderr unbuffered. Two writers, one pipe, so a
marker could be flushed into a chunk a stderr write had already cut into. Rare
enough to look like a phantom, and it presented as "your boot helpers are
broken" — the rig's most alarming failure — when nothing was wrong.
- `hSetBuffering stdout LineBuffering` is now the script's first statement, so
each marker is one atomic write, in order.
- Markers are self-delimiting (`@@PVBLOCK i start @@`) and matched by regex, so
a torn one CANNOT parse as intact.
- A torn marker, or a parse error that cannot be placed, is now INCONCLUSIVE
(rc=2, "rerun") rather than a crash — and rather than a silent skip, which
would have hidden a real error behind a green verdict.
Verified: 3 consecutive clean runs, then a planted unbalanced paren appended to
the block starting at :581 was caught and blamed on exactly that block
(rc=1, "block 16 (starts near bt.hs:581) is NOT one statement"). A checker that
cannot catch a planted bug is worth nothing, so that test is the one that counts.
gig-up: 4 blockers -> 2 (surface-grid migration debt, fader baseline).
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| liquid | Loading commit data... | |
| BreakBass.tidal | Loading commit data... | |
| MethBass.tidal | Loading commit data... | |
| alerte_verte.tidal | Loading commit data... | |
| anniv.tidal | Loading commit data... | |
| break_the_loop.tidal | Loading commit data... | |
| bruler_franchement.tidal | Loading commit data... | |
| drums_I_presume.tidal | Loading commit data... | |
| force_motrice.tidal | Loading commit data... | |
| golden_drum.tidal | Loading commit data... | |
| jet_de_resistance.tidal | Loading commit data... | |
| la_bonne_pression.tidal | Loading commit data... | |
| la_foule.tidal | Loading commit data... | |
| lime_tacos.tidal | Loading commit data... | |
| lucy_rode.tidal | Loading commit data... | |
| noname.tidal | Loading commit data... | |
| nouveau_soleil.tidal | Loading commit data... | |
| perceneige.tidal | Loading commit data... | |
| plosive.tidal | Loading commit data... | |
| prepabass.tidal | Loading commit data... | |
| something_about_drums.tidal | Loading commit data... | |
| venons_ensemble.tidal | Loading commit data... | |
| wap.tidal | Loading commit data... |