[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: on coding a portable R6RS package supporting Guile and its FFI
From: |
Ludovic Courtès |
Subject: |
Re: on coding a portable R6RS package supporting Guile and its FFI |
Date: |
Sun, 27 Jan 2013 16:08:46 +0100 |
User-agent: |
Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) |
Hi Marco,
Sorry for the delay.
Marco Maggi <address@hidden> 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’.