From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Fri, 13 Feb 2015 18:55:45 +0200 Message-ID: <8361b54upa.fsf@gnu.org> References: <85k31coixa.fsf@stephe-leake.org> <85oapy5kt6.fsf@stephe-leake.org> <83y4oiiw81.fsf@gnu.org> <838ugdf251.fsf@gnu.org> <54D80098.3020209@cs.ucla.edu> <54D85304.1030600@cs.ucla.edu> <54D9AC29.2020603@cs.ucla.edu> <54DA8539.1020905@cs.ucla.edu> <87zj8ktq8f.fsf@lifelogs.com> <54DD6413.1000403@cs.ucla.edu> <83wq3m436s.fsf@gnu.org> <54DDEB4D.5040300@dancol> <83egpt4zz6.fsf@gnu.org> <54DE12E9.504@[87.69.4.28]> <83a90h4xr8.fsf@gnu.org> <54DE1F14.9010807@dancol.org> <838ug14wti.fsf@gnu.org> <54D@[87.69.4.28]> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423847363 15042 80.91.229.3 (13 Feb 2015 17:09:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2015 17:09:23 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 13 18:09:16 2015 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 1YMJjv-0007pS-KS for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 18:09:15 +0100 Original-Received: from localhost ([::1]:56589 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMJjv-0007DN-14 for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 12:09:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMJX3-0005Vs-UJ for emacs-devel@gnu.org; Fri, 13 Feb 2015 11:55:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMJX0-000439-9K for emacs-devel@gnu.org; Fri, 13 Feb 2015 11:55:57 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:59571) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMJWz-00042o-Hz for emacs-devel@gnu.org; Fri, 13 Feb 2015 11:55:54 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NJP00500YP4JO00@mtaout27.012.net.il> for emacs-devel@gnu.org; Fri, 13 Feb 2015 18:49:59 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJP00OTQYRBIA50@mtaout27.012.net.il>; Fri, 13 Feb 2015 18:49:59 +0200 (IST) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. In-reply-to: <54DE2439.5080809@dancol.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:183014 Archived-At: > Date: Fri, 13 Feb 2015 08:20:09 -0800 > From: Daniel Colascione > CC: eggert@cs.ucla.edu, emacs-devel@gnu.org > > > Sorry, I don't share your optimism about the stability of their ABI. > > My optimism is rooted in reality. So is mine. I guess our experiences differ. > w32-win.el isn't that bad, especially for a module that loads quite a > few different image libraries. It's not bad when you get it ready. But the effort it took to find out which versions changed ABI, to design the way of testing that, and to have all the #ifdef's in Emacs core to support all of those versions, and continue maintaining that as new versions arrive, is anything but trivial, take it from someone who did most of that. > Besides: using modules tightly coupled to the Emacs core doesn't > actually help. Instead of elisp coupled to one module's stable ABI, you > have a piece of native code tightly coupled not only to that module's > stable ABI, but _also_ to the volatile Emacs internal ABI. As jwz would > say, now you have two problems. No, we have only one problem: design and implement a minimal set of APIs necessary for modules to work, and keep it minimal. All the rest is the problem of module developers. It makes little sense to me to turn the table and make module compatibility something that core developers need to take care of. > > And we didn't yet start talking about problems with passing FILE > > pointers and malloc'ed buffers between Emacs and the modules. > > You have that problem anyway: a tightly-bound Emacs module for bridging > the Emacs core and some third-party library would have to link against > _some_ libc, and unless both the Emacs core and the third-party library > used the same libc, you'd lose. A well-designed set of APIs between Emacs and modules will avoid this and other similar problems. This has already been done at least twice, in 2 different ways: in Make and in Gawk. I see no reason why Emacs couldn't do something similar to one of those methods. > A better idea is not to pass C runtime objects between dynamically > loaded components. Exactly. But this requires the set of APIs I'm talking about to support this without making non-trivial modules impossible.