<Regenaxer>
look also in @loc/XX.l for the translations
<mtsd>
Any luck with the llvm flags?
<Regenaxer>
No, I changed the internal code :)
<Regenaxer>
Made an array
<Regenaxer>
So the linker won't mess it up
<mtsd>
Got round the problem
<cil_z>
tkx guys
<Regenaxer>
Welcome!
karswell has quit [Remote host closed the connection]
<tankf33der>
downloading centos8, lets see.
karswell has joined #picolisp
karswell has quit [Read error: Connection reset by peer]
cil_z has quit [Ping timeout: 245 seconds]
orivej has joined #picolisp
ubLIX has joined #picolisp
freemint has quit [Ping timeout: 245 seconds]
orivej has quit [Ping timeout: 268 seconds]
karswell has joined #picolisp
andyjpb has quit [Ping timeout: 240 seconds]
beneroth has joined #picolisp
<beneroth>
hi all
<Regenaxer>
Hi beneroth!
<mtsd>
Hello beneroth
<tankf33der>
centos 8 works.
<Regenaxer>
Cool!
ubLIX has quit [Quit: ubLIX]
cil_z has joined #picolisp
m_mans has quit [Quit: Leaving.]
mtsd has quit [Quit: Leaving]
<beneroth>
freshly released and already tested, wow! thanks tankf33der !
rob_w has quit [Quit: Leaving]
cil_z has quit [Ping timeout: 252 seconds]
<tankf33der>
beneroth: every modern should be fine. i just have fun.
<Regenaxer>
:)
freemint has joined #picolisp
cil_z has joined #picolisp
<beneroth>
Regenaxer, is it okay to use (poll) within (in), e.g. (in 3 (while (poll 3) ...) ? or better only outside of (in) ?
<Regenaxer>
I havent tried, but it should be ok
<beneroth>
ok thanks
<beneroth>
yeah seems to work
<beneroth>
and a bit faster then (while (poll 3) (in 3 ...))
<Regenaxer>
Good to know
<Regenaxer>
Very little I think
<beneroth>
(wait NIL T 3) is also nice, very handy :)
<Regenaxer>
(in <fd> does no syscalls
<beneroth>
yeah
<beneroth>
my test might be meaningless, only sampled 1-2 attempts. 0.009 sec vs. 0.005 sec according to bench
<Regenaxer>
ok
<beneroth>
probably not related to the (in) :)
<beneroth>
actually
<Regenaxer>
yeah, such short timings are hard to measure
<Regenaxer>
'wait' may be better (sleeps the process) anyway
<beneroth>
and my 3 is a pipe to another process doing a network request.. so likely any time variation is due to server response time ^^'
<beneroth>
wait instead of poll, or wait instead of (wait NIL T 3) ?
<beneroth>
I'm using (poll) like (eof) here
<Regenaxer>
(wait NIL T 3) instead of poll
<beneroth>
as the fd is a pipe to a process which should continue to run in background, there is no eof
<beneroth>
I'd guess (wait ..) is doing more than (poll), no ?
<Regenaxer>
ok, but wait wakes up if something arrives
<Regenaxer>
poll just looks and continues
<beneroth>
yeah, I do that before starting (while (poll ...))
<beneroth>
the poll is just to find the end of the current exchange
<Regenaxer>
Ah, so you want to avoid blocking while reading
<beneroth>
not really
<beneroth>
out 3 command -> other process sends response
<beneroth>
I don't know how long the response is
<Regenaxer>
If the size of the message is less than PIPEBUF, you don't need to worry
<Regenaxer>
will always be fully transmitted
<beneroth>
similar to (in "somefile" (while (eof) ...)) I do (in 'fd (while (poll fd))
<Regenaxer>
Can you control the message format?
<Regenaxer>
if so, a given end may exist
<beneroth>
it could be larger in this use case. and I must not call (line) when the process stopped sending, as then i block
<Regenaxer>
eg (a b c) the ")"
<Regenaxer>
or PLIO
<beneroth>
I cannot
<Regenaxer>
ok
<beneroth>
is my usage of (poll) ok for that, or better something else?
<Regenaxer>
In fact I never use poll
<Regenaxer>
it does not feel right
<beneroth>
I just want "is there more to read right now: yes or now?"
<Regenaxer>
Can you use a task?
<Regenaxer>
eg. with 'fifo'
<beneroth>
its synchron, not asynchron
<beneroth>
the other process will only send data after I previously sent it a command
<beneroth>
relational database
<Regenaxer>
ok
<Regenaxer>
and there is no end-of-message marker?
<beneroth>
aye
<beneroth>
the other process just sends an arbitrary number of lines back
<beneroth>
and then it stops, until I send it another command. :)
<Regenaxer>
Yeah, seems like 'poll' is all right
<beneroth>
but I don't know how many lines beforehand, there is no end-of-message marker
<beneroth>
ok
<Regenaxer>
It might be that some lines are delayed. Then polling stops
<beneroth>
this is just for the crude general message exchange with the other process. I will define specific functions which look at the content of the response, so they can determine the end of the message without poll
<beneroth>
good point
<Regenaxer>
You could wait a little before each poll to be sure
<beneroth>
on the other hand... (wait NIL T 3) instead of poll will just end in wait when the other process stopped sending..
<Regenaxer>
(wait 80) or so
<beneroth>
I do:
<beneroth>
(wait NIL T 3) (make (in 3 (while (poll 3) (link (line T)))))
<beneroth>
I think there should be no delays within a response. before the response there might be, which I handled with (wait ...) here.
<Regenaxer>
yep
<beneroth>
the crucial point is not to end stuck waiting for more to come when the other process stopped sending
<Regenaxer>
this you detect because you get NIL then
<beneroth>
T
<beneroth>
from poll
<beneroth>
but would not work with (line), as (line) would wait for (eof), which will never come as the pipe is kept alive, so (line) blocks forever
<beneroth>
:)
<beneroth>
poll is perfect for this special use case
<Regenaxer>
not from poll, but when reading after waking up from wait
<Regenaxer>
Same in tasks
<beneroth>
<Regenaxer> not from poll, but when reading after waking up from wait
<beneroth>
reading using which function? not line, obviously
<Regenaxer>
line is OK if there are no messages with empty lines
<beneroth>
there aren't
<Regenaxer>
good, so you might be able to use just (wait ... fd)
<beneroth>
to detect beginning of a message, but not to detect end of message
<Regenaxer>
NIL is only if the remote process closed
<beneroth>
no, (poll 3) is also NIL if the pipe buffer is empty
<beneroth>
without the pipe being closed
<beneroth>
I tested
<Regenaxer>
I meant wait or task
<beneroth>
T
<Regenaxer>
they wake up, but reading gives NIL if closed
<beneroth>
T
<beneroth>
but reading does not give NIL if piper buffer is empty, reading just blocks until something arrvies
<Regenaxer>
So the most stable is to sleep in a task and put each line into a global fifo
<beneroth>
it seems to me you think of a specific scenario I don't see here
<beneroth>
anyway, I will send you the code for review when it is finished.
<beneroth>
before publish on ML :)
<Regenaxer>
The scenario is if the main process is not fully busy, so that it can start tasks
<Regenaxer>
ok :)
<beneroth>
yeah, doesn't apply, the main process should block while waiting for the response :P
<beneroth>
I'm aware of the other possibilities :)
<beneroth>
thanks
<Regenaxer>
What makes me feel uneasy is not being sure if all lines arrived
<beneroth>
I think I can be sure.
<beneroth>
the pipe is not over a network
<Regenaxer>
But the process may hang for a moment (I/O disk etc)
<beneroth>
just to a client binary, which I assume collects the full response before outputing it
<Regenaxer>
ok
<beneroth>
then line blocks, I think
<Regenaxer>
right
<beneroth>
you mean if the process hangs just long enough so the main process empties the buffer through reading, and the other process still hangs while I do (poll) ?
<beneroth>
maybe not impossible, but quite unlikely, I believe
<Regenaxer>
I mean (poll) returns NIL, but not all arrived yet
<Regenaxer>
eg the machine is loaded / swapping
<beneroth>
yeah, that would mean the other process hasn't sent all yet
<Regenaxer>
It is not predictable
<Regenaxer>
so (wait 100) (poll ... perhaps
<Regenaxer>
but how much time is enough?
cil_z has quit [Ping timeout: 276 seconds]
freemint has quit [Ping timeout: 264 seconds]
<Regenaxer>
I think the problem is the unclear protocol
<Regenaxer>
You need to know when all arrived
<beneroth>
it is ok, I only do this (poll) construct when not parsing the content of the response. for debugging and re-usability. when parsing the responses, it will be obvious if the response was incomplete
<beneroth>
yep
<beneroth>
I know :)
<Regenaxer>
eg send 2 queries together, one with a known oneline response
<beneroth>
yeah I'm aware of this strategy :)
<beneroth>
anyway, you answered my question about (poll), I believe I grokked my scenario and you confirmed my assumptions. all good.
<beneroth>
thank you Regenaxer
<Regenaxer>
Welcome :)
<beneroth>
I will send the code for review to you, later today or tomorrow