IRC channel logs
2024-09-11.log
back to list of logs
<tohoyn>Debian testing and unstable contain Guile version 3.0.10+really3.0.9-1. Is there some problem with Guile 3.0.10 and Debian? <ArneBab>sneek: later tell tohoyn: Guile 3.0.10 does not build on every architecture of Debian yet. But AFAIK fixes are in the works (or already committed). <leon-p>I want to use guiles FFI to wrap a C function, which returns a struct containing an integer tag and a union of structs. This use case isn't very well documented and from what I've gathered so far by reading docs and the FFI source, this would be quite tedious. Is there perhaps any material on this? <leon-p>(alternatively, I do have control over the C function, so I could redesign it, but would prefer not to) <mwette>tohoyn: 3.0.10 has issues with 32bit architectures <mwette>leon-p: unions are difficult: you could try (list int (list <bounding union>)) <leon-p>yeah, that sounds like the best plan. If I want to later "cast" the data to a different union entry, I suppose I have to convert to a bytevector and re-parse as a C struct? <leon-p>also, why doesn't a foreign object allow containing a #<pointer> as a field? That's a bit odd <mwette>the (bytestructures guile) module has a type system that supports unions. Unions are tricky; libffi does not support unions, so I would try to use pointers <mwette>the ffi helper types currently sit on top of bytestructures, I am working on a leaner "cdata" implementation <leon-p>I was also thinking that it might be simpler to create a module in C with libguile. That would trivialize unpacking the union. I was just hoping to not need any C <mwette>in bytestructures (define ud (bs:union `((a ,int) (b ,double)))) (define data (make-bytestructure ud)) (bytestructure-set! data 'b 3.12) <mwette>make-bytestructure allocates a bytevector for the union <dthompson>guile's ffi works best with pointers that are handles to some foreign object that you can then use other functions to get/set things <dthompson>for accessing the contents of C structs/unions from guile... nothing in guile core but there's the aforementioned bytestructures, guix has something for simple structs, wingo has started on something that might get into core guile, and I've implemented something very similar to chez scheme's ftypes <dthompson>last I checked, bytestructures is handy but inefficient <leon-p>the library I am trying to wrap has a context-pointer which all functions need. What is the most idiomatic way to pass that around? Wrapped in a foreign object or raw? <dthompson>use define-wrapped-pointer-type to wrap the ffi pointers in a disjoint type so you can distinguish them from all other types <dthompson>generally you want to hide all the C nonense behind an interface that feels schemey, and scheme record wrappers around foreign pointers are one way to do that <leon-p>wasn't aware of wrapped pointers, that part of the manual isn't linked from the foreign object / library parts unfortunately, but I like what I see <dthompson>foreign objects are a C interface, not part of the FFI which is a scheme interface <leon-p>as I said, I do control the C API so I can also create an additional function that is more guile friendly. I guess haivng a single API for both direct use in C and for language bindings was unrealistic in the first place :) <dthompson>I guess I assumed you were working in scheme <leon-p>I am working in both C and Scheme: A C library I want to use in Scheme <leon-p>right now I am working on how to bridge the two parts <dthompson>so you have two options: 1) write a C extension that guile can load that provides the bindings or 2) use the ffi from scheme <dthompson>forget about foreign objects then as it's part of guile's C api <leon-p>anyway, this was really helpful, thanks <leon-p>Interesintg, because the docs make it seem like you can use foreign objects in pure scheme bindings <mwette>funny, I'm working on a c-type system also. I work on microcontrollers so I've generated one that can cross compile types, and use offset for pointer accesses. <mwette>dthompson: is your design or wingo's written up? I should post my writeup. <mwette>I have written an AVR microcontroller simulator in C, and I interact with that through Guile. <dthompson>leon-p: there's a small amount of scheme api for it, but it's mostly a C thing. <dthompson>I'd like to iterate on the api a bit but the most important thing works: it generates good bytecode <mwette>I was going to post a link but git.sv is not responding. <mwette>I'll look. I'm not sure mine generates good bytecode, but I'm want to bench against bytestructures. Once a type is "compiled" it only deals with machine types: i32le f64le etc. I guess I should look at the code, and yours. <dthompson>I don't do bitfields yet as I haven't needed them so far <mwette>I also have a function type kind, that contains procedure->pointer and pointer->procedure field, so when I dereference a function pointer I get a procedure. <old>mwette: people still using AVR?? <old>Years back, I developed a cooperative multi-threading environment for AVR 8 bits in school <mwette>AVR is used a lot, making intelligent toys, I guess :) fun stuff <dthompson>AVR programming is fun. haven't done any in years, though. <old>I did have fun yes! My first assembly time <ekaitz>hi! is there any issue in bit-operations.test or is it me? <ArneBab>leon-p: where in the manual would you have needed the link to wrapped pointers? (do you have a link or a reference I can follow in info?) <leon-p>ArneBab: since I was looking to interface with C, I was looking at all sections with "foreign" in the name. I think in the foreign library section where binding C functions is described a link to wrapped pointers would have been nice, maybe in a paragraph about what to do with C functions that return pointers. Perhaps in the "More Foreign Functions" section, which already has similar-ish explanations