And really well-reasoned arguments. And a decades-long sterling reputation for cantankerous but insightful contrarian takes. And references in the article to astonishingly well researched articles by people who have talked to NASA engineers and read non-public documentation. It’s like anyone can be taken seriously these days…
When I refer to "extracting sources from the SQLite codebase" a big part of that was indeed referring to compiling Lemon and executing it against a custom implementation of parse.y [1].
The problem comes from how SQLite's upstream parse.y works. Becuase it doesn't actually generate the parse tree, instead generating the bytecode directly, the intepretation of any node labelled "id" or "nm" is buried inside the source code behind many layers of functions. You can see for yourself by looking at SQLite's parse.y [2]
Ah, that makes sense. Thanks for the details. I see now that your article basically had all the information I needed to figure this out if I’d thought a bit harder!
Also, nice work: this makes the world just a little nicer!
Correct[0]. This was also my first thought after reading
> Unfortunately, unlike many other languages, SQLite has no formal specification describing how it should be parsed. It doesn’t expose a stable API for its parser either. In fact, quite uniquely, in its implementation it doesn’t even build a parse tree at all9! The only reasonable approach left in my opinion is to carefully extract the relevant parts of SQLite’s source code and adapt it to build the parser I wanted
Did they made a proper problem research in the first place?
I'm very well aware of parse.y, if you look into the syntaqlite code, you'd find it's a critical part of how the whole "source extraction" mentioned in the article works [1]
To be clear when I say "formal specification", I'm not just talking about the formal grammar rules but also how those interpreted in practice. Something closer to the ECMAScript specification (https://ecma-international.org/publications-and-standards/st...).
It’s fun to look at your code samples, have absolutely no clue what any of it means, and think about just how many non-English-speaking programmers must have felt that way looking at our all-English programming languages.
Except lisp: that’s just inscrutable symbols like cond and cons and car and cadr and a bunch of parens! :-)
The real barrier is not just the language keywords but lots of documentations and discussions in English. I'm not sure whether there is a solution to this.
This tons of Eng documents and contents cannot be translated once but this project is trying to use another language for future use. Thanks for the comment, though.
Yes! Wokwi is great and definitely served as inspiration for Velxio. My goal with this project was mainly to explore how microcontroller emulators work internally and experiment with building parts of that stack myself.
For those arguing that humans rely on vision alone, one additional argument:
If a leaf lands on your windshield, you can look beside it or move your head to see around it. If a leaf lands on a camera lens, it blocks it.
A pair of cameras mounted in the same place as human eyes, with the freedom to move a bit would be a fairer comparison. (The cameras would probably see better…)
Agree. Also, you have a general intelligence and a pair of eyes, not just a pair of eyes. In the absence of an artificial general intelligence, we need better sensors than a human has if we are to hope to approximate human performance.
Thank you! I’ve always procrastinated tracking finances, but as a programmer who believes in reproducible builds, this just clicked.
I just downloaded a bunch of qfx and csv files, and got Claude Code to do this. Took an hour to create the whole system from nothing. Then of course I stayed up until 2am getting CC to create Python rules to categorize things better, and trying to figure out what BEENVERI on my bank statement means
(If you do this, make Claude generate fingerprints for each transaction so it’s easy to add individual overrides…)
Getting Claude to write a FastAPI backend to serve up a “Subscriptions” dashboard took about 3 minutes, plus another minute or two to add an svg bar graph and change ordering.
reply