From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: ffi docs Date: Fri, 16 Apr 2010 10:43:28 +0200 Message-ID: <87aat3hjnz.fsf@gnu.org> References: <87ljco1gyc.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1271407563 23949 80.91.229.12 (16 Apr 2010 08:46:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Apr 2010 08:46:03 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Apr 16 10:46:01 2010 connect(): No such file or directory Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O2hBY-0007Wc-0K for guile-devel@m.gmane.org; Fri, 16 Apr 2010 10:46:01 +0200 Original-Received: from localhost ([127.0.0.1]:37750 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2hBW-0005Jp-6R for guile-devel@m.gmane.org; Fri, 16 Apr 2010 04:45:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O2h9v-0004OJ-2A for guile-devel@gnu.org; Fri, 16 Apr 2010 04:44:19 -0400 Original-Received: from [140.186.70.92] (port=36862 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2h9c-0006Vn-Ug for guile-devel@gnu.org; Fri, 16 Apr 2010 04:44:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O2h9K-0008U0-2R for guile-devel@gnu.org; Fri, 16 Apr 2010 04:43:58 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:40184) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2h9J-0008TR-Nx for guile-devel@gnu.org; Fri, 16 Apr 2010 04:43:42 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O2h9G-0006S6-DG for guile-devel@gnu.org; Fri, 16 Apr 2010 10:43:38 +0200 Original-Received: from acces.bordeaux.inria.fr ([193.50.110.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Apr 2010 10:43:38 +0200 Original-Received: from ludo by acces.bordeaux.inria.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Apr 2010 10:43:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ connect(): No such file or directory Original-Lines: 115 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: acces.bordeaux.inria.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 27 Germinal an 218 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:xlytkfWbI5Nq037Kk4v4eBp21gk= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10231 Archived-At: Hi Neil, A few answers/comments and I’ll leave the rest to Andy. ;-) Neil Jerram writes: > Andy Wingo writes: >> -- Scheme Procedure: dynamic-link [library] >> -- C Function: scm_dynamic_link (library) > > Code below implies that library can be omitted, and that this - > i.e. '(dynamic-link)' - means to return an object representing libguile > itself. Should that be mentioned in the following doc? This is actually documented: >> When LIBRARY is omitted, a "global symbol handle" is returned. >> This handle provides access to the symbols available to the >> program at run-time, including those exported by the program >> itself and the shared libraries already loaded. [...] >> A compiled module should have a specially named "module init >> function". Guile knows about this special name and will call that >> function automatically after having linked in the shared library. For >> our example, we replace `init_math_bessel' with the following code in >> `bessel.c': >> >> void >> init_math_bessel (void *unused) >> { >> scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper); >> scm_c_export ("j0", NULL); >> } >> >> void >> scm_init_math_bessel_module () >> { >> scm_c_define_module ("math bessel", init_math_bessel, NULL); >> } >> >> The general pattern for the name of a module init function is: >> `scm_init_', followed by the name of the module where the individual >> hierarchical components are concatenated with underscores, followed by >> `_module'. > > Is this still correct? The bit that says “Guile knows about this special name” has been incorrect since 1.8 AFAIK, because the name of the init function has to be explicitly given to ‘load-extension’. So this part can be removed. The bit about the “general pattern for the name” is correct, but it should probably made clear that it’s just a convention. >> So when accessing a C value through a Scheme pointer, we must give >> the type of the pointed-to value explicitly, as a parameter to any >> Scheme procedure that accesses the value. > > This confused me at first. I think I understand the point now, but > > - isn't it actually much more to do with the ELF binary format, rather > than with C? If libguile could read and parse C, it would be able to > infer the type of any variable that the Scheme layer might request. > The problem is precisely that what we are linking with is *not* C > anymore... It's just untyped pointers. C itself is very weakly typed: about anything can be cast to anything else. > - I think "give the type ... as a parameter to any Scheme procedure that > accesses the value" is misleading, because we don't do that! Rather, > we construct a box that includes both the pointer and the type, and > then pass the box around. Agreed. [...] >> As an example, `(dynamic-pointer "foo" void bar-lib)' links in the >> FOO symbol in the BAR-LIB library as a pointer to `void': a `void*'. >> >> Void pointers may be accessed as bytevectors. >> >> -- Scheme Procedure: foreign->bytevector foreign [uvec_type [offset >> [len]]] >> -- C Function: scm_foreign_to_bytevector foreign uvec_type offset len >> Return a bytevector aliasing the memory pointed to by FOREIGN. >> >> FOREIGN must be a void pointer, a foreign whose type is VOID. By >> default, the resulting bytevector will alias all of the memory >> pointed to by FOREIGN, from beginning to end, treated as a `vu8' >> array. > > It feels like we're missing a unification trick here. What do you mean? > Thought #1: if we have, e.g., an int8 pointer ip, why not just use > (foreign-ref ip n) to interpret the pointer as pointing to an array, and > get its nth element? > > Thought #2: but if we do that we'll be duplicating the bytevector API. > So instead, shouldn't the fundamental operation be (foreign->bytevector > NAME TYPE LIBRARY [LEN]), and get/set then done using the bytevector > API? What would be LIBRARY here? FWIW I’m fine with this procedure. Thanks, Ludo’.