<pablo_escoberg>
aw: thanks much. I had a look at the code, and it does exactly what I'm trying not to do, which is fork a new process for every query. That will, per abu[7], slow the thing down by about 2 orders of magnitude, which is fine for some applications but not for mine. So I'm slogging through controlling the thing with named and/or unnamed pipes. I have a lot of playing around and many tantrums (tantra?) ahead of me, but I'm pretty conf
<pablo_escoberg>
ident I'll have a working, performant sqlite3 frontend within the next few weeks (which, I know, is a dangerous thing to put in writing :D).
<aw->
pablo_escoberg: i highly doubt forking is that big a problem in 99% of use-cases
<aw->
if it is then your application or DB queries should be re-architected, or you should switch to a client/server database like MySQL or Postgres
<aw->
it uses mkfifo to create named pipes under a parent process, and then child processes read/write to that pipe
<abu[7]>
Named pipes may indeed be easier
<abu[7]>
In PilBox they are used too, to communicate with the Android JVM
pablo_escoberg has quit [Remote host closed the connection]
pablo_escoberg has joined #picolisp
<pablo_escoberg>
aw: I appreciate the advice, and you are most likely right. Thing is, I need this thing to be able to scale vertically with little warning, and eliminating this kind of bottleneck ahead of time is kind of critical for that. Plus, TBPH, I am not in a hurry and prefer to have the most elegant solution out of the gate (even at the risk of premature optimization).
<pablo_escoberg>
abu[7]: Yeah, I am pretty sure named pipes are the way to go. So now I need to play with pipe, in, input, out, output to see which is most appropriate to the task. I'm still a bit confused by the docs...
<abu[7]>
The reference is very terse. Just ask.
<pablo_escoberg>
much appreciated. Can you give me a quick primer on the difference between in, input, out, output ?
<abu[7]>
input and output are "between", a kind of intermediate proceccors
<pablo_escoberg>
BTW, after this whole thing I may write a quick primer on process automation :D
<abu[7]>
For now, 'in' and 'out' are important
<abu[7]>
Any docs are welcome :)
<pablo_escoberg>
Of course. They've improved dramatically over the past few years. TBH, I kind of fell in love with picolisp 4 years ago but abandoned it for lack of documentation. Came back a couple weeks ago and found that the docs will now probably get me through, with some help, which I seem to be getting :D. I will definitely pass it forward.
<pablo_escoberg>
It feels like the secret I seek is entombed therein, waiting to be unlocked by the part of my brain that refuses to work right now :D
<abu[7]>
This example is useful only for communication between Pil processes, as it uses the PLIO format ('pr' and 'rd')
<abu[7]>
or, 'tell' in this case
<abu[7]>
so strictly pil rpc
<pablo_escoberg>
Not sure what that means, but my hope had been to make both pil processes the same process and stick a sqlite client in between.
<abu[7]>
You can use PLIO though also with non-picolisp, but then it needs a lib
<pablo_escoberg>
Seems plausible on it
<pablo_escoberg>
's face...
<abu[7]>
eg. on Android it is InOut.java
<pablo_escoberg>
Well, this is intended for server processes, so I'll keep playing with various pipe configurations for now. If it doesn't work out, I found a pretty comprehensive doc on the sqlite API which I think I can use to build an interface that way. I still hope to be able to bypass all that cleverly, though :D
<abu[7]>
Is it a C API?
<pablo_escoberg>
is what a what? Sorry, no idea what that question means...
<pablo_escoberg>
So given the sqlite C lib interface, I figure this shouldn't be rocket science.
Abhishek_ has joined #picolisp
<abu[7]>
Oh, "more than 225 APIs" ;)
<pablo_escoberg>
The reason I chose to try pipes first is that it's a lot more terse, a lot more elegant, and should require almost no maintainance.
<abu[7]>
Indeed, a C interface is probably the easiest and most stable way
<pablo_escoberg>
and yes, 225 API's is not something I want to deal with, though I imagine it's only about a dozen or so I'd need.
<pablo_escoberg>
Really? I'm thinking a C interface is less stable and less easy.
<pablo_escoberg>
I'm pretty sure unix names pipes have been a stable interface for longer than sqlite has even existed...
<abu[7]>
Depends
<pablo_escoberg>
and yes, it always depends :D
<abu[7]>
yes, that's true
<pablo_escoberg>
I'd love to hear the pro C API argument
<abu[7]>
It is more strict than a text interface via pipes
<pablo_escoberg>
my primary anti arguments: It's prone to change, and it's 225 API's, out of which I'll need to extract the (hopefully) right dozen or so.
<pablo_escoberg>
definitely more strict, but given the design choices you've made, I'm surprised you consider that an advantage
<abu[7]>
It is best to try both ways in parallel
<pablo_escoberg>
True, and I did say I wasn't in a hurry :)
<abu[7]>
I think I'd go with a C API if I have the choice
<pablo_escoberg>
just intuitively, or can you articulate why?
<abu[7]>
I believe it avoids some interpretation overhead
<abu[7]>
At least it should
<abu[7]>
of course, SQL always involves interpretation on the server side
<pablo_escoberg>
you're probably right. So it's a question of, at least in theory, a trade off between interface stability and performance.
<abu[7]>
And the API probably also uses sockets or pipes
<abu[7]>
... and of easiness
<pablo_escoberg>
Good point. So there may not even be any performance tradeoff.
<abu[7]>
The performance bottlenecks are probably on the server anyway
<pablo_escoberg>
easiness, I suppose. It ends up with less code, which I consider easier.
<abu[7]>
yes
<abu[7]>
simpler
<pablo_escoberg>
Even though there is pipe wrangling, etc. I never really learned APL, but I really appreciate the ethos. I like being able to see my entire code base on one screen if possible. And I could see this whole thing being less than 100 lines of code, as to opposed to the C API, which is probably closer to 500.
<pablo_escoberg>
Oh, and my eyes are getting old, so less code fits on a screen now :D
<abu[7]>
Same here :)
<abu[7]>
Not so much the eyes, but my small screen
<pablo_escoberg>
Good for you!
<pablo_escoberg>
IAC, I'll keep playing around. If nothing else, I'll gain a pretty strong knowledge of Pil in the process. But I hope to be able to contribute a working sql db interface with a working sqlite driver soonish, along with some docs.
<abu[7]>
cool
<abu[7]>
I'll release a new PilBox now
<pablo_escoberg>
Great! I've been playing with that a bit, too.
<pablo_escoberg>
In parallel with the whole sqlite thing, I'm building myself a silly sound effects app, since all the ones out there suck :D
<abu[7]>
Nice! For PilBox?
pablo_escoberg has quit [Quit: Leaving.]
pablo_escoberg has joined #picolisp
<abu[7]>
Is it for musicians?
razzy has quit [Ping timeout: 240 seconds]
razzy has joined #picolisp
razzy has quit [Quit: leaving]
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
pablo_escoberg has quit [Ping timeout: 240 seconds]
pablo_escoberg has joined #picolisp
seninha has quit [Quit: Leaving]
razzy has joined #picolisp
<razzy>
i forgot how to directly edit database symbols.
<abu[7]>
You can directly edit symbols (database or not) by passing as a list to Vip
<abu[7]>
or use 'v' as a non-evaluating convenience
<abu[7]>
(v {A7} {X123})
<abu[7]>
same as
<abu[7]>
(vi '({A7} {X123}))
<abu[7]>
Be careful only to write changes if you are absolutely sure all relations are correct
razzy has quit [Ping timeout: 240 seconds]
pablo_escoberg has quit [Ping timeout: 240 seconds]
pablo_escoberg has joined #picolisp
<pablo_escoberg>
abu[7]: Yes, for Pilbox. It's just a stupid little project to get started with Pilbox. Basically, I'm a childish idiot, and want the ability to pull out my phone for a quick rim shot, whip sound, or some such. All the apps out there are slow, bloated, and have ads. I'm hoping I can use Pilbox to build something reasonably performant. If not, I'll need to go with e.g. Flutter, but will at least have gotten to know Pilbox in the p
<pablo_escoberg>
rocess.
pablo_escoberg has quit [Quit: Leaving.]
pablo_escoberg has joined #picolisp
<abu[7]>
Nice!
<pablo_escoberg>
Thanks. So here's a new issue I just realized with my automation idea: I still need different threads to process input and output. Does Picolisp have any threading mechanism? If not, looks like my idea won't work because I'll still need to fork every time I do output.
pablo_escoberg has quit [Quit: Leaving.]
pablo_escoberg has joined #picolisp
<abu[7]>
Driving home from airport
<abu[7]>
ret
<abu[7]>
The best is a 'task' at the receiving side
<abu[7]>
This avoids also the problem of synchonizing writes and reads
<abu[7]>
A very simple example for such a task is in @bin/pty