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: Passing C pointers through guile Date: Wed, 09 Jul 2008 21:35:14 +0200 Message-ID: <87zloqyhot.fsf@gnu.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1215632165 8315 80.91.229.12 (9 Jul 2008 19:36:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jul 2008 19:36:05 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jul 09 21:36:52 2008 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.50) id 1KGfSx-0001Eq-IE for guile-devel@m.gmane.org; Wed, 09 Jul 2008 21:36:39 +0200 Original-Received: from localhost ([127.0.0.1]:41169 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KGfS5-0008Md-7O for guile-devel@m.gmane.org; Wed, 09 Jul 2008 15:35:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KGfS1-0008MR-EF for guile-devel@gnu.org; Wed, 09 Jul 2008 15:35:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KGfRy-0008LQ-ML for guile-devel@gnu.org; Wed, 09 Jul 2008 15:35:39 -0400 Original-Received: from [199.232.76.173] (port=46986 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KGfRy-0008LE-1A for guile-devel@gnu.org; Wed, 09 Jul 2008 15:35:38 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:57040 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KGfRx-0005Xw-2A for guile-devel@gnu.org; Wed, 09 Jul 2008 15:35:37 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KGfRp-0006Jh-WC for guile-devel@gnu.org; Wed, 09 Jul 2008 19:35:30 +0000 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jul 2008 19:35:29 +0000 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jul 2008 19:35:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 53 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 22 Messidor an 216 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: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i686-pc-linux-gnu User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Cancel-Lock: sha1:udrGcYRiVG9fYvnGZ+ICbwpn/48= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:7359 Archived-At: Hi, "Kjetil S. Matheussen" writes: > I gave it a try. Unfortunately, I was completely unable to create > the configure file right now, so the patch is against 1.8.5 (sorry > if this creats trouble against git repository), and > it's also untested, since I couldn't build configure. You have to make sure you are on the `branch_release-1-8', and then "autoreconf -vfi" should suffice to produce everything. Autoconf 2.61, Automake 1.10 and Libtool 1.5.26 is all you need. > The only thing I'm not too sure about is whether > the new SCM_I_GSC_T_UINTPTR type in configure.in will actually be > optional or not. I just copied the checking code for the optional > SCM_I_GSC_T_UINT64 type though: I think this type shouldn't be optional, because there will always be a pointer-sized integer type (whereas there could be platform without 64-bit integers). >> That said, using a Scheme integer to represent a pointer wouldn't be >> efficient (pointers would likely translate to bignums). > > I think cleaner code would usually be more important in this case, > but at least there will be a choice. I'm not sure how much cleaner this is. Usually, you'll want disjoint Scheme types, which means you'll end up enclosing the pointer-as-bignum in a structure or SRFI-9 record or similar. This leads to even more overhead. Conversely, using an opaque field in a Guile struct has the same effect but with much less overhead. Another issue is that of memory management. When using pointers-as-bignums, all the GC will see is a collection of bignums, not knowing that these are actually pointers to C objects that should not be GC'd unless the integer is no longer used---as opposed to "no longer referenced"! This actually makes it mandatory to enclose the integer in a structure or similar, and then to have a guardian on that structure to allow the C object's destructor to be called when that structure is no longer referenced. (Note that it could be a valid approach in some compiler environments. It just doesn't fit well with Guile's design.) Anyway, it can't hurt to have the choice. :-) Thanks, Ludovic. PS: You'll have to assign copyright to the FSF so that your code can be integrated. We can discuss it off-line if you want.