<pablo_escoberg>
Hey folks, more apologies, more stupid questions: When editing with (vi 'any), saving and quitting does not appear to reload the code. In a previous version, one would run (ld) after using the external vim, but now there is nothing in the docs that would indicate that such a thing should be necessary, nor what it is. What am I missing? Thanks again...
pablo_escoberg has quit [Quit: Leaving.]
pablo_escoberg has joined #picolisp
chexum has quit [Ping timeout: 240 seconds]
chexum has joined #picolisp
<aw->
pablo_escoberg: hi
<aw->
sorry i can't help with that, i think you'll need to wait for abu[m] to wake up
<aw->
pablo_escoberg: if you wait a bit, i will publish my source code where i interfaced picolisp with sqlite
<aw->
it's been in private use for many years (6 or 7 years actually)
<aw->
it's not a HUGE complicated thing, but somewhat generic enough to be used in your own projects
<aw->
i'll write the documentation later, gotta run now bbl
<pablo_escoberg>
Wow! Thanks! I'll have a look.
<abu[m]>
Hi pablo_escoberg! You can do ":l" in Vip to load the file in the current buffer
<pablo_escoberg>
Thanks, but that's not my issue. My issue is that I use e.g. (vi "x.pil") or (vi '+X), save, exit, and the changes I've made are not reflected.
<abu[m]>
You mean the file is not written at all?
<pablo_escoberg>
Nope, file is written. If I exit and restart, changes are reflected.
<pablo_escoberg>
prior to vip, ISTR having to run (ld) to load changes
<pablo_escoberg>
now, not sure...
<abu[m]>
I see
<abu[m]>
I thought (ld) is not needed, as :l does the same thing
<pablo_escoberg>
hmmm... let me check.
<abu[m]>
Because vip runs in the same process (as opposed to Vim which is a separate process)
<pablo_escoberg>
right! That's why I was so surprised that my changes weren't reflected in the REPL as soon as I exited.
seninha has quit [Ping timeout: 260 seconds]
<abu[m]>
Do you know that you can put the editor into the background with "qz"?
<pablo_escoberg>
That's what I thought would happen, and when it didn't, I started scouring the docs and couldn't find anything
<abu[m]>
hmm
<pablo_escoberg>
Interesting. Not sure it's relevant. Going to play with :| and see if that does it.
<pablo_escoberg>
nope, edits still show up in the file, but don't show up in the REPL. REALLY weird...
<abu[7]>
You did : (vi 'foo) in the pil REPL?
<abu[7]>
Then :l to save and load it?
<abu[7]>
then "qz" to pause Vip
<abu[7]>
and then : (pp 'foo) ?
<pablo_escoberg>
I also did a :w, but did not do a qa
<pablo_escoberg>
qz*
<pablo_escoberg>
rather just a :q
<pablo_escoberg>
which is what I want
<abu[7]>
:q quits witxout saving
<pablo_escoberg>
right, but I did a :w first
<abu[7]>
(no complains like in Vim)
<abu[7]>
ok
<pablo_escoberg>
so I did :w then :| then :q
<abu[7]>
And :l does :w implicitly
<pablo_escoberg>
and changes weren't reflected
<pablo_escoberg>
then I did ^D, re-entered, and changes were there
<abu[7]>
Strange. I just tried here and it showed the change with (pp 'foo)
<abu[7]>
after (vi 'foo)
<pablo_escoberg>
I used (show '+Sql). That shouldn't make a difference, right?
<pablo_escoberg>
is it that I am defining classes??
<abu[7]>
correct
<abu[7]>
Wait, perhaps it a namespace issue?
<pablo_escoberg>
Not using (symbols...
<abu[7]>
It might be loaded in the wrong namespace?
<pablo_escoberg>
then (vi '+Sql), add a method, (show '+Sql) and the method is not there. Then ^D, "pil sql.pil +" (show '+Sql) and it's there
<pablo_escoberg>
likewise if I remove a method or make any other change. It's really weird.
<abu[7]>
What if you do an explicit (load "file.l")?
<pablo_escoberg>
so (vi '+Sql), make some changes, (load "sql.pil) and see what happens?
<abu[7]>
yes
<pablo_escoberg>
I'll give it a shot. brb
<abu[7]>
I think re-loading class definitions may be a general problem
seninha has joined #picolisp
<abu[7]>
no, forget that. Such problems were fixed with pil21
<pablo_escoberg>
hmmm... getting some weird behavior. Probably my fault. Still playing...
<pablo_escoberg>
still doesn't seem to be updating. Getting errors I wasn't getting before, but not updating from vip.
<abu[7]>
Can you first try with simple functions, not class definitions? I'm not sure about side effects of class modifications
<abu[7]>
I must say that I usually don't reload E/R files
<abu[7]>
... but still, I think they should also be OK
<pablo_escoberg>
OK, cool. Seems it's a semi-known issue. I guess I won't use that workflow.
<pablo_escoberg>
perhaps the next version will have a better-than-emacs vip with full integration and all that. Very much looking forward to it. Until then, I'm thinking gvim and lots of reloads :D
<abu[7]>
I think it should be fine. Just did not remember at the moment about how it was fixed
<pablo_escoberg>
What was fixed?
<abu[7]>
The problems of loading class definitions
<pablo_escoberg>
Oh, well, in that case, happy to help debug, because it isn't working for me and I'd love it if it were...
<abu[7]>
Fixed in June 21
<pablo_escoberg>
June of 2021?
<pablo_escoberg>
I'm using 23.6.6 now...
<abu[7]>
yeah
<abu[7]>
So it should not be the problem
<pablo_escoberg>
hmmm... anything I can do to help debug, or should I just grin and bear it until the next release?
<abu[7]>
I'd really like to know what the problem is
<abu[7]>
Can you test a simple case?
<abu[7]>
Edit a single function?
<abu[7]>
(vi 'foo) :l qz (pp 'foo)
pablo_escoberg has quit [Quit: Leaving.]
<pablo_escoberg>
I'm fine with the latter option, BTW. This is an awesome platform and I won't let a couple of weird bugs scare me away.
pablo_escoberg has joined #picolisp
<abu[7]>
I don't think there is a bug. I use it all day long
<abu[7]>
Perhaps we are talking of different aspects?
<pablo_escoberg>
hmmm.... then anything I can do to help figure out what I'm doing wrong?
<abu[7]>
Try a simple stand-alone case
<pablo_escoberg>
ok, 1 sec
<abu[7]>
$ ./pil foo.l +
<abu[7]>
: (vi 'foo)
<abu[7]>
etc
<abu[7]>
The only thing I can imagine that you perhaps have some special namesspace setup. Do you use namespaces?
<abu[7]>
So that the load ends up in the wrong namespace
<pablo_escoberg>
ok, so I created a file called foo. Contents of the file: 1 line: de foo (x) prinl x)
<abu[7]>
good
<pablo_escoberg>
then, from the command line "pil foo"
<pablo_escoberg>
sorry, "pil foo +"
<abu[7]>
T
<pablo_escoberg>
Then (vi 'foo)
<pablo_escoberg>
added the following line: de bar (u) prinl u)
<pablo_escoberg>
Then, :w and :q
<pablo_escoberg>
then (show 'bar)
<abu[7]>
ah!
<pablo_escoberg>
NIL NIL
<abu[7]>
Not :w
<abu[7]>
You need :l
<abu[7]>
:w just writes
<pablo_escoberg>
ok, let me try that
<abu[7]>
:l does a write and a load
<pablo_escoberg>
yup, that did it. So looks like it's an E/R thing.
<abu[7]>
cool
<pablo_escoberg>
ok, so different workflow for these things for now. Thanks again for all the help.
<abu[7]>
I would like to know which modification gos wrong
<abu[7]>
'class' now clears the whole symbol
<abu[7]>
so all changes should be there
<abu[7]>
also removals of methods which did not work before 2021
<abu[7]>
21.6.1 in @doc/Changelog
<abu[7]>
'class' clears old method and var definitions
<pablo_escoberg>
hmmm... ok, I'll play around some more.
<abu[7]>
Thanks!
<abu[7]>
Would be nice if we fix a bug
<pablo_escoberg>
Least I can do. You guys are awesome.
<pablo_escoberg>
Yup, really seems to be E/R related.
<pablo_escoberg>
Very generic, added a method in vip from the repl, change not reflected even after :|
<pablo_escoberg>
trivial to reproduce here...
<abu[7]>
Hmm, is this a font issue? Looks like colon-verticalbar
<abu[7]>
not colon-ell ?
<pablo_escoberg>
LOL! Yes, I was using the pipe character. It's supposed to be :l for "load"???
<abu[7]>
Vip should beeb upon :|
<abu[7]>
yeah :)
<pablo_escoberg>
no beep...
<pablo_escoberg>
ok, let me give it another try. This is some really funny shit...
<abu[7]>
In fact I have no beep either, but my phone vibrates ;)
<pablo_escoberg>
OK, fucking font issue. Add that to your "impossible bug solved in ridiculous way" file.
<abu[7]>
haha ☺
<pablo_escoberg>
:{ell} FTW!
<abu[7]>
But for non E/R cases it worked?
<pablo_escoberg>
yes, just :w and :q apparently, since :{pipe} doesn't do anything :D
<abu[7]>
In any case, we have some progress :)
<pablo_escoberg>
absolutely. I am a recent convert and I have to say, the fact that this platform isn't everywhere is a total crime. It's utterly beautiful.
<pablo_escoberg>
And the way it's going, I'm pretty sure ~2ish years from now it will make Emacs + SLIME look absolutely silly.
<abu[7]>
Thanks! I'm very glad to hear that
<pablo_escoberg>
are you the original dev??
<abu[7]>
yes
<pablo_escoberg>
hats off, and I owe you many beers next time I'm in your neck of the woods.
<pablo_escoberg>
Somewhere in Germany, right?
<abu[7]>
Yes. A beer would be cool!
<abu[7]>
You seem in another time zone
<abu[7]>
more west?
<pablo_escoberg>
Santa Barbara, California.
<abu[7]>
a bit tough with the beer
<pablo_escoberg>
Not really. I'll be in Europe soon.
<abu[7]>
Nice!
<pablo_escoberg>
Where in Germany are you?
<pablo_escoberg>
I need to get to Berlin and Munich.
<pablo_escoberg>
friends in both places...
<abu[7]>
I'm near Augsburg, 70 km west of Munich
<abu[7]>
Next week I'm in Berlin
<pablo_escoberg>
Awesome. I'll be in touch!
<abu[7]>
I was born in Berlin, and my daughter lives there
<pablo_escoberg>
Love that town!
<pablo_escoberg>
And curry wurst is the bomb :D
<abu[7]>
:)
<abu[7]>
It is a very creative city
<pablo_escoberg>
Yeah. Munich is great too. A good friend of mine has a (I think) Michelin star restaurant there.
<pablo_escoberg>
But frequented his last restaurant, in Buenos Aires.
<abu[7]>
Sushi
<pablo_escoberg>
Fusion. He made the best fish tacos I've ever had.
<pablo_escoberg>
My wife and I are still talking about them 15 years later :D
<abu[7]>
Got a customer request. Busy for a while.
<abu[7]>
Let's talk later
<pablo_escoberg>
Absolutely. Thanks again.
<abu[7]>
:)
<abu[7]>
Must be after midnight in California?
<abu[7]>
no, 23 h
<abu[7]>
ok, anyway ...
<pablo_escoberg>
yup. Take care of your customers, and I'm sure I'll have plenty of stupid questions soon :D
<abu[7]>
Good, I'm looking forward for the questions
pablo_escoberg has quit [Remote host closed the connection]
pablo_escoberg has joined #picolisp
pablo_escoberg has left #picolisp [#picolisp]
pablo_escoberg has joined #picolisp
rob_w has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
seninha has quit [Read error: Connection reset by peer]
seninha has joined #picolisp
rob_w has quit [Remote host closed the connection]
pablo_escoberg has quit [Ping timeout: 252 seconds]
pablo_escoberg has joined #picolisp
seninha has quit [Quit: Leaving]
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
pablo_escoberg has quit [Quit: Leaving.]
pablo_escoberg1 has joined #picolisp
seninha has joined #picolisp
pablo_escoberg1 has quit [Quit: Leaving.]
pablo_escoberg has joined #picolisp
<pablo_escoberg>
OK, stupid question of the (early part of) the day: AFAICT, every time I run the line: (=: fd (unless (fork) (pipe (exec (pack "echo '.read \" | cat ./in \"' | sqlite3 " Fn " > out"))))) the REPL becomes sluggish. Am I accidentally causing some kind of folk bomb? It doesn't seem to affect the rest of my system, but I could be wrong...
<pablo_escoberg>
<abu[7]>
Hmm, at least it forks once too much
<abu[7]>
'pipe' also forks internally
<abu[7]>
And 'exec' needs an executable
<abu[7]>
what you pass is rather a shell command line
<abu[7]>
(exec "sh" (pack ...)) would make more sense
<abu[7]>
I think you just need an 'in' or 'out'
<abu[7]>
Ah, no, you want it bi-directional
<pablo_escoberg>
ah, thanks. I'll give it a shot when I get a chance, probably this afternoon. And yes, the in and out come in the query method
<abu[7]>
(=: fd (pipe (exec "sh" ...)))
<pablo_escoberg>
for now it looks like:(dm query> (QueryStr)
<pablo_escoberg>
(setq result (in fd (read)))
<pablo_escoberg>
)
<pablo_escoberg>
(out fd QueryStr)
<pablo_escoberg>
(prinl result)
<pablo_escoberg>
until I can make it work
<pablo_escoberg>
obviously, that's not supposed to be a smilie :D
<abu[7]>
As I wrote to aw- the day before yesterday, the difficult point with such a pipe is flushing
<abu[7]>
You must be sure the pipe'd process does a flush after sending a piece of data
<pablo_escoberg>
hmmm... is that a big issue? Should I try using e.g. input and output instead?
<abu[7]>
Otherwise the whole thing blocks
<pablo_escoberg>
well, so far, my experiments with sqlite on the command line have worked...
<pablo_escoberg>
but I haven't played with it too much.
<abu[7]>
Perhaps for the beginning do single-shot commands
<abu[7]>
(in (list "sql" "select" ...) (line) ...
<pablo_escoberg>
You mean fork every time? That's what I'm trying to avoid.
<abu[7]>
yes, but it could be a later speed up
<abu[7]>
if the fork is really such an overhead
<pablo_escoberg>
right. the thing is, the whole point of the thing is to automate sqlite with pipes.
<abu[7]>
ok
<pablo_escoberg>
If I was willing to live with the forking overhead, I'd be done.
<abu[7]>
For example, the 'mail' function uses such a persistent pipe
<pablo_escoberg>
Great! I'll have a look at that. Probably has all the code I need.
<abu[7]>
but the process is @bin/ssl which is under full control
<pablo_escoberg>
awesome! Thanks again. I'll dive into that code and see what I can accomplish.
<abu[7]>
ok
pablo_escoberg1 has joined #picolisp
pablo_escoberg has quit [Quit: Leaving.]
seninha has quit [Quit: Leaving]
seninha has joined #picolisp
<aw->
pablo_escoberg1: i've uploaded a README.md which explains how to actually use the sqlite/db code I published yesterday: https://github.com/aw/picolisp-sqlite
<aw->
that should be a bit more helpful
pablo_escoberg1 has quit [Ping timeout: 258 seconds]