From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: FFI again Date: Sat, 05 Oct 2013 12:11:26 -0400 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1380989503 7135 80.91.229.3 (5 Oct 2013 16:11:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Oct 2013 16:11:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 05 18:11:46 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 1VSUSH-0007Jy-Kb for ged-emacs-devel@m.gmane.org; Sat, 05 Oct 2013 18:11:45 +0200 Original-Received: from localhost ([::1]:52359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSUSH-0001zP-5e for ged-emacs-devel@m.gmane.org; Sat, 05 Oct 2013 12:11:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSUS7-0001yo-5t for emacs-devel@gnu.org; Sat, 05 Oct 2013 12:11:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VSURz-0001hm-I4 for emacs-devel@gnu.org; Sat, 05 Oct 2013 12:11:34 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:27080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSURz-0001hf-EH for emacs-devel@gnu.org; Sat, 05 Oct 2013 12:11:27 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIHABK/CFFMCoYf/2dsb2JhbABEtxERh2wXc4J7ciYYDQiIQKALoSKNGUiDKQOkeoFegxOBSg X-IPAS-Result: ArIHABK/CFFMCoYf/2dsb2JhbABEtxERh2wXc4J7ciYYDQiIQKALoSKNGUiDKQOkeoFegxOBSg X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="34826571" Original-Received: from 76-10-134-31.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([76.10.134.31]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 05 Oct 2013 12:07:55 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 5BC73AE21D; Sat, 5 Oct 2013 12:11:26 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:163879 Archived-At: As you may remember, I'd really like for Emacs to grow some kind of FFI. 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. The Emacs-Guile route seems promising, but I'm not sure I want to depend 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. So I'd like an FFI, but one that's really cheap to design/implement. 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 the ones that it was compiled with. More specifically, so that ELPA packages can use such .so libraries if they feel like. 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. 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). It's not ideal, but it should be reasonably cheap to implement, and would let people get access to pretty much any library they want. Stefan