<geri>
hey, do we have anything to connect to AF_UNIX sockets?
<geri>
(probably not...)
<abu[7]>
Only what is in @lib/net.l
<abu[7]>
No AF_UNIX
<geri>
do i gotta like clone the port function, adjust the values for AF_UNIX and pray? :D
<abu[7]>
I have not investigated, What do you need them for?
<geri>
you can talk to a running MPV player instance via ipc, ive made a music player using that fact and wanted to know if i'd be able to do it with pure picolisp instead of sh + socat + jq or cl with a json library
<geri>
(yes im stupid)
<abu[7]>
No, a valid idea
<geri>
:D
<geri>
its real fun too
<geri>
its really cool i technically can do it with pico if i know C well enough, although it sucks that i dont know it well enough
<geri>
so i guess ill have to scour through all of net lib
<abu[7]>
The network stuff is really tedious
rob_w has joined #picolisp
<geri>
i kinda know already, but not on the same level
<abu[7]>
I'm also not good at that
<abu[7]>
Took most from existing examples
<geri>
do you use pil scripts with vi's !! operator?
<geri>
just curious
<abu[7]>
Yes, sometimes. Why not? There is nothing special.
<geri>
why not indeed
<geri>
on my system pil scripts are between dash and bash performance wise
<geri>
closer to dash, but you cant compare usability of dash to a lisp
<abu[7]>
there is also miniPicoLisp and ErsatzLisp
<geri>
oh right
<geri>
wait, did you write miniPico too?
<abu[7]>
T
<geri>
xd
<geri>
"NOT ENOUGH MINIMALISM!!!"
<abu[7]>
:)
<geri>
i can relate
<geri>
if a function is defined to only take one function and 2 are passed, second one is completely ignored right?
<geri>
it seems so, just want to confirm :D
<abu[7]>
Superfluous arguments in general are ignored, missing args are bound to NIL
<geri>
its nice to not eval extra stuff
<geri>
and no need for optionals if everything is optional :D
<abu[7]>
Yay
<abu[7]>
The callee can decide what to do with the NILs
<geri>
interesting that most builtins seem to only take a single any as an argument
<geri>
i guess any x in this case means any arguments, any amount, any type
<abu[7]>
As I said, they are *all* FSUBRs
<abu[7]>
they take the list of unevaluated args
<abu[7]>
*all*
<geri>
explicit eval everywhere!
<abu[7]>
T
<geri>
i remember that fexpressions are hard to make compile efficiently, is it because evals are hard to compile efficiently? (iirc)
<abu[7]>
It is because FEXPRs get their code-argument(s) as data which cannot be well compiled statically. I think this has nothing to do with 'eval' per se.
<geri>
just managed to find anything on the web related to fexprs xd
<geri>
so basically as far as i understood - they were present in mac and inter lisps but were "deprecated" because its easier to compile macros efficiently
<abu[7]>
Ok, and FSUBRs are the built-in equivalents
<abu[7]>
Yes, I think so too
<geri>
whats the difference between fexprs and fsubrs?
<abu[7]>
FSUBRs are built-in (low level)
<abu[7]>
llwm or C
<geri>
hm
<abu[7]>
Same behavior
<geri>
okay
<geri>
had performance changed much since rewrite from assembly to llvm?
<abu[7]>
Not really
<geri>
but you get to write pico in itself
<geri>
:D
<abu[7]>
yes, and more portable most of all
<geri>
like itd work on risc-v?
<abu[7]>
yes, there is a problem on RISC-V, it does not have a condition code register
<abu[7]>
Pil64's vm needed a CCR
<geri>
new one doesnt?
<abu[7]>
LLWM-IR has a kind of carry flag and overflow mechanisms which is enough
<beneroth>
hi geri & abu :)
<geri>
hello
<abu[7]>
Hi beneroth!
<beneroth>
geri, FEXPR are interpreters in itself. so cannot be compiled because you don't know what they will do until you call them with arguments (and the arguments then influence their behavior)
<geri>
so the journey with main version is like "C so that it works" > "Assembly so it's fast" > "LLVM so it's fast and written in itself!" ?
<geri>
:D
<beneroth>
theoretically they could be compiled if you would know all possible arguments in your program. but if some of these arguments come from user input..then impossible
<geri>
(and portable)
<tankf33der>
hi all
<beneroth>
assembly was because it was easier (memory management), not for performance
<tankf33der>
pil21 works on riscv
<abu[7]>
Hi tankf33der
<geri>
so many people!
<beneroth>
hey tankf33der
<beneroth>
WOHOOOO great!
<tankf33der>
all tests passes.
<tankf33der>
all tests passed.
<beneroth>
awesome, thanks for testing!
<abu[7]>
The problem with FEXPs is that you don't know what is code and what is data, and *when* to execute the code
<abu[7]>
It can be executed conditionally etc
<geri>
beneroth: asm memory management being easier than C memory mangement sounds like a meme
<geri>
or maybe it is indeed because its general/generic assembly instead
<geri>
oh wait, is every extra argument unevaled because everything is unevaled by default?? :D
<abu[7]>
Yep
<geri>
makes sense
<abu[7]>
It is a consequence
<beneroth>
geri it's not a meme. in C memory allocation happens in blocks, and if you want a larger block you cannot resize the existing one but need to re-allocate the whole block. in asm you can extend the existing memory block.
<geri>
ah
<beneroth>
asm gives more fine-granular control than C
<abu[7]>
But in both asm and llvm you will call malloc()
<abu[7]>
So it ends up the same
<abu[7]>
as in C
<beneroth>
really?
<geri>
if you were to rewrite all of picolisp core from scratch, how long would it take you? abu[7]
<geri>
i feel now as if thats what you do instead of drinking coffee in the mornings
<abu[7]>
hmm, iirc pil21 took a few weeks, and then two years to get it all rounded up
<abu[7]>
I always wrote these versions parallel to my work
<abu[7]>
Used them in projects
<geri>
sounds like any projects i work on
<abu[7]>
So it did not feel like extra work ;)
<geri>
plus it might be a fun hobby for you too
<abu[7]>
OK, sorry, have a meeting soon, must prepare
<geri>
although after so much time it could get tedious and exhausting
<abu[7]>
BBL
<geri>
good luck
<abu[7]>
☺
pablo_escoberg has joined #picolisp
bjorkintosh has quit [Ping timeout: 246 seconds]
bjorkintosh has joined #picolisp
<geri>
abu[7]: do you know japanese?
<abu[7]>
Yes, some, but I forgot a lot during the last 35 years
<geri>
:D
<geri>
im griding anki cards every day, although kinda poorly lately
<geri>
the backtick youve explained, but where do i see what ~ does?
<geri>
also about penti - any plans to distribute it with fdroid?
<abu[7]>
I would like to, but did not succeed
<geri>
aw, what was the problem?
<abu[7]>
The procedure is complicated, and you need a git repo whicH I don't have
<abu[7]>
Mia created one, but she also did not succeed
<geri>
:(
<abu[7]>
She asked for help at F-Droid but without avail
<geri>
where do you store the source code?
<abu[7]>
In my own incremental directory tree
<abu[7]>
incremental backups
<abu[7]>
I have my own version control so to say
<abu[7]>
I always release TGZs, also for PicoLisp, PilBox
<abu[7]>
It is just a snapshot
<geri>
haha
<geri>
i mean, my files are just rsynced onto my usb drive for backup
<geri>
although all of my projects use git
<geri>
discrimination against tar lovers(
<abu[7]>
I hate Git and all existing repos I tried, because they destroy the metadata
<abu[7]>
I depend on the metadata for all I do
<geri>
what kind of metadata?
<abu[7]>
E.g in Vip you get the whole directory tree sorted by modification date
<abu[7]>
(vi "pil21")
<abu[7]>
You still have *all* time stamps correct
<abu[7]>
I can see what I worked on when
<abu[7]>
That's lost if you pull from Git et al
<abu[7]>
I still have files from the early 1990s with correct times
<geri>
aw
<abu[7]>
ALL my file management tools depend on correct times
<abu[7]>
When I modify a file, and then revert, I never undo by editing
<abu[7]>
Instead I fetch the old version from my repo to get the original timestamp too
<abu[7]>
See also :bak and :kab in Vip
<abu[7]>
The maintain stamps too
<geri>
ive recently switched from having a single directory full of configs to multiple for specific kinds of things because emacs config is like 1k lines and some other stuff, so ill probably need get something like incremental backups working to share configs between phone and pc
<geri>
what the hell, i just learned about superparens
<geri>
why arent they used more
<abu[7]>
A matter of taste perhaps
<geri>
this is kinda really cool
<geri>
except also harder to jump to matching paren
<abu[7]>
Vip handlen super parens correctly
<abu[7]>
*handles
<geri>
i should probably try to fix it up in the elisp package im using
<geri>
i hadnt seen it being used once in the source code yet though
<abu[7]>
I use it in the REPL sometimes
<abu[7]>
In source I somehow prefer (foo) ) ) )
<geri>
i hate spaced out closing parens with passion 🙂
<abu[7]>
They structure the code in a more readable way :)
<geri>
i find it more readable with just closing parens without spaces, but then again, i aint used to seeing that
<abu[7]>
] or ))))) cuts it off too harshly
<geri>
did you not add the ] reader macro?
<abu[7]>
What does it do?
<geri>
super parentheses? xd
<geri>
apparently its a read macro
<abu[7]>
Ah! Well, not really a macro, cause it does not expand to something