From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: DSO-style FFI Date: Tue, 08 Oct 2013 14:43:39 -0600 Message-ID: <877gdnfq84.fsf@fleche.redhat.com> 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 X-Trace: ger.gmane.org 1381265035 6161 80.91.229.3 (8 Oct 2013 20:43:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Oct 2013 20:43:55 +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:43:58 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 1VTe8L-0000wO-3r for ged-emacs-devel@m.gmane.org; Tue, 08 Oct 2013 22:43:57 +0200 Original-Received: from localhost ([::1]:38871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTe8K-00073R-PM for ged-emacs-devel@m.gmane.org; Tue, 08 Oct 2013 16:43:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTe8B-0006z0-P9 for emacs-devel@gnu.org; Tue, 08 Oct 2013 16:43:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTe85-0003I3-M7 for emacs-devel@gnu.org; Tue, 08 Oct 2013 16:43:47 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:33665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTe85-0003Hn-DY for emacs-devel@gnu.org; Tue, 08 Oct 2013 16:43:41 -0400 Original-Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r98Khe0j009874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Oct 2013 16:43:40 -0400 Original-Received: from barimba (ovpn-113-128.phx2.redhat.com [10.3.113.128]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r98Khd8r010972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Oct 2013 16:43:40 -0400 X-Attribution: Tom In-Reply-To: <87wqlnv9bn.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Tue, 08 Oct 2013 15:42:04 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 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:164023 Archived-At: Ted> Would any kind of FFI help with data formats? I don't think so, right? Sure. Basically you would need to expose "native" structures (and pointers and whatnot) to elisp, so that elisp can manipulate their fields in various ways. This is pretty easy to do; libffi doesn't provide code for this specifically, but you can reuse the type descriptor stuff. Ted> The foreign function has to take Emacs Lisp_Objects (maybe just strings Ted> and numbers) and package its return data in a Lisp_Object. So how do we Ted> handle that glue with libffi or anything else without promising some Ted> minimal internal Emacs ABI? The idea is to have the FFI code be part of Emacs. So when Emacs changes, it does too. What doesn't change is the API presented to elisp. This is how FFI works in other languages -- Common Lisp, Python, probably Guile (I didn't check), Java (it's part of reflection there), etc. Ted> I don't know much about libltdl but it seems fairly simple, except for Ted> the requirement to name all exported symbols _modulename_LTX_* which is Ted> a bit annoying. I think that's only for preloaded modules. Most people don't use this feature. Tom