<abu[7]>
The name has 8 bytes per cell and 7 in the last CDR
<abu[7]>
So we need a terminator
<geri>
okay, makes sense
<geri>
thats like the only bit that invalidates the "RFC8259-compliant" thingie :(
<geri>
but its 99.9% compliant, so good enough :D
<geri>
ive posted about the wiki page
<abu[7]>
:D
<abu[7]>
Cool!
<geri>
am i a contributor yet
<geri>
:D
<abu[7]>
sure!
<geri>
hehe
<geri>
btw, why is name of a symbol encoded in last cdr of its plist and not the first car instead?
<abu[7]>
property access should be faster than name access, because the name is needed mainly for I/O which is slow anyway
<abu[7]>
And a minimal system of one cell has only a CAR (value) and a CDR (name)
<abu[7]>
s/system/symbol
<geri>
fair enough
<geri>
what is actually better - reading char by char or trying to read everything into memory?
<geri>
im guessing first one uses less memory but maybe slower and second one the opposite way
<abu[7]>
What reading do you think of? Sexprs?
<geri>
mostly json, but also applies to sexprs i guess
<abu[7]>
or, what *can* be read into memory?
<abu[7]>
'read' reads into memory first (buffer)
<geri>
yeah and then you can operate on it
<abu[7]>
just byte by byte
<abu[7]>
buffer is only for efficiency
<geri>
okay
<abu[7]>
read does only a single-byte look-ahead
<geri>
with (peek)?
<abu[7]>
(peek) is just a function to access this single char
<abu[7]>
the global $Chr
<geri>
haha, ofc its a global
<abu[7]>
(vi 'llvm~$Chr)
<geri>
when implementing my own "unread" functionality in python i had to have a variable for the latest char too
<geri>
q: does it mean when you do (char) it actually just returns you whatever was in $Chr and read a new char into there, available for (peek) again?
<abu[7]>
Yes, exactly
<geri>
is that how peeking in C works as well?
<abu[7]>
plus additional byte
<abu[7]>
s
<abu[7]>
I don't know a C peek fun
<geri>
right
<geri>
nvm, its got ungetc instead
<abu[7]>
a char in pil may he up to 4 byte
<abu[7]>
T, stdio
<geri>
i would guess it works in a similar way, just storing it in some variable upon doing ungetc and un-storing it when you read 1 char
<geri>
hm
<abu[7]>
I think so too
<geri>
how large is $Chr overall?
<abu[7]>
Just an int
<abu[7]>
it holds only one byte
<abu[7]>
so (char) or (peek) may trigger further fetches
<geri>
but yeah, utf-8 chars can be up to 4 bytes...
<geri>
ah
<abu[7]>
T
<abu[7]>
For the look-ahead a byte is enough
<abu[7]>
ASCII only
<abu[7]>
delimiters
<abu[7]>
abc(def)
<abu[7]>
read should return 'abc'
<abu[7]>
next read the list (def)
<geri>
yeah
<geri>
is ungetting vs peeking largely a preference thing?
<abu[7]>
Depends what ungetting can do
<abu[7]>
Can you unget more than one?
<geri>
i think no
<abu[7]>
So it is the same
<geri>
okee
<geri>
thanks
<geri>
why is (char) when called on top level of a script not reading from stdin?
<geri>
or more like, should i be doing (in 0 (char))?
<abu[7]>
When 'load'ing a file, the current input channel is the file itself
<geri>
huh
<geri>
worked with (in 0 ...)
<abu[7]>
yes, or (in NIL ...)
<abu[7]>
(pp 'private)
<abu[7]>
calls (read)
<abu[7]>
so it reads the *next* expression
<abu[7]>
(load "file") is basically (in "file" (while (read) (eval @]
<geri>
aha
<geri>
that's fun
<geri>
gotta go, have fun
<abu[7]>
o/
geri has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]