From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Davis Herring Newsgroups: gmane.emacs.devel Subject: Re: DSO-style FFI Date: Tue, 08 Oct 2013 14:47:17 -0600 Organization: XCP-1 Message-ID: <52546F55.1020707@lanl.gov> References: <877gdqrc9u.fsf@flea.lifelogs.com> <87mwmmp05f.fsf@flea.lifelogs.com> <87fvsdpato.fsf@flea.lifelogs.com> <8738oc20xk.fsf@flea.lifelogs.com> <87d2ngzlyl.fsf_-_@flea.lifelogs.com> <87siwcxda7.fsf@flea.lifelogs.com> <87zjqjfz36.fsf@fleche.redhat.com> <87wqlnv9bn.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1381265258 8768 80.91.229.3 (8 Oct 2013 20:47:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Oct 2013 20:47:38 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 08 22:47:41 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 1VTeBv-00030D-Ek for ged-emacs-devel@m.gmane.org; Tue, 08 Oct 2013 22:47:39 +0200 Original-Received: from localhost ([::1]:38879 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTeBu-0000z2-UC for ged-emacs-devel@m.gmane.org; Tue, 08 Oct 2013 16:47:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTeBk-0000v4-6l for emacs-devel@gnu.org; Tue, 08 Oct 2013 16:47:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTeBc-0004l5-4a for emacs-devel@gnu.org; Tue, 08 Oct 2013 16:47:28 -0400 Original-Received: from proofpoint5.lanl.gov ([204.121.3.53]:53351) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTeBb-0004ky-T8 for emacs-devel@gnu.org; Tue, 08 Oct 2013 16:47:20 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate5.lanl.gov (8.14.5/8.14.5) with ESMTP id r98KlIUF008617 for ; Tue, 8 Oct 2013 14:47:18 -0600 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id 44B7F276258 for ; Tue, 8 Oct 2013 14:47:18 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Original-Received: from [128.165.123.183] (xray-r06.lanl.gov [128.165.123.183]) by mailrelay1.lanl.gov (Postfix) with ESMTP id 1DFE2276263 for ; Tue, 8 Oct 2013 14:47:18 -0600 (MDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110717 Lanikai/3.1.11 In-Reply-To: <87wqlnv9bn.fsf@flea.lifelogs.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-08_08:2013-10-08, 2013-10-08, 1970-01-01 signatures=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 204.121.3.53 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:164024 Archived-At: > Tom> This approach seems very weird to me. > Tom> I don't understand why it is preferable to a libffi-based FFI. > Tom> The main difficulty I see is that now you're either promising an > Tom> internal Emacs ABI -- hard to do -- or you're requiring recompilations > Tom> whenever Emacs changes -- hard on users. > > Would any kind of FFI help with data formats? I don't think so, right? > The foreign function has to take Emacs Lisp_Objects (maybe just strings > and numbers) and package its return data in a Lisp_Object. So how do we > handle that glue with libffi or anything else without promising some > minimal internal Emacs ABI? An interface like ctypes from Python would not involve Lisp_Objects on the other side, but would rather provide a means for a Lisp program to specify a mapping from its objects (Lisp_Objects, of course) to the C datatypes appropriate to the interface. Simple things like "expose my string as a writable char*" and "copy my integer into an int passed by value" would suffice for many clients (or many target libraries, which is much the same thing). libffi helps to formulate the actual calls (with all their platform/ABI-dependent nonsense) based on such abstract descriptions. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.