IRC channel logs

2020-10-09.log

back to list of logs

<mwette>rekado: I think I can fix. Can you file a bug report? The issue with unsized arrays is fixed. (bytestructures guile) does not support but I added to ffi-help-rt.
<mwette>I will look soon (this weekend latest).
<mwette>rekado: Can you try this: (define unwrap~array unwrap~pointer)
<mwette>I had struggled with how to handle unsized arrays like foo_t x[]. (bytevectors guile) does not deal with this case, so I extended the bs:pointer case to handle integer dereferences (i.e., (bytevector-ref x '*) works but so does (bytevector-ref x 0)
<mwette>s/bytevector/bytestructure
<mwette>sneek: later tell rekado, try (define unwrap~array unwrap~pointer)
<sneek>Got it.
<mwette>sneek: botsnack
<sneek>:)
<chrislck>you guys are very clever with guix and srfis, but down on earth it's not easy :)
<leoprikler>chrislck: I think the writer of SRFI 180 simply expects you to add /path/to/git/checkout to your load path
***rekado_ is now known as rekado
<rekado>mwette: I tried (define unwrap~array unwrap~pointer), but I’m not sure what to provide as the vector. When I give it a mere list of strings it says “expecting pointer type”.
<sneek>rekado, you have 1 message!
<sneek>rekado, mwette says: try (define unwrap~array unwrap~pointer)
***apteryx_ is now known as apteryx
<mwette>rekado: thanks -- I will look into it. I think there is a similar glib arg somewhere.
<mwette>sneek: later tell rekado: try https://paste.debian.net/1166490/
<sneek>Will do.
<nerdypepper>hiya, what exactly does `>` do when you supply more than 2 args?
<RhodiumToad>> is true if all the args form a strictly descending sequence
<mwette>sneek: later tell rekado: needs pointer-address: https://paste.debian.net/1166491/
<sneek>Will do.
<RhodiumToad>i.e. (> a b c ...) is (and (> a b) (> b c ...))
<nerdypepper>ah i see, ty RhodiumToad, where can one find/read implementations of these functions?
<RhodiumToad>well, for primitives they're in C code in libguile/* in the sources
<RhodiumToad>for non-primitives, mostly in the (ice-9 boot-9) module
<lloda>nerdypepper: (help >) does work, surprisingly
<lloda>i believe there are still many primitives without online help
<lloda>like (help cons) doesn't give anything
<chrislck>Hellllooo Fridayyyy
<nerdypepper>lloda: ah, thanks
*mwette is using (system vm elf) to convert microcontroller machine code to modified asm (i.e., CPS asm) for model-checking.
<stis>hej guilers!
<RhodiumToad>good evening
<rekado>mwette: thank you for the definition of make-cstr-array!
<sneek>Welcome back rekado, you have 2 messages!
<sneek>rekado, mwette says: try https://paste.debian.net/1166490/
<sneek>rekado, mwette says: needs pointer-address: https://paste.debian.net/1166491/
<rekado>Unfortunately, bv-set! is undefined because (sizeof '*) returns 8.
<rekado>(I don’t know if that’s unexpected)
<rekado>I suppose I could use bytevector-u64-native-set! for now
<rekado>so, this creates a bytevector that is big enough for n pointers, where n is the number of strings.
<rekado>it then stores the address of a pointer for each string in the bytevector, eventually returning a vector of pointer addresses.
<mwette>the cases should be (4) and (8) not (32) and (64)
<mwette>yes. I think that is what the C code is expecting
<rekado>I think bv-set! should use (* (sizeof '*) index) instead of just the index
<rekado>(just by looking at the resulting bytevector)
<rekado>unfortunately, when I pass this to the C procedure Guile crashes, but that might be an unrelated mistake
<rekado>I’m passing it with (pointer-to (make-cstr-array (list "hello" "world"))) after defining unwrap~array as unwrap~pointer
<rekado>oh, it worked with (make-char* (bytevector->pointer (make-cstr-array (list …))))
<mwette>Oh. I thought unwrap~pointer dealt with bytevectors. I will add that.
<mwette>Ah, the index is byte offset. I fill fix. Thanks.
<rekado>FWIW this is the variant of make-cstr-array that I’m using now: https://paste.debian.net/1166540/
<mwette>and you don't need make-char*, unwrap~pointer is meant to be forgiving
<rekado>okay
<mwette>And I will use your version in next release, if OK w/ you. I'm only changing the doc-string.
<rekado>sure!
<rekado>for some reason the C procedure triggers a crash sometimes, when I run it often enough.
<rekado>let’s see…
<mwette>I wonder if something is being gc'd? Try executing (gc) just before the C function call.
<rekado>seems so
<rekado>with (gc) it crashes reliably
<rekado>maybe I need to copy the strings?
<mwette>Hmm. I don't know.
<rekado>I’ll play with this
<mwette>Ah. Yes. When the pointers are converted to integers and stuffed into the bytevector the reference to the strings goes away.
<mwette>s/integers/integer addresses/
<mwette>maybe add a guardian for the list of strings