Impressed you found that. I don't have anything set up to automatically update it currently, but I do have an intention to have something set up to automatically update it.
Ha, yes, I was being nosy. It was quite easy to spot as it's the only XHR/Fetch request.
I was intrigued what you had used to build it, and if you had built your own solver (which you have), and what editor you used (Code Mirror) so went looking at the code. Interesting to see you left the source maps for production, made it easy for my sleuthing...
I experimented with a similar idea last year, but used ProseMirror/TipTap as the editor to enable rich text editing, and the MathJS (https://mathjs.org) solver. I also combined it with PouchDB and Yjs for offline editing and syncing between devices. Never finished it though, you have kept your nice and simple!
Oops, didn't realise I'd left source maps in, thanks for pointing it out!
Your project sounds really interesting, I'm following you on twitter now, so tweet about it if you ever finish it and hopefully I'll see.
Having CRDT-based syncing/collaboration is a direction I'd like to take NumPad in eventually, and if I have time. But I definitely think that ignoring that part completely has allowed me to get it to an MVP state.
The right operator for unit conversions is "in." "to" is used for ranges, so it's doing 100 euros _goes to_ 1 us dollar and giving you back the answer in dollars.
But it seems the parser is breaking when trying to do the inverse, anyway: "100 usd in eur" seems to do "e*ur" and gives "Values must be converted to units."
