<tankf33der>
abu[7]: can you describe in a few words till algo. for example, do you peek every char before read? :/
<abu[7]>
It uses the normal read machinery, which *always* does a single-char look ahead
<abu[7]>
eg. (a)
<abu[7]>
when reading 'a', it stops at ')'
<abu[7]>
or (a(b)) stops at '('
<tankf33der>
ok
<abu[7]>
*next* read returns (b)
<tankf33der>
i see.
<abu[7]>
This next char is always in (val $Chr)
<abu[7]>
not char, but byte actually
<abu[7]>
It is a single-byte look-ahead
<beneroth>
tankf33der, works all fine until you start mixing textual reading and binary reading, or if you read from a pipe or network socket which blocks if you don't keep the look-ahead-peek-buffer-read in mind...
<beneroth>
abu[7], what if we peek for an multibyte-char?
corecheckno has quit [Read error: Connection reset by peer]
<abu[7]>
Works
<abu[7]>
just may block iirc
<abu[7]>
you mean 'peek'?
<beneroth>
yep
<beneroth>
peek returns a char, not a byte, right?
<abu[7]>
T
<abu[7]>
Wait, no
<abu[7]>
just a byte
<abu[7]>
: (in "a" (list (char) (char) (char) (char)))
<abu[7]>
-> ("a" "b" "c" "☺")
<abu[7]>
: (in "a" (list (char) (char) (char) (peek)))
<abu[7]>
-> ("a" "b" "c" "â")
<beneroth>
hmm, right
<beneroth>
ugly
<abu[7]>
(after "echo abc☺def >a")
<beneroth>
but a variable-sized buffer (or fixed 4 bytes) is also a bit ugly...
<abu[7]>
Yes, but otherwise it *might block
<abu[7]>
buffer is not the problem
<abu[7]>
but blocking
<beneroth>
T
<beneroth>
yeah this way (peek) is non-blocking
<beneroth>
well, if the buffer is already filled
<abu[7]>
: (in "a" (list (char) (char) (char) (peek) (char)))
<abu[7]>
-> ("a" "b" "c" "â" "☺")
<abu[7]>
Normally you peek for ASCII chars
<beneroth>
thanks abu[7], I forgot how peek behaved with multi-byte
<abu[7]>
prog langs etc.
<beneroth>
abu[7], yes agreed
<abu[7]>
I forgot too
<beneroth>
though I like to do funny stuff - or at least don't restrict my options - in HTTP. E.g. smileys and special chars in URLs, hehehe
<abu[7]>
What you said about mixing binary reads is right
<abu[7]>
ie. 'rd'
<beneroth>
T
<abu[7]>
also 'pr' and 'wr' when printing
<beneroth>
reading a chunked HTTP stream might necessitate mixed reading
<abu[7]>
T, but you can't mix
<abu[7]>
so we have ht:xxx
<abu[7]>
Chunked I/O
<beneroth>
I could and did mix. Just keep track of buffer states xD
<beneroth>
but yeah, not recommend :)
<abu[7]>
T
<beneroth>
otherwise you get a paradie for off-by-one and sudden blocks
<beneroth>
*paradise
<abu[7]>
Yeah, on the file struct level it is the same buffer
<abu[7]>
not like stdio in C
<abu[7]>
stdio uses separate buffers iir6
<abu[7]>
iirc
<abu[7]>
so mixing with read(...) won't work
<beneroth>
oh it does? didn't know
<abu[7]>
I think so
<abu[7]>
must be
<abu[7]>
for read() you pass your own buffer
<abu[7]>
and stdio has a hidden one
<abu[7]>
We could extend 'peek' with an optional 'flg' argument, so that it returns a full char, but may block on a socket or pipe
<abu[7]>
Just needs to call llvm~getChar internally
lagash has joined #picolisp
lagash has quit [Remote host closed the connection]
lagash has joined #picolisp
lagash has quit [Remote host closed the connection]
<abu[7]>
The ref of 'peek' is wrong anyway, saying that it would block on a multi-byte character
<abu[7]>
It does not, see above
<abu[7]>
I will extend 'peek' and fix the ref
<abu[7]>
OK! Done and released :)
<abu[7]>
: (in "a" (list (char) (char) (char) (peek)))
<abu[7]>
-> ("a" "b" "c" "â")
<abu[7]>
: (in "a" (list (char) (char) (char) (peek T)))
<abu[7]>
-> ("a" "b" "c" "☺")
<abu[7]>
Hmm, no! This was a bad idea! I revert :(
<beneroth>
yeah, I think the (peek T) is not needed
<beneroth>
then better a way to get the number of bytes read from (char) and other text read functions
<beneroth>
but this can also already be done in other ways, I think
<abu[7]>
(peek T) was even wrong, because it fetched the char from the stream and was no longer just a peek
<beneroth>
yeah makes sense
Iacob has quit [Remote host closed the connection]