alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
<beneroth>
Regenaxer, (peek) is blocking? so I should do (when (poll Socket) (peek)) on network connections?
<beneroth>
nevermind, I get a block on (char), not (peek)
<Regenaxer>
ok :)
<Regenaxer>
But (peek) can block
<Regenaxer>
it uses the internal look-ahead
<Regenaxer>
As ever, the right way is to wake up when ready (task / *Run)
_whitelogger has joined #picolisp
<beneroth>
Regenaxer, I'm after wake up, parsing one char after another, and suddenly it hangs
<beneroth>
probably my mistake, but still searching the cause
<Regenaxer>
yeah
<beneroth>
(peek) returns a value
<Regenaxer>
Not a mistake probably
<beneroth>
but the next (char) hangs
<beneroth>
I check with (peek) to decide how to continue parsing
<beneroth>
it meets expectations, so I do (char)
<Regenaxer>
The buffer can be empty any time
<beneroth>
then char blocks until the buffer as something in it, right?
<beneroth>
that would be okay
<Regenaxer>
What if you (fifo) in the background?
<beneroth>
funningly the other end claims my program closed the connection
<beneroth>
Regenaxer, hm.. you mean instead of calling (peek) multiple times?
<Regenaxer>
yes
<Regenaxer>
collect in the background
<Regenaxer>
then look at the fifo queue
<Regenaxer>
perhaps too tedious
<Regenaxer>
or fork a process
<beneroth>
what benefit gives that beside having a second buffer?
<Regenaxer>
you can take only full messages from the queue
<Regenaxer>
Or, as I wanted to say, fork a process and (alarm) in it
<Regenaxer>
Only handle fully received data
<Regenaxer>
It all depends ... :)
<beneroth>
the blocking is not the problem
<Regenaxer>
ah, ok
<beneroth>
well it is.. but the problem is because I don't expect a block to be at that point
<Regenaxer>
hmm
<beneroth>
I also don't see how (char) can block when (peek) just before is ok
<Regenaxer>
the connection might be unstable
<beneroth>
yeah
<beneroth>
how to get the 'fd of the current input stream? no function for that?
<beneroth>
like (ipid) but for the 'fd ?
<Regenaxer>
true, char returns what peek saw
<Regenaxer>
There is none I think
<beneroth>
ok :)
<Regenaxer>
It was explicit after connect etc
<Regenaxer>
in/out are not explicit
<Regenaxer>
in/out have (fd) though
<Regenaxer>
returns the innermost FD
<beneroth>
ah yes
<beneroth>
(fd) is perfect, that was what I was looking for :)
<Regenaxer>
:)
<beneroth>
I just tested with (poll)... (peek) returns a value, and then (poll) returns nil
<beneroth>
I come to think it is because of my logging function.. it is an FEXPR, doing (out ...) while 'eval
<beneroth>
even doing a (flush) at the end
<beneroth>
maybe that affects the (unchanged) current input stream ?
<Regenaxer>
flush concerns only output
<Regenaxer>
no
<beneroth>
I assumed so
<beneroth>
ok
<Regenaxer>
peek and poll adress different issues
<beneroth>
T
<Regenaxer>
peek lookes at the prefetched char
<Regenaxer>
no meaning in PLIO
<Regenaxer>
only read/char/line etc
<beneroth>
T
<Regenaxer>
nasty stuff :)
<beneroth>
how can it be that (peek) returns me a value, but the (poll) just after it returns NIL, and the (char) call just after it hangs
<beneroth>
the input stream is supposed to be text
<Regenaxer>
'poll' just does a select()
<Regenaxer>
while char/poll operate on the stream buffers
<beneroth>
T
<beneroth>
Regenaxer, calling (peek) multiple times before consuming the input with (char)/(line)/(skip) should be okay, right?
<Regenaxer>
yes
<Regenaxer>
it just looks at the global char variable
<beneroth>
alright thanks
<Regenaxer>
So peek is not intended for such checks
<Regenaxer>
it is really just a logical look-ahead
<Regenaxer>
for the char already fetched in the read processing
<Regenaxer>
useful for some kinds of parsing
<beneroth>
(peek) -> "s" (char) hangs
<beneroth>
the input stream is really empty/stopped after this (char) call
<beneroth>
but I would expect (char) to return the same value as (peek) just before, and then from then on (peek) and (char) hanging
<Regenaxer>
(char) return the char, and fetches the next
<Regenaxer>
so it might hang
<beneroth>
ok
<Regenaxer>
always one char ahead :)
<beneroth>
so this is how it should be
<beneroth>
if there is no next one?
<Regenaxer>
only one?
<beneroth>
only one?
<beneroth>
yeah after the successful peek there is no more input
<Regenaxer>
I see
<beneroth>
so I guess it is all correct that (char) hangs then
<Regenaxer>
probably
<beneroth>
but there might come more.. might.
<beneroth>
so for that I could use (poll), no?
<Regenaxer>
not really
<beneroth>
if (poll) (char) else we're at the EOF
<Regenaxer>
if the data are buffered already, poll might return NIL
<beneroth>
hmm
<beneroth>
seems like I cannot truly empty the buffer
<Regenaxer>
yeah
<Regenaxer>
It is all rather asynchronous
<beneroth>
yeah that is alright
<beneroth>
what is the 'cnt that is returned by (poll) ?
<beneroth>
size of buffer?
<beneroth>
well.. stuff waiting in buffer, I mean
<Regenaxer>
no, just the argument
<beneroth>
ah
<beneroth>
ok
<beneroth>
so the fd
<beneroth>
btw
<Regenaxer>
yep
<beneroth>
ok I guess I can solve it
<beneroth>
btw. I realised a thing about (run)
<beneroth>
fexpr evaluating a prg within (in) or (out).. I guess in pil64 you can switch to some other (in)/(out) stream using the offset argument, no?
<beneroth>
this would be something lost when run no longer has the offset parameter, no?
<Regenaxer>
yes, numeric
<Regenaxer>
no
<Regenaxer>
the offset was about bindings
<Regenaxer>
the in/out offset is about i/e frames
<Regenaxer>
i/o
<Regenaxer>
bind frames and i/o frames are completely separate
<beneroth>
ok, so you say (pseudocode): (out "foo" (fexpr (prinl "bla"))) with (fexpr Prg (out "bar" (prinl (run Prg 1)))) is already now directing all output into "bar" and none into "foo" ?
<beneroth>
ah yes
<beneroth>
yeah the reference sounds like what you are saying here :P
<Regenaxer>
all relative and dynamic :)
<beneroth>
I see :)
<beneroth>
thanks!
<beneroth>
afk
<Regenaxer>
:)
<alexshendi>
pil21 has native, right? So can I call libSDL2 from pil21?
<Regenaxer>
yes, native is ready now :)
<alexshendi>
Regenaxer:Thanks.
<Regenaxer>
ah, beneroth, for the records:
<Regenaxer>
(poll) *does* check the buffer
<Regenaxer>
I looked into the source now
<Regenaxer>
So (poll) should be good
<Regenaxer>
(peek) is still separate though
<Regenaxer>
It might have the char, but the buffer may be empty
<Regenaxer>
So a combination of peek and poll somehow might be the way
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #picolisp
<beneroth>
Regenaxer, ok, so as I thought!
<beneroth>
Regenaxer, thanks for checking! Much appreciated!
<beneroth>
so I will add some (poll) to my code to check for connection abortion / weird clients
<Regenaxer>
:)
<Regenaxer>
Why not 'abort'?
<beneroth>
that is another topic.. I will do wrap abort around it...
<Regenaxer>
ok
<beneroth>
well yes, you are right, I can always just abort by default and let it hang if things go really bad
<beneroth>
on the other hand, with proper (poll) checks, hanging should never be possible, except maybe for TCP edge cases