TLA+ = formal language for modeling software above the code level and hardware above the circuit level by Leslie Lamport (of vector clock and Paxos fame, among other things.)
So there's \in, \subseteq and probably many others that are written just like in Latex. Notably \cap and \cup were also copied from Latex, which describe the shape of the symbol instead of its meaning. But not \to, \mapsto, \Vee and \Wedge, they're written as ASCII art ->, |->, \/ and /\.
Then there's SUBSET, which means power set ... yeah. -_-
You’re in a desert walking along in the sand when all of the sudden you look down, and you see a tortoise, it’s crawling toward you. You reach down, you flip the tortoise over on its back. The tortoise lays on its back, its belly baking in the hot sun, beating its legs trying to turn itself over, but it can’t, not without your help. But you’re not helping. Why is that?
Because that would reverse flipping it over the first time, and our universe's physics are not reversible. Thermodynamics demands the turtle stay flipped.
Thanks for the nice article. The SQLite docs that explain this bug are emphatic about how utterly rare, even irreproducible it is. How, then, was it found, one wonders?
It's in Chrome, Firefox, Safari, Windows 10, macOS because it efficiently solves a huge number of use cases while giving plenty of headroom for flexible querying.
If you have data more complicated than a single CSV or tab-separated text file that you will only ever process in sequential order, and you don't need inter-process interaction, you should be asking why not use SQLite.
My guess is that they noticed something was not quite right when inspecting the code and then tested their hypothesis manually to see if it was actually a real bug.
Something similar happened to me when I was working on some code that should clear the state and, by inspection, I noticed some field was not properly cleared under specific circumstances. Then I tested the hypothesis and indeed found a bug. Sometimes intuition and guessing is what it takes.
I don't like the title. The article actually describes the process of proving that dqlite does not have the same bug as SQLite, using a TLA+ specification. The SQLite bug fix was entirely separate from what is described here.
For local only high level modelling. Its not a full tie into the actual model checker, but its meant to serve as a first step into system modelling for state machine modelling for beginners
This is so cool and I wonder how effective it would be using this technique when using LLMs to generate code. Have the llm generate code and a TLA+ model. Use the TLA+ model as the test bed of the code (instead of writing tests in the original language).
https://lamport.azurewebsites.net/tla/tla.html
Then there's SUBSET, which means power set ... yeah. -_-
[0] https://en.wikipedia.org/wiki/LaTeX
[1] https://en.wikipedia.org/wiki/Donald_Knuth
[2] https://en.wikipedia.org/wiki/TeX
We should probably blog about it.
If you have data more complicated than a single CSV or tab-separated text file that you will only ever process in sequential order, and you don't need inter-process interaction, you should be asking why not use SQLite.
Something similar happened to me when I was working on some code that should clear the state and, by inspection, I noticed some field was not properly cleared under specific circumstances. Then I tested the hypothesis and indeed found a bug. Sometimes intuition and guessing is what it takes.
I wonder if anyone has worked on porting it to Lean and making tactics for it
I made https://github.com/RCSnyder/tlaplus-process-studio
https://tlaplus-process-studio.com/
For local only high level modelling. Its not a full tie into the actual model checker, but its meant to serve as a first step into system modelling for state machine modelling for beginners
Also congratulations to the author, I'll try and reproduce this over the weekend.