From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: FFI again Date: Sat, 05 Oct 2013 16:24:03 -0700 Message-ID: <52509F93.80304@dancol.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XicM2BoOf5De0Hli8kjlXWOnRbVss5LSI" X-Trace: ger.gmane.org 1381015536 854 80.91.229.3 (5 Oct 2013 23:25:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Oct 2013 23:25:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 06 01:25:40 2013 Return-path: Envelope-to: ged-emacs-devel@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 1VSbEA-0007DD-Ha for ged-emacs-devel@m.gmane.org; Sun, 06 Oct 2013 01:25:38 +0200 Original-Received: from localhost ([::1]:53307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSbE9-0001Jv-VJ for ged-emacs-devel@m.gmane.org; Sat, 05 Oct 2013 19:25:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSbDv-0001Iw-4E for emacs-devel@gnu.org; Sat, 05 Oct 2013 19:25:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VSbDm-0002cL-ND for emacs-devel@gnu.org; Sat, 05 Oct 2013 19:25:23 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:52466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSbDm-0002aE-GS for emacs-devel@gnu.org; Sat, 05 Oct 2013 19:25:14 -0400 Original-Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[192.168.1.52]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VSbDk-000484-RU; Sat, 05 Oct 2013 16:25:12 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: X-Enigmail-Version: 1.5.2 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163898 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XicM2BoOf5De0Hli8kjlXWOnRbVss5LSI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/5/13 9:11 AM, Stefan Monnier wrote: > As you may remember, I'd really like for Emacs to grow some kind of FFI= =2E > Last time we discussed it, I mostly remember the following points being= made: > - An FFI can be a lot of work, and the benefit is not as obvious as it = seems. > - Emacs-Guile would give us an FFI for free. > - The xwidget branch indirectly gives us some limited FFI. >=20 > The Emacs-Guile route seems promising, but I'm not sure I want to depen= d > on its schedule. The xwidget one seems a bit too limited for my taste.= > And I surely don't want to put a lot of work into it. >=20 > So I'd like an FFI, but one that's really cheap to design/implement. >=20 > The main purpose of an FFI, as far as I'm concerned, it to make it > possible for Emacs to use any .so library it feels, rather than only th= e > ones that it was compiled with. More specifically, so that ELPA > packages can use such .so libraries if they feel like. >=20 > I think a "cheapish" way to do that is to make it possible for an ELPA > package to come with a .c file that exports a "syms_of_module" function= > that can call things like defsubsr. >=20 > Installing such an ELPA package would require running a C compiler, > obviously (unless we also provide some pre-compiled versions for > particular target systems?). And we'd need to add some function that > can load the resulting compiled object (along with the .so libraries it= > depends on, since in many cases the whole purpose would be to call > functions in those .so libs). I really don't like this idea. You either force users to have the Emacs headers, Emacs import library, and a C compiler available to install a package or you provide pre-compiled binaries for popular platforms and create an ABI versioning nightmare. The routines declared in lisp.h do not form stable interface. Sure, you could require that libraries export a version number, then have Emacs refuse to load libraries compiled with the wrong ABI version, but then you have to ship many different pre-compiled binaries and take care to bump the ABI version when necessar= y. I'd definitely prefer something libffi-based and with a CFFI-like interfa= ce. --XicM2BoOf5De0Hli8kjlXWOnRbVss5LSI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) iQIcBAEBAgAGBQJSUJ+TAAoJEMAaIROpHW7IG30P/iI/tkvQRMMDN7mRC/hPbGcB pyK3J/Nz/h8X6Umu+0NaV/gf+r790Y059tjM4tr4U2Q3/ZT/2nUa2M/viKITQiJe NLW8xve8igWv1vmkh3LeH9ORxNbdpj4Dp352b2Fy/ZwhWa9r0Fm80+bFV0Ru8oLi RNGuyNW4OLac8QyTe08XNotks8p3QCwmNpESU0SGV/+b+bD1TWqCLkAU24WHyQMj tKIjbBq8nPav+FI5iMwUBpitGkCmJuCE3u49C6xXz3WT5kIVkEycZVnddJ2WjdyA T/ie0Ttr9plK2M1fXjAmQNVUFU0VXjPuWOuxSLXxGYCLAbKoXoYYu1IdL5i8x84p l8tISElBeG1/y+dfBk5L9CvM9LFYfXdCNSOUKhU54FLSk2tAhqxmJEJYLyVj8mtc Fzz9XDw/BbLNjyTue6Y+lKjd2/aHyN2rxq7qC4NXIIiL/vzxGlpLi1BhUNNsKcNv 8tGX4BdSoWfU/iNVBqicnM/k8BvdgYDescn4WvrTTMo6IOFaLf7m/s4XGFZmsgJQ 288c9sG5bAXsudXmxGyQAP7Z8UfMyUV2NN45fReDEyZ5KAfWTSNK4R7D3NJejxiK Z7UCkG+jxMDV1zdgIoizWhg+nfHJiQ6gYfiKAC+vDixXHH44bM1XazFi4S7E5o7i CfDTb9qqfEW1zafbbVaM =cJay -----END PGP SIGNATURE----- --XicM2BoOf5De0Hli8kjlXWOnRbVss5LSI--