<Regenaxer>
(let F (open "a") (%@ "read" 'I F '(X (4 . I)) 4) (close F))
<Regenaxer>
Looks very similar! :)
<Regenaxer>
even "a" ! :)
<Regenaxer>
I get the correct value in 'X'
<Regenaxer>
Return value of read is int, so 'I' is better
<Regenaxer>
but should not matter on 64 bits
<aw->
yeah.. return value of read() is just the length of the bytes read
<Regenaxer>
T
<Regenaxer>
But what goes wrong on your side?
<aw->
i get this
<aw->
218103808
<Regenaxer>
this is correct
<Regenaxer>
big endian
<Regenaxer>
: (hex 218103808)
<Regenaxer>
-> "D000000"
<Regenaxer>
BTW, remember that you should (use Buf ...) around your code
<Regenaxer>
in all such native usages of return variables
<aw->
yes i did that
<aw->
here it's just an example
<aw->
(hd "a")
<aw->
00000000 00 00 00 0D ....
<Regenaxer>
good
<Regenaxer>
Anyway, your read call works
<aw->
hmmm...
<Regenaxer>
(wr 0 0 0 13) is big endian of 13 decimal or D hex
<aw->
right
<aw->
so why am I getting D000000 instead of 000000D ?
<Regenaxer>
big endian
<Regenaxer>
you wanted big endian
<Regenaxer>
but the machine seems to be little endian
<Regenaxer>
the 13 is at the highest byte
<Regenaxer>
buffer + 3
<aw->
ok so if i'm sending the 4-byte integer '13' over the network, (0 0 0 13) is correct, right?
<Regenaxer>
network order is which endianess?
<aw->
big endian
<Regenaxer>
yes, you send 13 last then
<aw->
yes
<aw->
and my protocol should read the bytes: (0 0 0 13)
<aw->
it does
<Regenaxer>
yeah
<aw->
but why when I use '(Buf (4 . I)) i get 218103808 instead of 13?
<Regenaxer>
and 13 is at the highest address
<aw->
because my CPU?
<Regenaxer>
yes, Arm and x86 are little endian
<aw->
ohshit
<aw->
well that explains it
<aw->
in this case I can't use (4 . I) .. better to use (4 B . 4) and then convert to Int manually?
<Regenaxer>
hmm, what did I do in lib/net.l?
<Regenaxer>
call htonl()
<Regenaxer>
these are C macros usually
<Regenaxer>
no, in pil64 I call htons()
<Regenaxer>
why not in lib/net.l ?
<aw->
in pil21 you shift bytes by 8
<aw->
left shift
<Regenaxer>
right
<aw->
ahh yes
<Regenaxer>
it is only 2 bytes for a short
<aw->
that makes sense
<Regenaxer>
but you can call htonl()
<aw->
i've been using (rd 4) since the beginning.. and because pil knows my cpu arch, it handles the conversion
<Regenaxer>
8 bytes I presume
<Regenaxer>
no, pil does not know
<Regenaxer>
it uses what you tell
<Regenaxer>
(rd -4) reads little endian
<aw->
ohhh ok
<aw->
so i've been reading in big endian all this time without realizing
<Regenaxer>
as you know the data are big endian, all is ok
<aw->
"it just works" for network data
<aw->
yes exactly
<Regenaxer>
yes
<aw->
haha oops
<Regenaxer>
So all good here
<aw->
ok well I can fix this now, no problem
<aw->
thank you
<Regenaxer>
call htonl()?
<Regenaxer>
or shifting?
pointfree has quit [Read error: Connection reset by peer]
pointfree has joined #picolisp
<aw->
htonl probably.. but maybe I don't to do it because the code might run on systems which are already big endian.. dont want to break for those systems
<dexen>
i would probably enjoy it, tho for now i prefer git because if its very natural & sensible *storage* format. given my filesystem interest, the storage format is very natural to me.
_whitelogger has joined #picolisp
<Regenaxer>
I see, thanks!
_whitelogger has joined #picolisp
<dexen>
generally, how does one implement a very simple DSL in picolisp?
<dexen>
i want to interpret RPG style dice throw expression, similar to "3d10+5"