<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>sneek: later tell rekado, try (define unwrap~array unwrap~pointer) <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, 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. <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 <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 *mwette is using (system vm elf) to convert microcontroller machine code to modified asm (i.e., CPS asm) for model-checking. <rekado>mwette: thank you for the definition of make-cstr-array! <sneek>Welcome back rekado, you have 2 messages! <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. <mwette>and you don't need make-char*, unwrap~pointer is meant to be forgiving <mwette>And I will use your version in next release, if OK w/ you. I'm only changing the doc-string. <rekado>for some reason the C procedure triggers a crash sometimes, when I run it often enough. <mwette>I wonder if something is being gc'd? Try executing (gc) just before the C function call. <rekado>maybe I need to copy the strings? <mwette>Ah. Yes. When the pointers are converted to integers and stuffed into the bytevector the reference to the strings goes away. <mwette>maybe add a guardian for the list of strings