From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.user Subject: Re: on coding a portable R6RS package supporting Guile and its FFI Date: Mon, 28 Jan 2013 11:00:03 +0800 Message-ID: References: <87y5fsw05u.fsf@rapitore.luna> <87txq24q9t.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1359342020 18211 80.91.229.3 (28 Jan 2013 03:00:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Jan 2013 03:00:20 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jan 28 04:00:40 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tzexb-0002OQ-GF for guile-user@m.gmane.org; Mon, 28 Jan 2013 04:00:39 +0100 Original-Received: from localhost ([::1]:34640 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzexJ-0006aj-Qn for guile-user@m.gmane.org; Sun, 27 Jan 2013 22:00:21 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:40479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzexC-0006aR-Ku for guile-user@gnu.org; Sun, 27 Jan 2013 22:00:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tzex7-0005SI-Ei for guile-user@gnu.org; Sun, 27 Jan 2013 22:00:14 -0500 Original-Received: from mail-ie0-x22c.google.com ([2607:f8b0:4001:c03::22c]:62302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tzex7-0005LN-5a for guile-user@gnu.org; Sun, 27 Jan 2013 22:00:09 -0500 Original-Received: by mail-ie0-f172.google.com with SMTP id c10so615747ieb.3 for ; Sun, 27 Jan 2013 19:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=jfLBe1LNdWxdOIh++0d6j9sRiaJTSrUTxuzy3pugLIs=; b=qYV4BSrBAEzrebK+W0Wcdf6wtfOfWGWcpQzbcKBDZHrGcN8nLMR6OntUvMoW//oZzn bT1VEaif3dMbkZAgcbxw/tYj91GI6qXt7egvSQANfNgLROBlmAJY/Zj2lHNbOYtc3E03 x9xE4GYnGZk04rp6QHE0ki2G/oXSJF7n1Y0TziHSkvduMmQL1ywRIM47JSvbZOg9Nxs+ AX5WhUvNrsTBmkqRZ4PdsXhCAAkBqUQ1DS5Pt+rrX+A+E/WmWU0iZ3GEQ75FP55cH+f4 xUs9i0GZANwNJm0SPvV/Hlb6ZRcIcjzoszo3TENET8LyRnflOUq8qxapmiXEwfVyEs/2 OOkQ== X-Received: by 10.50.12.201 with SMTP id a9mr1788693igc.10.1359342003465; Sun, 27 Jan 2013 19:00:03 -0800 (PST) Original-Received: by 10.64.76.51 with HTTP; Sun, 27 Jan 2013 19:00:03 -0800 (PST) In-Reply-To: <87txq24q9t.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22c X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:9924 Archived-At: On 27 January 2013 23:08, Ludovic Court=C3=A8s wrote: > Hi Marco, > > Sorry for the delay. > > Marco Maggi skribis: >> * 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 =E2=80=98make-int-pointer=E2=80=99 and =E2=80=98dereference-int= =E2=80=99 at: Likewise. > > http://git.savannah.gnu.org/cgit/libchop.git/tree/guile2/chop/internal.= scm#n255 > > Perhaps adding them to (system foreign) would help? Yes, in these generic cases. > >> 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 Pointer arguments are common, yes, but they have a variety of usage patterns across different APIs. This is evident in the complexity of the Racket API for dealing with this. In particular, the questions of who (caller or callee) allocates the memory and who deallocates the memory complicate the handling. In some APIs, the party in control of deallocation can=C2=A0change. >> (this is the sort of thing a user >> does not want to think about: it should be an already >> solved problem). Mapping any pointer interface requires some user thought to consider its unique behaviour. It is risky to abstract some of that process away from the programmer, even if only to accomodate a single, =E2=80=9Cmos= t common=E2=80=9D usage. IMO the best that could be done without complicating the FFI is to bring in a small set of generic helpers such as Ludo's make-int-pointer, etc.. > =E2=80=A6 > > All in all, it=E2=80=99s always seemed easier to me to do that manually, = with > helpers specifically adapted to the C library I write bindings for. > > WDYT? Right. After considering the requirements for any given interface it is only a small amount of work to create the appropriate helpers. Being specific to the API under consideration, such helpers can present an optimal interface. > >> * Whenever a callout to C accepts a pointer argument: a >> bytevector argument is rejected. Is this not a useless >> complication? No, it is sensible type checking: bytevector is not pointer. >> >> 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 =E2=80=98pointer=E2=80=99 type is useful, because it=E2=80=99s = 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? This implicit conversion must be avoided. Instead, how about supporting supporting SRFI-4 types (s16vector, etc.) or typed arrays in the FFI. This would only cover some use cases, where the caller controls the memory and the foreign argument is a /typed/ pointer. This much could be implemented without seriously complicating the FFI. For =E2=80=9Cvoid *=E2=80=9D it is still required to explicitly pass a poin= ter object, though it is not difficult to create helpers appropriate to the /particular/ interface. For callee allocated or deallocated memory it is still required to interface using pointer objects. SRFI-4 has the advantage that slots are always stored contiguously in memory. Typed array slots can be stored non-contiguously, and any such array would have to be rejected as =E2=80=9Carray-contents=E2=80=9D do= es. Regards