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]
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.
trifling.org is an entire Python coding site, offline first (localstorage after first load), with docs, turtle graphics, canvas, and avatar editor, vibe coded from start to finish, with all conversations in the GitHub repo here: https://github.com/zellyn/trifling/tree/main/docs/sessions
This is going to destroy my home network, since I never moved it off the little Lenovo box sitting in my laundry room beside the Eero waypoint, but I’m out of town for three days, so
Granted, the seed of the idea was someone posting about how they wired pyiodide to Ace in 400 lines of JavaScript, so I can’t truly argue it’s non-trivial.
As a light troll to hackernews, only AI-written contributions are accepted
[Edit: the true inception of this project was my kid learning Python at school and trinket.io inexplicably putting Python 3 but not 2 behind the paywall. Alas, Securely will not let him and his classmates actually access it ]
I’m horribly biased but I think it’s a combination of: (1) knee-jerk reaction to similar-looking but low-value comments, and (2) most people not having played around with LLM coding agents and messed around with their own agents enough to immediately jump to excitement at simple, safe sandboxing primitives for that purpose.
And +1000 on linking to your own (or any other well-written) blog.
When I ported pikchr (also from the SQLite project) to Go, I first ported lemon, then the grammar, then supporting code.
I always meant to do the same for its SQL parser, but pikchr grammar is orders of magnitude simpler.
reply