Hi Marco, Sorry for the delay.
Marco Maggi <[email protected]> skribis: > * Guile does not come with the very simple SRFI 78: > lightweight testing. I had to include it[2][3]. Patches welcome. :-) > * It appears that there is no facility to handle "output > arguments" from C functions; I mean the cases where a C > function accepts as argument a pointer to variable that > will be filled with some computed value. I am using a > WITH-LOCAL-STORAGE[4] macro which is maybe ugly, but > works. I typically roll my own allocation and dereference routines as well, such as ‘make-int-pointer’ and ‘dereference-int’ at: http://git.savannah.gnu.org/cgit/libchop.git/tree/guile2/chop/internal.scm#n255 Perhaps adding them to (system foreign) would help? > Such arguments are common, and represent a nuisance to > handle. Racket has a sophisticated interface, complicated > to use when writing adapter code. Something simpler but > built in would be useful (this is the sort of thing a user > does not want to think about: it should be an already > solved problem). I realize it would be good to have facilities already available for this. However, I’m not familiar with Racket’s FFI, and it’s not clear to me what a good generic API would be. For instance, one could imagine a layer on top of ‘pointer->procedure’ that would allow to specify whether pointer arguments really are output arguments. But then, you’d also have to allow programmers to tell how output arguments are to be allocated (“pointerless” or not, ‘malloc’, etc.), who owns them, what their life cycle is, etc. All in all, it’s always seemed easier to me to do that manually, with helpers specifically adapted to the C library I write bindings for. WDYT? > * Whenever a callout to C accepts a pointer argument: a > bytevector argument is rejected. Is this not a useless > complication? > > One can work around it by explicitly using > BYTEVECTOR->POINTER, so everything is ready in Guile. The > other Scheme implementations using a non-compacting > garbage collector already support this feature and I find > it truly convenient. Well, the ‘pointer’ type is useful, because it’s inherently a more low-level representation than bytevectors. That said, the FFI call could implicitly convert bytevectors to pointers. However, I generally prefer avoiding implicit type conversions like these, for clarify. Thoughts? > * There are no raw memory getters and setters[5]? There’s only ‘dereference-pointer’ now, but I agree we could add more of these, as well as pointer arithmetic operators. > * The limit of 10 arguments for callouts to C is annoying. > It forced me to exclude some SOFA functions resulting in > amputated Guile support. Agreed. Would you like to propose a patch in some of these areas? Thanks for your feedback, Ludo’.
