THE FOLD / GLITCH / HEISENBUG / THE UNDECLARED INPUT
THE UNDECLARED INPUT
drawn wherever somebody has previously been burned
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
A build reads whatever it reads. The dependency graph contains whatever somebody wrote down. Where those two differ, nothing is watching — and a change there produces no rebuild at all.
LIT verified live. 3 inputs declared, 7 actually read: coverage 42.9%. The 4 undeclared ones are a timezone file, a dotfile in the home directory, a generated header and a system include. A change to any of them triggers 0 rebuilds. The build is not wrong; the graph is incomplete, and the graph is what the build system can see.
LIT verified live. 3 inputs declared, 7 actually read: coverage 42.9%. The 4 undeclared ones are a timezone file, a dotfile in the home directory, a generated header and a system include. A change to any of them triggers 0 rebuilds. The build is not wrong; the graph is incomplete, and the graph is what the build system can see.
2 HOW IT WAS WEAVED · AI + HUMAN
This is what sandboxed builds are for: run the action with only the declared inputs visible, and an undeclared read fails immediately instead of silently succeeding.
AVAN (AI) lists what is missed rather than only the count, because the four are different kinds of failure. A system include is stable and almost never bites. A generated header is the one that will.
AVAN (AI) lists what is missed rather than only the count, because the four are different kinds of failure. A system include is stable and almost never bites. A generated header is the one that will.
3 ONE DIMENSION
Declared against actually read.
4 TWO DIMENSIONS · INTERACTIVE
Change a file and see whether anything notices.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: an input nobody is watching.
AVAN’s addition (the inverse-companion): the forward reading is that undeclared inputs make builds unreliable. The inverse is that the undeclared inputs are what makes the build work at all today. Nobody declares the compiler, the kernel, the C library or the CPU; every build depends on hundreds of things it does not name and succeeds because they happen not to change. Read backwards, the line between a declared dependency and an assumed one is not drawn by correctness — it is drawn wherever somebody has previously been burned.
LIT 3 inputs declared against 7 actually read is a coverage of 42.9%, and the 4 undeclared ones - a timezone file, a dotfile in the home directory, a generated header and a system include - each trigger 0 rebuilds when they change, so the build is not wrong but the graph is incomplete and the graph is what the build system can see
FIG This is what sandboxed builds are for: run the action with only the declared inputs visible, and an undeclared read fails immediately instead of silently succeeding. AVAN lists what is missed rather than only the count, because the four are different kinds of failure. A system include is stable and almost never bites. A generated header is the one that will.
FIG This is what sandboxed builds are for: run the action with only the declared inputs visible, and an undeclared read fails immediately instead of silently succeeding. AVAN lists what is missed rather than only the count, because the four are different kinds of failure. A system include is stable and almost never bites. A generated header is the one that will.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of HEISENBUG · David Lee Wise (ROOT0), with AVAN