<clacke[m]>
> The personal task management software that works the way your brain does.
<clacke[m]>
So it's just an uncoordinated jumble that spits out random urges
f8l has quit [Ping timeout: 248 seconds]
<viaken>
clacke++
<aw->
aaahhaha clacke[m]
f8l has joined #picolisp
jibanes has quit [Ping timeout: 248 seconds]
jibanes has joined #picolisp
<m_mans>
Hi all
<m_mans>
how to make this pilog filter shorter: (not (or ((same "completed" @@ state id)) ((same "canceled" @@ state id)) ((same "closed" @@ state id))))
<Regenaxer>
m_mans, you could use 'member/2' perhaps
<Regenaxer>
yes, or of course (^ @ID ..., but 'val' is best
rob_w has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
Regenaxer has quit [Remote host closed the connection]
Regenaxer has joined #picolisp
<viaken>
https://picolisp.com/wiki/?unifyinglanguage - In the first phrase, nless that's an intentional portmanteau of page and paper, it should probably be one or the other.
<Regenaxer>
It was a paper originally
<Regenaxer>
converted to HTML years later
<aw->
hi all
<Regenaxer>
hi aw-
<beneroth>
hi viaken, Regenaxer, aw- :)
<Regenaxer>
Hi beneroth
<aw->
hey bene
<beneroth>
Regenaxer, abort/alarm might be ignored if execution is waiting on another process, correct? e.g. when doing an abort around (in (list ..) (line T)) ?
orivej has quit [Ping timeout: 248 seconds]
<Regenaxer>
no, alarm is lower level, SIGALRM
<Regenaxer>
only if (protect ...) is called it is delayed
<beneroth>
so (abort 5 (in (list "openssl" ...) (read) (read) (read))) should abort if the openssl call is taking longer than 5 seconds?
<Regenaxer>
yes
<Regenaxer>
hmm
<Regenaxer>
I see
<Regenaxer>
you mean the called process. This is not sent a signal probably
<beneroth>
aye
<Regenaxer>
true
<beneroth>
main process is on hold. so probably also not processing the alarm
<beneroth>
any way to solve this short of having an extra watcher process?
<Regenaxer>
I had expected the (read) to terminate nevertheless
<beneroth>
he? but (alarm) has an optional second argument, no?
* beneroth
is confused
<Regenaxer>
nope
<beneroth>
so the example in the ref is also wrong
<beneroth>
so I tried (in ... (or (abort 3 (read)) (kill (ipid) 9))) - same behaviour as before
<Regenaxer>
yes
<beneroth>
: (pp' abort)
<beneroth>
(alarm "N" (throw 'abort))
<beneroth>
(catch 'abort
<beneroth>
(de abort ("N" . "Prg")
<beneroth>
(finally (alarm 0)
<beneroth>
(run "Prg") ) ) )
<Regenaxer>
only the text is correct
<beneroth>
but in (abort) alarm is also used as in ref?
<Regenaxer>
true
* beneroth
is completely confused
<Regenaxer>
seems nonsense
<Regenaxer>
I looked into the source of 'alarm'
<Regenaxer>
no 'prg' is handled
<beneroth>
so how the fck did (abort) ever work?
<beneroth>
I have it in use at least once - was under the impression it worked as documented
<Regenaxer>
Yes, I'm confused too. The unit test also uses a 'prg'
<Regenaxer>
(let N 6
<Regenaxer>
(alarm 1 (inc 'N))
<Regenaxer>
(test 6 N)
<Regenaxer>
(wait 2000)
<Regenaxer>
(test 7 N)
<Regenaxer>
(alarm 0) )
<Regenaxer>
How can it work?
<Regenaxer>
Do I look in the wrong place?
<Regenaxer>
Whe (test 7 N) would not work
<Regenaxer>
The
<beneroth>
you sure you read the source of doAlarm correctly?
<beneroth>
(I don't fully understand it)
<Regenaxer>
hehe, I'm wondering too
<Regenaxer>
look into the pil32 code, src/main.c
<Regenaxer>
Aaahhh!
<Regenaxer>
I'm stupid
<beneroth>
Alarm = cddr(x);
<Regenaxer>
Yep!
<Regenaxer>
Overlooked it
<beneroth>
ld (Alarm) (Y CDR)
<Regenaxer>
:)
<beneroth>
I would guess
<Regenaxer>
yep
<beneroth>
so doc is right. you haven't booted yet?
<Regenaxer>
I was looking for some prog X # Run body
<beneroth>
well its not run yet xD
<Regenaxer>
booted?
<beneroth>
your brain I mean
<beneroth>
:P
<Regenaxer>
T
<Regenaxer>
hehe
<Regenaxer>
of course it cannot run the 'prg' immediately
<beneroth>
aye. thats the point.
<Regenaxer>
must be delayed to the signal handler
<Regenaxer>
yes
<Regenaxer>
Sorry for the confusion!
<beneroth>
implies that only one alarm can be set at the same time
<beneroth>
no problem
<Regenaxer>
yes, in Unix anyway
<Regenaxer>
the other signal handlers too
<Regenaxer>
*Hup, *Sig1 ...
<beneroth>
moments like this kinda motivates me. shows you are not the over-the-top superhuman some of your work suggests - meaning we all can get on your level just with efforts :P
<beneroth>
k makes sense
<Regenaxer>
exactly, all just boiled with water
<beneroth>
dunno if this saying works in english ^^
<beneroth>
T
<Regenaxer>
me too :)
<Regenaxer>
makes sense in Eng too
<beneroth>
so back tot he initial topic: alarm (signal) is not handled while the process is on hold due waiting on a called sub-process, right?