SQLite is >< close to becoming the lingua franca for all next-generation ideas
Queryable Executables
51–60 of 83 posts
Re: Queryable Executables
#52Neat stuff. I’m sold! Could the webserver receive a code segment from the web and add it to itself (like a plugin upload)?
You can think further, you can build a no-server server; Example let Nginx be running, then forward requests to the database, running the code, query data and responding then shutting down again. Need the service to do something regularly, just trigger that part of the database through crontab.
And yes you can let authorized users add custom code, make it run in the database like a micro-micro-vm and do stuff on triggers etc in the database as well.
This makes it even more powerful, because users can switch code during runtime and you can have multiple users "programming" against the same database at the same time working against the same data.
Re: Queryable Executables
#53Earlier quoted context omitted.
$ cp /original/binary.app /new/binary.app && /new/binary.app Makes sense to me. Also for production, I would have the app change its name by adding a datetime to the filename, indicating when it was last synchronized. This is a very appealing idea, I too hope it gets 1000% more attention and adoption.
There are applications where you want to run multiple instances but also want to have them use shared state, e.g. for their preferences (editable via their UI). Or think of an editor or something like Excel. You probably don’t want the files you edit to all be stored in the binary and require separate export/import functions for sharing, or for editing using alternative applications. And in the end, that goes for pre…
local appConfig[myUniqueArgv0] = { .. some config data .. }
Re: Queryable Executables
#54>I’m amazed how much collapses into a single domain: SQL. perhaps is more correct to say "all data, including code, is table-representable, even though being a graph" or "everything falls back to tables" or even "relational algebra is all u need", but I strongly disagree SQL being a domain on its all, and that it (all) collapses into such domain. One can collapse segment tables likewise into DATALOG, which is also a…
It's interesting how different people fall into different "everything is a hammer" perspectives. I have a bunch of people around who do the same, everything collapses into table-like structures, but personally I always end collapsing everything into a tree, one way or another. Any problem I encounter, my brain seems to just default into "Yeah, arranged this way, this is clearly just a tree", and it keeps happening fo…
I'm sure you've stumbled upon graphs that are not trees, which can be represented with tables.
Re: Queryable Executables
#55Earlier quoted context omitted.
I think its really cute that SQlite is used as the container format - but my mind wanders to other things used in the same way. One of my favourite ways to develop apps is to use Lua - for everything. Construct an efficient core application framework, then embed the Lua VM in it, and then do all program logic and control flow in Lua, then put the Lua bytecode in the binary with luastatic, and off we go. So this techn…
> One of my favourite ways to develop apps is to use Lua - for everything. Construct an efficient core application framework, then embed the Lua VM in it, and then do all program logic and control flow in Lua, then put the Lua bytecode in the binary with luastatic, and off we go. Okay, you have to expand on this. Do you have a blog post or anything that goes into more detail?
I don't have an article or blog post, alas.
Basically, take your application framework of choice - in my case its JUCE (C/C++) - and embed a Lua VM in it. Put the UI in the framework, and then encode all of the program logic and application control flow in Lua, which marshals the UI and the rest of the system through the VM interface.
Sure, you can just 'do everything in C/C++', but I've found that for long-term projects, doing app logic in Lua, a simpler language to wrangle, has been very fruitful. And, it puts the framework in an interesting context - serving the VM - which reduces bugs and keeps things pretty tidy. Most of the C/C++ code is just UI and system-level scaffolding - which I then write Lua tests for - and then once this is in place, the app logic is very productively developed and shipped as byte code. The App becomes a host for the logic.
Re: Queryable Executables
#56Where this approach might shine right now is .o/.obj files for assemblers/compilers/linkers. Instead of using COFF/ELF/whatever binary voodoo, a relational DB container makes most of the previously hard things trivial, including optional vendor extensions.
This would be a super pragmatic approach for a modern compiler suite. This is the brilliant part of the whole idea.
Re: Queryable Executables
#57i still don't understand what it does. Can someone ELI5? I've read both articles, still clueless.
[deleted]
Re: Queryable Executables
#58Earlier quoted context omitted.
It's interesting how different people fall into different "everything is a hammer" perspectives. I have a bunch of people around who do the same, everything collapses into table-like structures, but personally I always end collapsing everything into a tree, one way or another. Any problem I encounter, my brain seems to just default into "Yeah, arranged this way, this is clearly just a tree", and it keeps happening fo…
I'm sure you've stumbled upon graphs that are not trees, which can be represented with tables.
But on the other hand table are represented with trees![1]
[1]: https://en.wikipedia.org/wiki/B-tree#B-tree_usage_in_databas...
Re: Queryable Executables
#59I wonder if the interpreter could create a mount namespace and mount virtual filesystems backed by the SQLite database itself, so you wouldn’t need source changes to self-contain (ha!) file accesses.
People have created FUSE filesystems backed by SQLite before, but I don’t see how you’d get much unique value out of an RDBMS as filesystem if you’re only interacting with is through a traditional non-transactional byte stream API.
Vendors who have done this like IBM with the AS/400 have typically put the database APIs front and center in their sales pitches, and POSIX on AS/400 is more akin to WSL than something well-integrated into the traditional single-level store (or at least was a few years ago when I last took a look at it).
Re: Queryable Executables
#60SQL over ELF headers is clever. Debug symbol lookups alone would save me a ton of grep piping.