beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
NobleNibble has joined #picolisp
oldf8l has quit [Ping timeout: 252 seconds]
prestidigitator has joined #picolisp
NobleNibble has quit [Ping timeout: 260 seconds]
f8l has joined #picolisp
prestidigitator has quit [Ping timeout: 260 seconds]
stultulo has joined #picolisp
f8l has quit [Ping timeout: 265 seconds]
oldf8l has joined #picolisp
stultulo has quit [Ping timeout: 252 seconds]
NobleNibble has joined #picolisp
oldf8l has quit [Ping timeout: 252 seconds]
prestidigitator has joined #picolisp
NobleNibble has quit [Ping timeout: 265 seconds]
<Regenaxer> Oh, I see! Effective vs. efficient, OK
rob_w has joined #picolisp
rob_w has quit [*.net *.split]
beneroth has quit [*.net *.split]
emacsomancer has quit [*.net *.split]
anjaa has quit [*.net *.split]
mabi has quit [*.net *.split]
razzy has joined #picolisp
rob_w has joined #picolisp
beneroth has joined #picolisp
emacsomancer has joined #picolisp
anjaa has joined #picolisp
mabi has joined #picolisp
beneroth has quit [Quit: Leaving]
beneroth has joined #picolisp
<beneroth> Good morning everyone
<beneroth> I ended up in the wrong part of a IRC netsplit xD
<Regenaxer> Hi beneroth
<beneroth> Hi Regenaxer!
<Regenaxer> I did not know such a thing is possible
<Regenaxer> What is the consequence?
<beneroth> well IRC is a distributed system. I just found myself chatting in a #picolisp channel with only 4 other people after netsplit.
<beneroth> so I guess I was/ended up on a IRC server which lost connection to the "main" libera network
<Regenaxer> I see
<Regenaxer> Will such a situation fix automatically?
<beneroth> I don't know. I did reconnect, that worked.
<Regenaxer> ok
<Regenaxer> Sigh
<Regenaxer> Everything unreliable
<beneroth> I saw * Regenaxer hat die Verbindung getrennt (*.net *.split). in my log, so that was it
<Regenaxer> (even facebook ;)
<beneroth> facebook should stay down, would be better for the mental health of humans... and that is even scientific fact...
<Regenaxer> indeed
<Regenaxer> Good to have decentral systems
<Regenaxer> though I still have problems with Matrix
<beneroth> but that was a configuration error, which is the leading cause for big outages for a while now
<beneroth> facebook has their own domain registrar, and that disconnected from the internet
<beneroth> dunno about the Matrix problems
razzy has quit [Ping timeout: 268 seconds]
<Regenaxer> Does not decrypt sometiones
<Regenaxer> sometimes
<beneroth> weird
<Regenaxer> T
<beneroth> so key exchange issues... which is kidna good if it rather doesn't decrypt than being able to decrypt when it must not.. but...
<Regenaxer> yes, key exchange. But it works 99% of the time
<Regenaxer> even with the same contact within minutes works and then works not and then works
<Regenaxer> no idea
<beneroth> IRC, or at least freenode and libera, use DNS round-robin to load-balance new connections on multiple servers. so multiple IP's are placed in same A-record in DNS. simple but effective.
<beneroth> same contact, so not only group channels but single contact messaging? I would believe that should not need so many key exchanges. Group chats..sure.. but single contact messaging?
<beneroth> that sounds weird
<Regenaxer> Yesterday my OnePlus updated, and now shared storage access does not work any more
<Regenaxer> all app permissions are ok
<beneroth> "it" updated... so much about being in control and the owner of the device
<Regenaxer> yes, single peer-to-peer chat
<Regenaxer> very right!
<beneroth> I have a pil question for you
<Regenaxer> ok
<beneroth> I'm using (abort) as I said yesterday, to prevent getting stuck in a blocking read or slow network connection.
<beneroth> works well.. but I get "48072 SIG-14" written on stderr, I believe it's from the alarm placed by abort
<beneroth> any idea?
<beneroth> SIG-14 is SIGALRM afaik
<Regenaxer> right
<Regenaxer> Is it because the process terminated already?
<beneroth> no, the pipe is still running
<beneroth> the aborted execution already terminated, yes
<Regenaxer> yeah, otherwise (finally (alarm 0)
<Regenaxer> ah
<Regenaxer> so the finally is not reached?
<beneroth> no, I don't have a (finally (alarm 0)), I thought this should not be necessary when using (abort).. is it necessary?
<beneroth> I use abort in two patterns..
<Regenaxer> no, 'abort' calls 'finally'
<beneroth> 1) in opening the background pipe: (pipe (abort Timeout (exec ....))) -> 3
<beneroth> 2) when reading from that background pipe, e.g. (in 3 (abort Timeout (line)))
<beneroth> in normal operation, that abort should not be triggered
<beneroth> (I mean the evaluation is finished before the alarm triggers)
<Regenaxer> The SIG-14 looks like going to the wrong process
<beneroth> I'm not sure if those stderr messages are caused only by the 1) pattern or from both usages
<beneroth> yeah
<Regenaxer> a process not catching it
<beneroth> ah, makes sense!
<beneroth> I suspect the 1) (pipe (abort Timeout (exec ...))) is the issue
<beneroth> should do (abort Timeout (pipe (exec))) instead?
<Regenaxer> The first looks correct
<Regenaxer> Perhaps it is not inherited
<Regenaxer> the exed'd process
<Regenaxer> to the exed'd process
<beneroth> doesn't it mean, the abort is placed in the piped/forked process, which then gets taken over by (exec) and thus does not expect the SIGALRM ?
<beneroth> hmmm
<Regenaxer> yes
<beneroth> the exec is a executable call, not pil anymore
<Regenaxer> not inherited across exec
<Regenaxer> yes
<Regenaxer> So the exec'd process must do it
<Regenaxer> or use 'alarm' and kill the process
<beneroth> yes it from the 1) usage with the pipe, I' sure
<beneroth> so the issue is.. because the exec'd process does not inherit the alarm handler, but receives the alarm?
<Regenaxer> I think so
<beneroth> why is (abort Timeout (pipe (exec ...))) not a good solution?
<Regenaxer> Can you use 'ipid' to get the PID?
<Regenaxer> then an 'alarm' to kill the child
<Regenaxer> (abort Timeout (pipe also goes to the wrong process
<beneroth> I don't want to kill the child
<beneroth> well not in the normal use case
<beneroth> only when it takes to long to start up
<Regenaxer> yes, by using 'alarm' manually
<Regenaxer> 'abort' uses 'alarm'
<Regenaxer> (pp 'abort)
<beneroth> aye
<Regenaxer> The problem is to get the PID
<Regenaxer> (pipe (...) (ipid)
<beneroth> with (exec) the PID stays the same, I believe.
<beneroth> so I could get it before calling (exec)
<beneroth> oh
<Regenaxer> (pipe (...) (alarm N (kill -X (ipid))))
<Regenaxer> yes, exec replaces in the same process
<beneroth> but (pipe (...) (alarm N (kill -X (ipid)))) does terminate the forked process once (...) is finished, no?
<Regenaxer> only if the alarm fires
<beneroth> ah
<beneroth> well no
<beneroth> hm
<Regenaxer> if you get the pid in the pipe, you must comunicate it to the parent
<beneroth> I think my use of abort here is complete nonsense
<Regenaxer> Best would be if the exec'd process behaves the right way
<beneroth> because (pipe (exec)) will return a 'fd in any case pretty quickly, even if the started executable gets stuck.. then only the pipe would not be responsive
<beneroth> right?
<Regenaxer> right
<beneroth> so guarding the (read) and (line) with abort is meaningful, but not starting the piped exec
<Regenaxer> then find the pid from the fd
<beneroth> no problem with aborts in the main process, as there the handler is present
<beneroth> the (abort Timeout (line))) don't cause stderr messages
<Regenaxer> Sorry, have a conference in three minutes. Must prepare :)
<beneroth> all good, you helped me
<beneroth> thank you!
<Regenaxer> :)
<Regenaxer> Conf with Ruediger and Olaf on your server ;)
<Regenaxer> Thanks for that!
<beneroth> you're welcome :)
razzy has joined #picolisp
razzy has quit [Ping timeout: 250 seconds]
razzy has joined #picolisp
razzy has quit [Ping timeout: 265 seconds]
razzy has joined #picolisp
<razzy> beneroth: may i ask you, what you meant by "turtle is limited?"
<beneroth> ah
<beneroth> do you know the expression "it's turtles all the way down" ? it means there is infinite more layers of complicated stuff beneath something. https://en.wikipedia.org/wiki/Turtles_all_the_way_down
<beneroth> with that I meant, that this is not so with picolisp, the layers of a picolisp application are less and more transparent then in comparable software stacks
<beneroth> e.g. even most of the database code is picolisp, and the picolisp interpreter itself is a collection of rather small and readable asm code
<beneroth> does this make sense?
<razzy> beneroth: ok, thank you.
<beneroth> bbl
razzy has quit [Ping timeout: 268 seconds]
f8l has joined #picolisp
prestidigitator has quit [Ping timeout: 265 seconds]
rob_w has quit [Remote host closed the connection]
aw- has quit [Ping timeout: 245 seconds]
f8l has quit [Quit: Moving abroad]
rob_w has joined #picolisp
rob_w has quit [Read error: Connection reset by peer]
aw- has joined #picolisp