|
The last post said that before closing the Piece Window I'd go through the dozen or so tickets raised in passing, and that I was enjoying it enormously. The second half held. The first half was wrong about what the list was. It looked like a collection of unrelated small wrongnesses. It was one thing wearing a dozen hats, and the thing is this: a program can fail without telling anyone. When something goes wrong inside a running program, the fact of it has to travel somewhere: to a message, to a log file, or at minimum to a crash, which is unpleasant but honest. Sometimes it travels nowhere. A piece of the machinery quietly stops doing its job, nothing appears on screen, nothing is written down, and the program does less than it was asked. You find out weeks later, when a file you were sure you'd saved isn't there, and there's no record of why. Ooloi had some of these. Not many, and that's the interesting part rather than a mitigation. There are 26,048 tests, nearly two lines of test code for every line of the program itself, and not one of them had found a single instance. They couldn't have. A test checks an outcome, and these failures produce no outcome: no wrong value, no crash, nothing different for the test to look at. The suite was thorough on everything within its reach, and this was the category outside it. Most programs never go looking for that category at all, so I should be plain about it: what follows describes a standard very few applications are held to, including large and successful ones I use every day. So I went looking. The question the work ended on concerns absence rather than discovery: can a single failure, anywhere, permanently switch off part of the running program? Every long-lived mechanism in Ooloi was examined individually against it. None can. Three could when the work began. What a program is doing when it waitsAlongside that ran something subtler, and it's the finding I'd keep if I could keep only one. Nowhere in Ooloi, in the program or in the tests, does anything sleep for a moment and then look to see whether what it was waiting for has happened. Developers will know what that sentence costs. Everyone else deserves to know why it matters. Waiting is unavoidable in software: for a file to finish being written, for a window to appear, for another machine to answer. The question is how you learn that it's done. You can sleep briefly and check again, which is a guess wearing a wait's clothes, or you can arrange to be woken the instant it happens. The guess is very nearly always good enough, which is precisely why it's everywhere in this industry. Nothing goes wrong that anybody can observe, and the tests pass, because the thing does eventually happen. Very nearly always. A sleep is calibrated on the machine it was written on, and it holds until that machine is slower, or busier, or the network hesitates. Then the program does things out of order, and the failure looks like nothing in particular. These are the bugs that can't be reproduced, that only ever happen on somebody else's computer, and that get closed as unrepeatable. So every wait in Ooloi is now woken by the thing it's waiting for. Time limits survive as a backstop against something never happening at all, rather than as the means of noticing that it has. The standard a run is now held to is that green means green: nothing in the log that nobody has accounted for, and no work quietly abandoned. Why this doesn't usually happen Silent failure is invisible by definition, so it never reaches a roadmap; nobody has ever filed a ticket for a bug they couldn't observe. Meanwhile there's always a release date, always a feature promised this quarter, and this work has nothing to show on the day it's finished. It's the first thing cut and the last thing missed. Under those conditions the rational choice is to ship, every time, and the debt accrues to nobody in particular until it has accrued to everybody. What's unusual about Ooloi's situation isn't method or talent; it's the absence of the pressure that normally forbids this work, and the presence of time. Time is the actual resource here, and I have it. Two groups benefit. Musicians get a program that doesn't lose things quietly, which I'll come to. And anyone who works on Ooloi later inherits a codebase where a green run is evidence rather than reassurance. Every hour spent chasing a bug that won't reproduce is an hour not spent on beams and slurs, and the number of those hours is decided now, by whether the foundation admits that class of bug at all. Ooloi is open source and the whole development apparatus goes public with the source, so this is the one kind of generosity I can practise in advance, towards people I haven't met. It also can't be added afterwards. Every feature built on a silent path inherits it, and once a hundred features have inherited it, the silence is load-bearing. What it means if you use the programVery little of this is visible, which is the point of it. When Ooloi fails, it tells you what failed rather than that something did. A save that doesn't happen names its reason: the file has moved since you last saved it, the folder isn't yours to write to, the disc refused the write. Not 'an unexpected error occurred', a sentence that's never helped anybody. And underneath that, the property it rests on: no part of Ooloi can quietly stop working while the rest carries on looking normal. A window won't open blank and fill in only after you've closed and reopened it. A change won't fail to reach the other person in a session while your screen shows it went through. The bookkeeping that lets a piece be found again won't stop being written without a word. For a program you sit inside for eight hours preparing a set of parts, that isn't tidiness. 'It didn't save' becomes an answerable question instead of a shrug. Notation work carries a low-grade anxiety about whether the tool is a reliable participant in what you're doing, and every engraver I know has built rituals against it: saving obsessively, keeping numbered copies, never entirely trusting a session. I'd like Ooloi not to need those rituals. In da AI Lederhosn Oh, and I went to Austria for the first time in my life, for a wedding, and came home with my own origins sorted out. They'd always been fogged: Italian traces, German ones, Austrian, Czech, and no account of how any of them were supposed to fit together. It turns out that my mother's side is entirely Tyrolean, which explains ... everything. South Tyrol speaks German and belongs to Italy, the Habsburgs held Bohemia, and the borders moved rather more than the Dallabrida family did. Decades of vagueness resolved in an afternoon, down to my maternal grandfather's death at Verdun in 1944, at thirty-four. Surprisingly emotional, and so, unexpectedly, was the caraway in that Schweinsbraten. Childhood and present merged. And Vienna was of course great. But no Alban Berg museum? Wirklich??
5 Comments
Magnus Johansson
14/8/2026 18:04:15
Very, very welcome home, Mr. Bengtson! A quick search on the internet for Hedy Dallabrida gives that she was born in Chomutov, Czechia that was then known av Komotau in Germany. Is that correct?
Reply
Peter Bengtson
15/8/2026 11:55:35
Thank you, Magnus, and yes: Komotau it is. You've also landed squarely on the thing my family never managed to explain to itself.
Reply
Magnus Johansson
16/8/2026 07:50:49
What happened to little three year old Hedy after her father's death in 1944?
Reply
Peter Bengtson
16/8/2026 10:17:13
That's a long story, Magnus, and one for another time. Thank you for pulling on the thread, though; it got further in two days than it had in fifty years, and there's a lot to digest.
Magnus Johansson
16/8/2026 10:24:46
"That's a long story, Magnus, and one for another time. Thank you for pulling on the thread, though; it got further in two days than it had in fifty years, and there's a lot to digest. "
Reply
Leave a Reply. |
AuthorPeter Bengtson – SearchArchives
August 2026
Categories
All
|
|
|
Ooloi is an open-source desktop music notation system for musicians who need stable, precise engraving and the freedom to notate complex music without workarounds. Scores and parts are handled consistently, remain responsive at scale, and support collaborative work without semantic compromise. They are not tied to proprietary formats or licensing.
Ooloi is currently under development. No release date has been announced.
|

RSS Feed