<aw->
in pil21, is there an easier way to write this (native) result specification: (list 'Attr (64 N . 4) . 0)
<Regenaxer>
You could (64 N N N N) . 0
<Regenaxer>
nit easier
<Regenaxer>
well, it is constant
<Regenaxer>
no 'list' needed
<Regenaxer>
'(Attr (64 N . 4) . 0)
<Regenaxer>
so less 'cons'ing at runtime
<aw->
oh good
<aw->
that works in pil64 too
<Regenaxer>
yes
<aw->
ok this is good
<aw->
thanks
<Regenaxer>
:)
<Regenaxer>
Also, 'list' does not what you want
<Regenaxer>
: (list 'Attr (64 N . 4) . 0)
<Regenaxer>
-> (Attr (64 N . 4))
<Regenaxer>
You'd need 'cons'
<Regenaxer>
: (cons 'Attr (64 N . 4) 0)
<Regenaxer>
-> (Attr (64 N . 4) . 0)
<aw->
oh wow you're right
<aw->
well i had already fixed it to '(Attr (64 N N N N) . 0)
<Regenaxer>
ok :)
<aw->
is that wrong?
<Regenaxer>
No, looks good
<aw->
ok thank you
rob_w has quit [Quit: Leaving]
patrixl has quit [Read error: Connection reset by peer]
patrixl has joined #picolisp
<aw->
Regenaxer: i think i asked you already, but if I do (in Fd (rd 4)) to read 4 bytes.. it reads as an Int.. is there a way to conver that to 4 separate bytes?
<Regenaxer>
Instead of converting, better read the bytes directly
<Regenaxer>
(in Fd (make (do 4 (rd 1))))
<Regenaxer>
(in Fd (make (do 4 (link (rd 1)))))
<Regenaxer>
Conversion would need & and >> operations
<aw->
right.. ok that's what i was doing (make (do ...)
<tankf33der>
Regenaxer: alloc() is calloc(), right ?
<Regenaxer>
It calls realloc() iirc
<tankf33der>
because malloc() does not init memory
<tankf33der>
calloc() does.
<tankf33der>
calloc() does by zeroes.
<Regenaxer>
I dont want to waste time initializing
<Regenaxer>
not useful at all
<beneroth>
which is good practice, but unnecessary performance cost if you can guarantee to never read from that memory without writting first
<Regenaxer>
sure
<beneroth>
well possible that the checker just checks for idealistic reasons...
<Regenaxer>
else you get nonsense data
<Regenaxer>
and if initialized to zero it still gives nonsense
<Regenaxer>
I dont think so
<Regenaxer>
No software does that
<beneroth>
well reading from possible uninitialized or deleted memory is also a main vector to attack C programs (overwriting the value of function pointers)
<beneroth>
initializing to zero can block such a security attack
<tankf33der>
you could modify just for testing and then return back.
<beneroth>
T
<Regenaxer>
If a bad process can read the heap, it does not help
<Regenaxer>
free()d mem is just normal heap
<beneroth>
its a clang feature? so from the same guys who hate dynamic sized arrays just by principle?
<Regenaxer>
Even that I wont believe ;)
<Regenaxer>
No, it may well be I have indeed a fault
<Regenaxer>
but which one?
<beneroth>
you need to factor more cargo-culting into your model of how other devs think, Regenaxer ;-)
<beneroth>
T
<beneroth>
it might be a real issue
<Regenaxer>
yes, quite probable
<Regenaxer>
beneroth, btw, I introduced a new concept in pil21 namespaces
<Regenaxer>
2 days ago
<Regenaxer>
I like it :)
<Regenaxer>
It concerns the (private)s
<Regenaxer>
(private) is also in pil21 recently, but I think it is wrong
<Regenaxer>
or at least dangerous
<Regenaxer>
pil21 now has a special namespace built-in, in addition to the internal, transient and external namespaces
<Regenaxer>
this 'priv' namespace behaves in a special way
<Regenaxer>
that's why I said "a new concept"
<Regenaxer>
(despite I try to avoid too many concepts)
<beneroth>
the amount of namespaces might become too big xD
<Regenaxer>
Nono :)
<beneroth>
I still use "normal" transient often, but I also burned myself with not thinking about a (load) in the middle ;)
<Regenaxer>
yes
<Regenaxer>
And transients look ugly when used as variables
<Regenaxer>
I rewrote @lib/xhtml.l and @lib/form.l with (private)
<Regenaxer>
in pil21 I mean
<Regenaxer>
But transients continue to work as before
<Regenaxer>
Still nice for a quick local symbol
<Regenaxer>
But 'priv' in pil21 is always there
<Regenaxer>
something between transients and a normal namespace
<Regenaxer>
I'll explain later
<Regenaxer>
When it is clear that it works out well
<Regenaxer>
But so far it looks good
<aw->
Regenaxer: not long ago we discussed parsing a list like this: (2 97 98 5 99 100 26085) so it returns -> "ab" and "cd日"
<beneroth>
Regenaxer, yeah I think I understand :)
<aw->
the problem was mixing rd and char
<aw->
so you suggested an alternate utf-8 parsing
<beneroth>
hi aw- :)
<aw->
hi beneroth
<aw->
so i wonder if i can just add a null byte at the end of each string
<aw->
like this: (2 97 98 0 5 99 100 26085 0)
<aw->
or (3 97 98 0 6 99 100 26085 0)
<aw->
but in that case i guess i dont need the length byte
<aw->
ok never mind ;)
<aw->
actually i'm just curious
<Regenaxer>
hmm, I don't remember exactly
<aw->
how does (char) behave when there's a null byte in the next character?
<Regenaxer>
'C' cannot be used?
<aw->
'C' ? this is a pure picolisp thing, not native
<Regenaxer>
I think (char) returns "^@'
<Regenaxer>
I mean the 'C' spec
<Regenaxer>
like 'B' and 'N' etc
<aw->
(in Fd (char))
<Regenaxer>
Ah, I thought for 'native'
<Regenaxer>
ok, it returns an anonymous symbol:
<Regenaxer>
: (out "a" (wr 0)) (in "a" (char))
<Regenaxer>
-> $344610442461
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
<aw->
hmmm
<Regenaxer>
cause it is a symbol without name
<Regenaxer>
Null-bytes cannot be represented in Pil symbol names
<Regenaxer>
like in C
<Regenaxer>
they are a terminator
<Regenaxer>
So you are reading non-UTF chars?
<Regenaxer>
(char) is not suitable then
<Regenaxer>
it needs UTF-8
<aw->
no no they are UTF-8
<Regenaxer>
ok
<Regenaxer>
: (out "a" (wr 66 0))
<Regenaxer>
: (in "a" (list (char) (char))
<Regenaxer>
-> ("B" NIL)
<Regenaxer>
So it returns NIL
<Regenaxer>
The issue is problematic
<aw->
ahhh ok
<aw->
it returns NIL
<Regenaxer>
yes, but I'm not sure if this is guaranteed
<Regenaxer>
NULL bytes are kind of illegal
<Regenaxer>
beyond the standard data
<Regenaxer>
You also cannot well edit such files
<Regenaxer>
Can't you take another delimiter?
<Regenaxer>
Ideal is "\t"
<aw->
ideally i would have no delimiter
<Regenaxer>
cause you have a count?
<aw->
yes, with a length byte at the beginning of the list
<Regenaxer>
A delimiter is easer and more powerful
<Regenaxer>
eg if the data are more than 256 bytes