ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
<aw-> morning, it seems pil21.tgz is not compiling anymore
<aw-> make: opt: Command not found
<aw-> ah i see.. it's a symlink to /usr/bin/opt-7 or opt-8 or opt-9 ...
<aw-> ok i'll fix my build scripts
aw- has quit [Quit: Leaving.]
patrixl has quit [Read error: Connection reset by peer]
patrixl has joined #picolisp
orivej has joined #picolisp
aw- has joined #picolisp
<Regenaxer> Hi aw-, I reverted yesterday's change to mkStr()
<aw-> hi
<Regenaxer> I think it works correctly
<aw-> fixed?
<Regenaxer> No, it worked before
<aw-> oh
<aw-> hmm
<Regenaxer> http://ix.io/2xPn
<Regenaxer> A single null byte returns NIL
<Regenaxer> so all was ok
<Regenaxer> What did you test?
<aw-> ok one sec let me try/test
<Regenaxer> btw, the same with 'buf':
<Regenaxer> (buf P 10 (byte P 0) (%@ "strdup" 'S P))
<Regenaxer> -> NIL
<aw-> did you release the code?
<Regenaxer> yes
<Regenaxer> but yesterday's code behaved the same
<Regenaxer> I just removed the additional check again
<Regenaxer> as it was before
<aw-> pil21$ ./pil
<aw-> !? (byte P 0)
<aw-> NIL -- Number expected
<aw-> : (byte P 0)
<Regenaxer> So it seems I misunderstood the problem
<aw-> arm64 problem?
<Regenaxer> Nono
<Regenaxer> what is 'P'?
<aw-> oh oops
<aw-> forgot to malloc
<Regenaxer> yes
<Regenaxer> or see 'buf' above
<Regenaxer> is shorter and does not need free()
<Regenaxer> Also, in fact strdup() is not a good idea
<Regenaxer> it creates a memory leak, no way to free it
<Regenaxer> better use 'struct'
<Regenaxer> : (buf P 10 (byte P 65) (byte (inc P) 0) (struct
<Regenaxer> P 'S))
<Regenaxer> -> "A"
<aw-> ok wait
<aw-> i'm testing
rob_w has joined #picolisp
<aw-> what is (buf) ?
<aw-> theres no docs
<Regenaxer> A new function
<aw-> ohhhh
<aw-> pil21 ?
<Regenaxer> I mentioned yesterday
<aw-> hmmm
<Regenaxer> check the logs
<aw-> ok but my code needs to run on pil64
<Regenaxer> I said it is faster and needs no free()
<aw-> right but i can't code **only** for pil21
<Regenaxer> yep
<aw-> let me try some things
<aw-> strdup can't be free'd ? that's not good
<Regenaxer> yeah
<aw-> sorry, yesterday i didnt realize (buf) is only for pil21
<Regenaxer> 'native' does not know that it allocates new memory
<Regenaxer> see pil21/doc/diff
<Regenaxer> The 'P' spec also does not exist in pil64
<aw-> right
<Regenaxer> but (struct P 'S) instead of strdup works
<aw-> ok but
<Regenaxer> and is more efficient
<aw-> you're missing what i'm saying
<aw-> i can **NOT** code only for pil21
<Regenaxer> ok?
<aw-> even though pil21 has these nice functions, my code is for pil64
<Regenaxer> yes, but where is the problem?
<Regenaxer> you use malloc()
<Regenaxer> everything else works
<Regenaxer> 'P -> 'N of course
<aw-> ok so you're saying i need to use two different approaches for reading data?
<aw-> one for pil21, one for pil64?
<Regenaxer> No!!!
<Regenaxer> you are not reading ;)
<Regenaxer> ok, I ran this on pil64: http://ix.io/2xPt
<Regenaxer> Anyway, what was your null-byte-problem yesterday?
<aw-> let me try
mtsd has joined #picolisp
<aw-> Regenaxer:
<aw-> how can i use this with (native) ?
<aw-> i'm not storing a byte in memory
<Regenaxer> It is just an example
<aw-> i'm retrieving bytes from a (native)
<Regenaxer> yes, same
<Regenaxer> I thought you read a string from a memory locatiin
<aw-> no
<Regenaxer> I understood some function fills a buffer you provide
<aw-> i call (native "lib" "fun" 'I Buffer) and it returns the bytes in Buffer
<Regenaxer> Exactly what I say!
<Regenaxer> As in the above example
<Regenaxer> 'byte' is used to fill the buffer :)
<Regenaxer> Must telephone, bbl
<aw-> (byte P (native ...)) ?
<aw-> i have no idea how (byte) works, let me figure that out first
<Regenaxer> (byte P (char "A")) is as (byte P 65) above
<aw-> ok
<aw-> but i'm trying to read more than 1 byte
<aw-> not store 1 byte
<aw-> it makes no sense
<aw-> you're explaining the exact opposite of what i want to do
<Regenaxer> See above!
<Regenaxer> I stored "A" and null
<aw-> ok wait
<aw-> please wait
<Regenaxer> and got the string "A"
<aw-> stop giving me solutions, you don't know what i'm trying to do
<aw-> let me explain first
<Regenaxer> But you should try to understand the example
<Regenaxer> most basic mechanisms
<aw-> i am but you keep throwing code at me and telling me "LOOK IT WORKS"
<aw-> im trying to understand but you keep giving examples which don't apply
<Regenaxer> it was all the same, basically a single example
<Regenaxer> storing two bytes, giving "A\0"
<aw-> ok but i am NOT storing bytes!
<aw-> i keep telling you this
<Regenaxer> not you, but the function
<aw-> i dont know the memory location where the data is stored
<aw-> unless there's a way to get it?
<beneroth> do you have to allocate the buffer, or is the lib allocating the buffer?
<aw-> the function wants a buffer to store the bytes
<beneroth> hi aw-, Regenaxer :)
<aw-> i have to allocate it
<Regenaxer> telephone
<aw-> hey bene
<beneroth> so your question is: how to allocate a buffer for native to write in?
<aw-> beneroth: no
<aw-> i know how to do that
<aw-> i'm trying to figure out how (byte) can be used with (native)
<beneroth> I understand byte (first form with single argument) as: reads a single byte from the pointer you give it
<beneroth> the number argument being a pointer
<beneroth> so I guess you could use the address of the buffer you give into native as argument to (byte) to get the number representation of the first byte in the buffer
<aw-> (native "lib" "fun" 'I Msg) # Msg = buffer which receives the message, 'I = number of bytes (size) of message
<Regenaxer> 'byte' has nothing at all to do with 'native'
<beneroth> message format is text or binary, aw- ?
<beneroth> Regenaxer, T, I understand it as: turns raw bytes into picolisp numbers
<aw-> beneroth: it's just bytes, could be text, could be random garbage
<beneroth> so binary, as far as it concerns you
<aw-> i wrote my (native) code above, how do I get the string from Msg? (byte Msg) ?
<aw-> (byte Msg) (struct Msg 'S) ?
<Regenaxer> Sorry, on phone
<Regenaxer> (byte Msg (char "a")) (byte (+ Msg 1) (char "b")) (byte (+ Msg 2) (char "c")) (byte (+ Msg 3) 0)
<Regenaxer> gives "abc" in C
<Regenaxer> get the string "abc" with (struct Msg 'S)
<Regenaxer> a string in C is an array of bytes, with null at the end
<aw-> ok
<aw-> so i dont need (byte)
<aw-> ok well
<aw-> in any case
<aw-> with (struct Msg 'S) i still get the same problem with pil21
<Regenaxer> Then 'fun' is wrong
<aw-> yes yes i didnt give the full spec
<aw-> it's actually (native "lib" "fun" 'I Fd Msg Size)
<aw-> Size being the size of the buffer I created with malloc
<aw-> your example is fine, seems my code is doing something weird
<Regenaxer> phone done
<aw-> ah
<aw-> ok
<aw-> i found the bug
<Regenaxer> :)
<aw-> ugh
<aw-> the problem is not at all with the receiving function
<aw-> it's the sending
<Regenaxer> filling the buffer?
<aw-> when i send only a null byte, the Size should be 0, not 1..
<Regenaxer> the returned size, yes
<aw-> yes so i was always adding +1 for regular strings because they include the nullbyte
<Regenaxer> but the size is not needed to get the string into Lisp
<aw-> no
<Regenaxer> strdup or (struct Msg 'S)
<aw-> the C (native) function needs it
<Regenaxer> ok
<Regenaxer> perfect
<aw-> however it doesn't explain why i had no problem in pil64
<Regenaxer> so the strange result yesteday is gone?
<aw-> and only discover this issue in pil21
<aw-> i think the bug gis in pil21 actually
<Regenaxer> What exactly happened?
<Regenaxer> does it still appear?
<Regenaxer> and different in 64 and 21?
<aw-> wait
<aw-> i wonder if NIL is a null byte?
<aw-> or "" ?
<Regenaxer> NIL is a symbol, and a byte is a number
<Regenaxer> "" is *read* as NIL
<Regenaxer> in C "" is a single null byte
<beneroth> NIL is not the same thing as NULL byte, generally in picolisp
<beneroth> e.g. there is a encoding for NIL in plio, afaik
<aw-> hmmm
<beneroth> empty string and empty list are NIL
<aw-> "Also note that specifying NIL as an argument passes an empty string ("", which also reads as NIL in PicoLisp) to the C function. Physically, this is a pointer to a NULL-byte"
<aw-> ok so
<aw-> my question: how many bytes in "" ?
<Regenaxer> in C ?
<aw-> yes
<Regenaxer> "" is a pointer to a single null byte
<Regenaxer> strlen() gives zero
<Regenaxer> Like I did above (byte P 0) (struct P 'S) -> NIL
<aw-> right
<aw-> ok i'm seeing the same thing
<aw-> ok so
<Regenaxer> Mysterious what it was yesterday
<aw-> in pil64, when I send the value "", i also send the string size 1
<Regenaxer> I think you saw "^@" ?
<aw-> because "" is 1 byte
<Regenaxer> yes, but the size is not used here
<Regenaxer> the length
<aw-> but in pil21, when I send the value "", i have to send the string size 0, otherwise i get back some garbage
<aw-> size/length..
<Regenaxer> With "send" you mean "store in buffer"?
<aw-> there's definitely a problem somewhere either in pil21 or pil64
<aw-> yes, and then send to the (native) function
<aw-> in pil21 and pil64, i always store the exact same value: "", and supply the exact same string length: 1
<Regenaxer> We should clear up that "problem somewhere either in pil21 or pil64"
<aw-> but in pil21 it returns garbage when i try to read the value
<Regenaxer> how do you store "" ?
<Regenaxer> I C you do *p = '\0';
<Regenaxer> if 'p' is the buffer pointer
<Regenaxer> you cant *store" ""
<aw-> (native "lib" "fun" 'I Fd NIL (+ (size NIL) 1))
<beneroth> string length vs. buffer length ?
<aw-> string length
<Regenaxer> (size NIL) ?
<beneroth> string length should be 0 with buffer length 1
<beneroth> I'd say
<beneroth> (for empty string)
<aw-> i'm not using a buffer here
<aw-> just passing the value directly
<Regenaxer> I don't get it
<Regenaxer> what you are really doing
<aw-> actually it's: (native "lib" "fun" 'I Fd Msg (+ (size Msg) 1))
<aw-> Msg can be anything, like "hello" or "test" or ""
<beneroth> why (size Msg) and not (length Msg) ?
<aw-> string length (in bytes)
<Regenaxer> ok
<aw-> i believe it's in bytes, handles utf-8 correctly
<beneroth> right
<Regenaxer> yep
<Regenaxer> So what goes wrong in pil64 or pil21?
<aw-> so the problem is when I try to re-read that string once more with (native) and the C code
<Regenaxer> first 'fun' runs
<Regenaxer> it gets the string Msg
<Regenaxer> what does it do?
<Regenaxer> There is no buffer involved
<aw-> I do (native "lib" "fun2" 'I Fd Buf Size) # get the data into 'Buf' buffer
<Regenaxer> yesterday you said you get the wrong string from the buffer
<aw-> yes
<Regenaxer> ok, fun2
<aw-> in pil21 i get garbage
<aw-> it's always different
<aw-> like a non null-terminated string
<Regenaxer> Buf is malloc'ed?
<Regenaxer> and then (struct Buf 'S) ?
<aw-> yes
<aw-> exactly
<Regenaxer> are you sure it is not fun2 filling in garbage?
<Regenaxer> I don't believe we have a bug here in pil
<Regenaxer> it is too basic
<Regenaxer> It would never work
<aw-> wait let me try some more tests
<aw-> holy shit
<aw-> when i receive just \0 (null byte) in pil21, it spits out the entire library I loaded with (load)
<Regenaxer> whole memory
<aw-> yes
<aw-> i think because my buffer is 8K
<Regenaxer> The buffer contains only '\0'?
<Regenaxer> pil does not care about the size
<Regenaxer> it goes till '\0'
<Regenaxer> I think pil21 is correct
<aw-> one sec
<Regenaxer> tested with
<Regenaxer> : (buf P 10 (byte P 0) (struct P 'S))
<Regenaxer> -> NIL
<Regenaxer> There is not more to it!
<aw-> ok good
<aw-> i'm debugging my code now
<Regenaxer> I think fun2 does not store the null byte
<aw-> i trust you more than myself for pil code haha
<Regenaxer> then the result depends on the random memory layoout
<aw-> omg
<aw-> i found it
<aw-> wow i'm so stupid
<aw-> ok before i tell you
<aw-> can you explain this argument for (native):
<aw-> (native "lib" "fun" 'I (list 'Attr (64 N . 4) 0))
<aw-> there is something wrong with that
<Regenaxer> hmm, looks good
<Regenaxer> a 64 byte buffer
<Regenaxer> but only the first byte is set to 0
<Regenaxer> you could (64 N . 4) . 0)
<Regenaxer> this fills all 64 bytes
<Regenaxer> and 32 would be enough
<Regenaxer> for long[4]
<aw-> the result is stored in Attr right?
<aw-> i wonder if this is a bug in the native C function
<Regenaxer> yes, Attr receives 4 numbers
<Regenaxer> as a list
<aw-> hmmm
<aw-> it seems like there's memory not being free'd somewhere
<Regenaxer> oh
<Regenaxer> This has not yet been tested in pil21 perhaps
<aw-> yeah
<Regenaxer> How do you notice? Called in a loop?
<aw-> when i make a call to malloc, after using that (native) i showed above, then that buffer gets filled with... my source code
<aw-> i change the malloc to 256 and it fills it with 256 bytes of my source code haha
<aw-> only happens after i use that structure to get a 64-byte result
<aw-> which works perfectly
<aw-> i get '(0 10 8192 1)' from that native call
<Regenaxer> but 4 * 8 is 32
<aw-> err not 64-byte sorry, 8 longs
<aw-> err yes
<aw-> it's weird
<Regenaxer> (64 N . 4)
<aw-> ah!
<aw-> should be 8
<aw-> OMG
<aw-> ok my problem is fixed
<aw-> wow what a fail
<Regenaxer> :)
<aw-> guhhhhhhhhhhh
<aw-> i can't believe I did (64 N . 4) ahahaha
<Regenaxer> happens to me too
<aw-> wait let me test again to confirm
<Regenaxer> confusing with cell size
<aw-> no
<aw-> sorry
<aw-> the problem is (struct) in pil21
<aw-> but only when the value is a null-byte
<aw-> i tried so many things, and narrow it down to (struct Msg 'S) where Msg points to a memory location containing only a null-byte
<aw-> it fills my malloc'd buffer with.. my source code
<Regenaxer> : (buf P 10 (byte P 0) (struct P 'S))
<Regenaxer> this is the minimal tes
<Regenaxer> t
<Regenaxer> this can't be different in your case
<aw-> but this only happens after I call (native) with the structure above
<aw-> i dont know why
<aw-> something is not being free'd
<aw-> yes the simple test/example works fine for me too
<Regenaxer> This has nothing to do with freeing
<Regenaxer> You see a memory leak if you make a loop
<Regenaxer> and watch the process size grow
<Regenaxer> getting garbage has nothing to do with not freeing
<aw-> right
<aw-> ok let me try that
<Regenaxer> free() just does some pointer changes in the heap
<aw-> i will try this code on a different machine, different kernel
<Regenaxer> I do a loop now
<Regenaxer> (%@ "localtime" '(I . 9) ...
<Regenaxer> ok, memory is not increasing :)
<Regenaxer> No leak
<aw-> Regenaxer: (list 'Attr (64 N . 8) . 0)
<aw-> this result specification, is there another way to write it?
<aw-> perhaps i can malloc 64 bytes
<aw-> and store into that
<Regenaxer> You can also (64 (N . 8))
<Regenaxer> malloc is ok, but native does exactly that
<Regenaxer> in pil21 even on the stack iirc
<Regenaxer> but (64 (N . 8)) will give ((...))
<Regenaxer> and (64 ((N . 8))) gives (((...)))
<Regenaxer> :)
<aw-> Regenaxer: with this: (struct Mem 'N (0 . 8) (0 . 8) (0 . 8) (0 . 8))
<aw-> is it similar to struct mystruct { long a; long b; long c; long d; } ?
<aw-> ;
<Regenaxer> hmm, (0 . 8) is a fixpoint number
<Regenaxer> And what is 'N' ?
<aw-> oh
<Regenaxer> { long a; long b; long c; long d; } is simply (N N N N)
<aw-> Pointer
<aw-> ok so (struct Mem '(N N N N)) ?
<Regenaxer> yeah
<Regenaxer> '(N N N N) is the returned list
<Regenaxer> no initialization
<Regenaxer> Sorry, I was wrong with the fixpoint
<Regenaxer> for *init* items (0 . 8) is fine
<Regenaxer> a long with value zero
<aw-> ok ok
<Regenaxer> I confused with 'native' arguments
<aw-> hmmm
<aw-> ok so
<Regenaxer> It *is* confusing
<aw-> in pil64, if I use malloc to allocate a 256 byte buffer
<Regenaxer> C has so many argument types
<aw-> and then (native "lib" "fun2" 'I Fd Buf 256)
<aw-> the result in Buf is different between pil21 and pil64
<aw-> but only IF Buf "only" contains a null-byte
<aw-> does that make sense?
<aw-> in pil21, that null byte ends up doing something weird and the Buf gets filled with the source code of my library
<Regenaxer> hmm, strange
<aw-> yes indeed
<Regenaxer> you then do (struct Buf 'S) ?
<aw-> i am using (struct Buf 'S) to get the actual string
<aw-> yes
<Regenaxer> ok
<Regenaxer> But (struct Buf 'S) can't be wrong
<Regenaxer> Have you looked directly into the memory?
<Regenaxer> What gives (struct Buf B B B B B B B) ?
<aw-> wait
<aw-> can you tell me
<aw-> is this wrong: (let Str (struct Msg 'S) ... )
<Regenaxer> no, fine
<aw-> i mean.. does the value end up in Str or in Msg ?
<Regenaxer> Msg is a number
<aw-> yes
<Regenaxer> struct returns a Lisp symbol for 'S' spec
<aw-> so i'm correct to use Str
<Regenaxer> the 'let' is irrelevant here
<aw-> ok let me inspect the bytes directly
<aw-> (78 40 83 105 122 101 32 32)
<aw-> ("N" "(" "S" "i" "z" "e" " " " ")
<aw-> this is in my source code
<aw-> hahahaha
<Regenaxer> wrong above of course, must be (struct P '(B B B B B B))
<Regenaxer> we want the list of raw bytes
<aw-> yes i know
<aw-> i fixed it ;)
<Regenaxer> cool
<Regenaxer> So (78 40 83 105 122 101 32 32) does not start with 0
<Regenaxer> fun2 does not fill the buffer correctly
<Regenaxer> It is normal that an uninitialized buffer contains some old data
<Regenaxer> from a previously free'd buffer
<aw-> right
<aw-> makes sense
<Regenaxer> can be anything
<Regenaxer> So why is there no null byte in the first position?
<aw-> but i'm sending NIL as an argument in my (native) call
<aw-> good question
<aw-> wait let me try the same test with pil64
<aw-> (0 138 121 123 127 0 0 0)
<aw-> hah
<aw-> 100% exact same code
<Regenaxer> but fun2 is wrong
<aw-> why?
<Regenaxer> it does not fill the buffer
<aw-> hmmm ok that makes sense
<aw-> ok let me try
<aw-> would this work: (struct Msg 'N (0 . 256))
<Regenaxer> Not (struct Msg 'S (0 . 256)) ?
<Regenaxer> N returns the pointer
<aw-> hmmm no
<aw-> that makes no sense
<aw-> why would i fill it with zeros _after_ calling (native) ?
<Regenaxer> with 'struct' or 'byte'
<aw-> you mean fill it _before_ (native), right?
<Regenaxer> depend
<Regenaxer> s
<aw-> so i am calling (struct) twice?
<Regenaxer> the arguments to 'native' only fill the *temporary* buffer
<Regenaxer> allocated and freed by native
<Regenaxer> struct takes a pointer to an *existing* buffer
<aw-> right
<aw-> right
<aw-> got that
<aw-> (let Msg (native "@" "malloc" 'N 256)
<aw-> Buf (struct Msg 'S (0 . 256))
<aw-> Res (native "lib" "fun" 'I Fd Msg 256)
<aw-> Str (struct Msg 'S)
<Regenaxer> looks good
<aw-> yes
<aw-> same here
<aw-> but when i print out Str
<aw-> i get "N"
<Regenaxer> Why is the init necessary
<Regenaxer> fun2 fills the buffer
<aw-> yes it's not necessary
<aw-> for some reason, in pil21 it fills the buffer with my source code
<Regenaxer> you call "fun"
<Regenaxer> I thought "fun2"
<aw-> same thing.. im renaming things everywhere and testing
<aw-> sorry for the name change
<Regenaxer> ok
<Regenaxer> no problem
<aw-> my code is a huge mess now haha
<Regenaxer> I understand it is pseudo code
<Regenaxer> I would test it all in the repl
<Regenaxer> not messing with sources
<aw-> yeah i wrote a script to run the tests so it's fairly quick
<Regenaxer> I did all above tests only in repls on 64 and 21
<Regenaxer> T, reload is even faster
<Regenaxer> tel
<aw-> no prob
<aw-> i will write some more here
<aw-> i init the buffer to 256 0s, then call (native) which fills the buffer with data, then call (struct) to extract the string
<aw-> however
<aw-> when the buffer _only_ contains a null-byte, I instead get (78 0 0 0 0 0 0 0) as a result using (struct Msg '(B B B B B B B B))
<aw-> which is crazy
<aw-> i'm not sure why
<aw-> in pil64 i get: (0 0 0 0 0 0 0 0)
<aw-> oh...
<aw-> N
<aw-> is the first letter from NIL
<aw-> i wonder if it's taking just the first byte from NIL and returning that
<aw-> instead of converting NIL to a null-byte
<aw-> Regenaxer i think i found the problem
<Regenaxer> phone done
<Regenaxer> yes, "" stores the string "NIL", both in 64 and 21
<Regenaxer> ha! no!
<Regenaxer> only in pil21!!!
<Regenaxer> So that is it!
<Regenaxer> : (native "@" "strdup" 'S "")
<aw-> :O
<Regenaxer> -> "NIL"
<Regenaxer> This is wrong
<aw-> yeahhhhh
<aw-> that's what i'm seeing
<Regenaxer> pil64 returns NIL
<aw-> yes
<Regenaxer> ok, I will check
<aw-> i wish i knew enough native/C to debug this a lot quicker haha
<Regenaxer> no problem
<Regenaxer> I will try to find it
<Regenaxer> forgot the internals of 'native' meanwhile
<aw-> ok thanks
<aw-> i'll be back later, dinner time :)
<Regenaxer> struct in pil64 behaves the same
<Regenaxer> (struct P 'S '("" . 4)) -> "NIL"
<Regenaxer> this is in both
<Regenaxer> ok, later, enjoy dinner!
mtsd_ has joined #picolisp
mtsd_ has quit [Client Quit]
mtsd has quit [Ping timeout: 260 seconds]
<Regenaxer> Fixed and released it
<Regenaxer> Note that in pil64 it is still wrong:
<Regenaxer> : (setq P (native "@" "malloc" 'N 99))
<Regenaxer> -> 494132412416
<Regenaxer> : (struct P 'S '("" . 4))
<Regenaxer> -> "NIL"
<Regenaxer> : (struct P '(B B B B))
<Regenaxer> -> (78 73 76 0)
<Regenaxer>
<Regenaxer> pil21 now does:
<Regenaxer> : (setq P (native "@" "malloc" 'N 99))
<Regenaxer> -> 533404266496
<Regenaxer> : (struct P 'S '("" . 4))
<Regenaxer> -> NIL
<Regenaxer> : (struct P '(B B B B))
<Regenaxer> -> (0 0 0 0)
<Regenaxer>
<Regenaxer> i.e. for string pointers in structures
<Regenaxer> as native *argument*s now both do:
<Regenaxer> : (native "@" "strdup" 'S "")
<Regenaxer> -> NIL
<Regenaxer> (this gave "NIL" in pil21 before)
mtsd has joined #picolisp
<Regenaxer> Hmm, aw-, I still don't understand
<Regenaxer> The above is about cases where the buffer is filled from Lisp
<Regenaxer> but in your case your C function filled it
<aw-> works on pil21!
<aw-> pil64 seems fine though
<aw-> but i'm not sure why
<Regenaxer> so it is not fun?
<Regenaxer> You fill the buffer from Lisp, as the above examples?
<aw-> yes
<Regenaxer> I'm confused
<aw-> (let Msg (native "@" "malloc" 'N 256)
<aw-> Buf (struct Msg 'S (0 . 256))
<Regenaxer> anyway, makes sense then
<Regenaxer> yes
<Regenaxer> (struct Msg 'S (0 . 256) worked though
<aw-> yes
<aw-> no, i dont think so
<aw-> is there a way to check?
<Regenaxer> No, this always worked
<aw-> oh wait
<aw-> you're right
<aw-> it does
<Regenaxer> What I changed now is NIL or "" argument
<aw-> right
<Regenaxer> grr, why is this such a mess?
<aw-> haha you're asking me?
<Regenaxer> It is not clear at all what you are doing
<aw-> oh ok
<aw-> i will release my code shortly and you can review if you want
<aw-> just need to finish my documentation
<Regenaxer> good
<Regenaxer> You said all the time that the C function fills the buffer, and you want to fetch the value from Lisp
<Regenaxer> Anyway, pil21 'native' was wrong
<Regenaxer> and pil64 'struct' is still wrong, I won't fix
<Regenaxer> Well, not "wrong"
<aw-> wait i broke something.. not sure if the new release works
<Regenaxer> but it is more useful if NIL is stored as empty string
<Regenaxer> oh
<Regenaxer> As I said, it is not clear at all what you want to do
<aw-> ok yes it's fixed
<aw-> my code was broken, reverted everything and all tests pass now
<Regenaxer> So you have code that passes NIL
<aw-> yes
<Regenaxer> ok
<aw-> the new release fixed it
<Regenaxer> great! :)
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
<aw-> Regenaxer: i copied your (sysdefs) from lib.l
<aw-> for pil64
<Regenaxer> good idea
<aw-> so no need to check which version anymore
<Regenaxer> OS version?
<aw-> *OS
<aw-> err
<aw-> (version)
<aw-> (> (version T) (21)) not needed
<Regenaxer> great
mtsd has quit [Quit: Leaving]
<aw-> ok Regenaxer thanks for your help!
aw- has quit [Quit: Leaving.]
rob_w has quit [Quit: Leaving]
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 264 seconds]
DKordic has joined #picolisp
orivej has joined #picolisp
<tankf33der> i've found code which 4x faster on pil21 than on pil64.
<tankf33der> of course pil21 opted.
<Regenaxer> Rather long functions, right?
<Regenaxer> I.e. little function call overhead
<tankf33der> yea, big math of rsa.l
<Regenaxer> yes
<Regenaxer> this can be optimized
<Regenaxer> register usage
<Regenaxer> The problem is many small functions calling each other
<Regenaxer> the interpreter itself
<Regenaxer> But 4 times is really a lot
<Regenaxer> Would be interesting to know *which* function
<Regenaxer> eg. '*' or '/'
<tankf33der> prime? of rsa.l
<Regenaxer> or '+'
<tankf33der> afk.
<Regenaxer> perhaps 'bit?' ?
<Regenaxer> no
<Regenaxer> it calls almost everything
<Regenaxer> also div
orivej has quit [Ping timeout: 256 seconds]
jibanes has quit [Ping timeout: 265 seconds]
jibanes has joined #picolisp