From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: FFI again Date: Tue, 08 Oct 2013 11:22:20 +0900 Message-ID: <878uy4lcwz.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87iox9luwa.fsf@uwakimon.sk.tsukuba.ac.jp> <87hactlmx0.fsf@uwakimon.sk.tsukuba.ac.jp> <8261t83f0e.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1381198963 8089 80.91.229.3 (8 Oct 2013 02:22:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Oct 2013 02:22:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 08 04:22: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 1VTMwg-0006MX-Mk for ged-emacs-devel@m.gmane.org; Tue, 08 Oct 2013 04:22:46 +0200 Original-Received: from localhost ([::1]:34307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTMwg-0006uY-7d for ged-emacs-devel@m.gmane.org; Mon, 07 Oct 2013 22:22:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTMwX-0006td-Fi for emacs-devel@gnu.org; Mon, 07 Oct 2013 22:22:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTMwP-0005Bk-48 for emacs-devel@gnu.org; Mon, 07 Oct 2013 22:22:37 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:46757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTMwO-00059J-Iz for emacs-devel@gnu.org; Mon, 07 Oct 2013 22:22:29 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 421643FA0973; Tue, 8 Oct 2013 11:22:20 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3666B1A3B6D; Tue, 8 Oct 2013 11:22:20 +0900 (JST) In-Reply-To: <8261t83f0e.fsf@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 182d01410b8d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.223 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:163984 Archived-At: Andy Moreton writes: > On Mon 07 Oct 2013, Stefan Monnier wrote: > > > So what I propose is to use "runtime loading of DSO" as a poor man's FFI > > where the DSL of the FFI is C and where the compilation of this "DSL" is > > handled by a C compiler. > > > > The only technical difference between what I propose and typical "runtime > > loading of DSOs" is that the system also handles running the C compiler, > > so you can download the TedZ-OpenPGP package from ELPA and install it > > (provided you have a C compiler on your machine). > > This will work well enough for POSIX systems, And in XEmacs, it has worked well enough for a decade now. Windows, too. But very few users actually use it as far as I know, on either type of system. > but will fail miserably on Windows systems. Most Windows users do > not develpment tools installed, and would have a hard time to find > a C compiler producing binaries with the correct ABI, and the other > required build tools and dependencies. You don't need to worry about such users. The XEmacs runtime DLL loading system demonstrated optional static linking of the wrapper code, and load the external DLL as usual at program execution. The wrapper code does an Fprovide at Emacs initialization, so the feature code works as expected. The price is a somewhat fatter binary and perhaps loading an external library that would otherwise not take up any memory. No DDL wrapper, no problem for users. Even if the necessary "stuff" is available, such a DLL loading system really isn't very useful to ordinary users. Almost nobody except developers[1] who can save a lot of time by recompiling the module only and then reloading to test really benefit (having done 3 of these myself, I can say it *is* a nice feature), vs building the feature into the Emacs binary. If you're only occasionally going to rebuild modules with a C compiler, it's not so much of additional burden to rebuild Emacs as well. If the necessary stuff *isn't* available then you're dependent on somebody else to build an installer. Again, these days it may as well be all of Emacs as a single module (and quite likely the corresponding external DLL). That way the user doesn't even need to put the DLLs in the right place. Footnotes: [1] The others are those who just love BrightShinyThings.