4 ms·

> that you could directly query To take it even further, the language grammar could be a superset of the SQL grammar. > Would it have to be a scripted languag

> that you could directly query To take it even further, the language grammar could be a superset of the SQL grammar. > Would it have to be a scripted language? Not at all. It's just the first thing which came to mind. I'm tickled by the idea of having the entire program state (stack frames and all!) in SQLite so that you could ship a snapshot of your program around. > There would be overhead compared to directly managing memory. Of course, but if the critical queries were pre-compiled via sqlite3_prepare, I doubt the overhead would so greatly exceed the memory management overhead in language runtimes which ship with a GC that it would be a show-stopper.

Imustaskforhelp 2y ago
wow the idea of shipping a snapshot is also crazy good , bookmarking your comment as well the parent comment as well. Because snapshotting is a rather crazy thing which have to be managed by criu or qemu this could even be faster than a vm shipped. MY goal with snapshots can be literally anything (yet , I like the idea of extraction snapshots for extremely large files very lucrative idea)
- acuozzo 2y ago
  Thank you! Considering this further... I think Lua might be a good match for this idea. Everything it can do can be pretty easily mapped to SQLite queries and its type system is pretty close to the limited set of types offered by SQLite.
  - Imustaskforhelp 2y ago
    yup , I was actually looking at the tglite bytecode engine. I am really interested in this project. My thought was about arturo lang though https://arturo-lang.io/ https://arturo-lang.io/ since it has https://github.com/arturo-lang/grafito https://github.com/arturo-lang/grafito , and it just felt like having a better integration with sql though lua is also fine. We can also integrate this directly to something like lua running on sqlite compiled by cosmopolitan project to even ship a cross platform single executable sqlite. The possibilites are endless. If you are genuinely interested in this project. I am willing to help in my free time. But I am a novice and I don't have experience in low level langauges like C/rust and much prefer golang.
- knome 2y ago
  While not serialized to a database, memory-dump/snapshot based distribution was done with smalltalk and various lisps. Basically dump the gc and the executable just reloads it right into RAM. Wasn't the best from what I've read over time. Having an SQL based callstack sounds painfully slow.
  - acuozzo 2y ago
    > Having an SQL based callstack sounds painfully slow. It could be, but this aspect of the idea could also be user-togglable at runtime.
  - igouy 2y ago
    > Wasn't the best from what I've read over time. Because?
    - knome 2y ago
      I don't have references, just bits of notion from reading various accounts of things online over the years. Most of the software that was distributed as an image would also run as an image and stop by saving that image down to the disk. This could lead to persistent difficult to debug errors (imagine a random RAM bit flip getting persisted into the image) that couldn't be recreated because they only existed on that one clients machine. Each customer was effectively modifying their versions as they ran and saved and reloaded the software, and the as seller was contracted to make local modifications for them, so the install base would diverge over time. There was no central or single source to rebuild the program from. Turning it off and on again just reloaded the saved bugs.
      - igouy 2y ago
        > just bits of notion from reading various accounts of things online over the years And that casts shade. > Most of the software … would … stop by saving that image down to the disk. Not so. Fat-client apps for corporate DBs. > There was no … source to rebuild the program from. Not so. I'll leave you to read a 1984 manual, page 459: https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... > … just reloaded the saved bugs. Let's pretend that someone had made "bad" changes and saved them in their current image file, and they had not archived their other changes. They would be able to recover all their "good" changes without the "bad" changes because their changes were automatically recorded in a transaction log file. They could replay the "good" changes from the changes log into an original image file, and not replay the "bad" changes.

Imustaskforhelp 2y ago

wow the idea of shipping a snapshot is also crazy good , bookmarking your comment as well the parent comment as well. Because snapshotting is a rather crazy thing which have to be managed by criu or qemu this could even be faster than a vm shipped. MY goal with snapshots can be literally anything (yet , I like the idea of extraction snapshots for extremely large files very lucrative idea)

acuozzo 2y ago
Thank you! Considering this further... I think Lua might be a good match for this idea. Everything it can do can be pretty easily mapped to SQLite queries and its type system is pretty close to the limited set of types offered by SQLite.
- Imustaskforhelp 2y ago
  yup , I was actually looking at the tglite bytecode engine. I am really interested in this project. My thought was about arturo lang though https://arturo-lang.io/ https://arturo-lang.io/ since it has https://github.com/arturo-lang/grafito https://github.com/arturo-lang/grafito , and it just felt like having a better integration with sql though lua is also fine. We can also integrate this directly to something like lua running on sqlite compiled by cosmopolitan project to even ship a cross platform single executable sqlite. The possibilites are endless. If you are genuinely interested in this project. I am willing to help in my free time. But I am a novice and I don't have experience in low level langauges like C/rust and much prefer golang.
knome 2y ago
While not serialized to a database, memory-dump/snapshot based distribution was done with smalltalk and various lisps. Basically dump the gc and the executable just reloads it right into RAM. Wasn't the best from what I've read over time. Having an SQL based callstack sounds painfully slow.
- acuozzo 2y ago
  > Having an SQL based callstack sounds painfully slow. It could be, but this aspect of the idea could also be user-togglable at runtime.
- igouy 2y ago
  > Wasn't the best from what I've read over time. Because?
  - knome 2y ago
    I don't have references, just bits of notion from reading various accounts of things online over the years. Most of the software that was distributed as an image would also run as an image and stop by saving that image down to the disk. This could lead to persistent difficult to debug errors (imagine a random RAM bit flip getting persisted into the image) that couldn't be recreated because they only existed on that one clients machine. Each customer was effectively modifying their versions as they ran and saved and reloaded the software, and the as seller was contracted to make local modifications for them, so the install base would diverge over time. There was no central or single source to rebuild the program from. Turning it off and on again just reloaded the saved bugs.
    - igouy 2y ago
      > just bits of notion from reading various accounts of things online over the years And that casts shade. > Most of the software … would … stop by saving that image down to the disk. Not so. Fat-client apps for corporate DBs. > There was no … source to rebuild the program from. Not so. I'll leave you to read a 1984 manual, page 459: https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... > … just reloaded the saved bugs. Let's pretend that someone had made "bad" changes and saved them in their current image file, and they had not archived their other changes. They would be able to recover all their "good" changes without the "bad" changes because their changes were automatically recorded in a transaction log file. They could replay the "good" changes from the changes log into an original image file, and not replay the "bad" changes.