From: ludo@gnu.org (Ludovic Courtès)
To: guile-user@gnu.org
Subject: Re: on coding a portable R6RS package supporting Guile and its FFI
Date: Sun, 27 Jan 2013 16:08:46 +0100 [thread overview]
Message-ID: <87txq24q9t.fsf@gnu.org> (raw)
In-Reply-To: 87y5fsw05u.fsf@rapitore.luna
Hi Marco,
Sorry for the delay.
Marco Maggi <marco.maggi-ipsu@poste.it> 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’.
next prev parent reply other threads:[~2013-01-27 15:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-17 10:53 on coding a portable R6RS package supporting Guile and its FFI Marco Maggi
2013-01-27 15:08 ` Ludovic Courtès [this message]
2013-01-28 3:00 ` Daniel Hartwig
2013-02-05 17:38 ` Andy Wingo
2013-02-05 19:29 ` Noah Lavine
2013-02-06 8:36 ` Andy Wingo
2013-02-06 13:25 ` Noah Lavine
2013-02-05 22:31 ` Ludovic Courtès
2013-02-06 10:57 ` Andy Wingo
2013-02-08 14:10 ` Ludovic Courtès
2013-02-08 14:37 ` Andy Wingo
2013-02-08 15:52 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87txq24q9t.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).