From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Fri, 13 Feb 2015 09:38:40 -0800 Message-ID: <54DE36A0.7080705@dancol.org> References: <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]> <8361b54upa.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LBUIhVL4BH52pxfwAVCMQHNfJxtALnOOS" X-Trace: ger.gmane.org 1423849137 13679 80.91.229.3 (13 Feb 2015 17:38:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2015 17:38:57 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 13 18:38:56 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 1YMKCc-0001Xy-8K for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 18:38:54 +0100 Original-Received: from localhost ([::1]:56902 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMKCb-0007Vy-KP for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 12:38:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMKCX-0007V3-57 for emacs-devel@gnu.org; Fri, 13 Feb 2015 12:38:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMKCV-0004wR-US for emacs-devel@gnu.org; Fri, 13 Feb 2015 12:38:49 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:50016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMKCV-0004wD-IF; Fri, 13 Feb 2015 12:38:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=5X52a0WCzyhD0M58oXeeLhT+Vb8m+BpZ/p1XhdAOn0U=; b=k2HrKGFE/0ezFnYFSpa8BWt+gGxC6z3lHJ/8qg4V+QFlcTQ1N8JRvje7QK5/yaNYcLGIYeFj0uonYs8s/8kj6P13HExpdB/eFtYIZWMH7ffw1sUm5aIwcj6LNcamx/BFraIisyBWZlBU4sNq63ucEgS2F+7Vh96dKYrbyZE4mDtrIC2EWtP1KIDIMQxJs51UjXhpG53f27zQ0NFn9cOzrBL46h/zXTzp0V+aPKx/RR/uVTj5+7FB3ORv6D2+x7k4bPNWpWdmn8gu2d7YH5m139ancO2I0nR+0aTqK1JbsSdOsiT7Dk1bL8elvfYbHkjOSLQklhLa8KOMBrGB4NYuuw==; Original-Received: from [2620:10d:c083:1004:7211:24ff:fe8c:b06d] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YMKCU-0004uh-Co; Fri, 13 Feb 2015 09:38:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: <8361b54upa.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:183015 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LBUIhVL4BH52pxfwAVCMQHNfJxtALnOOS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/13/2015 08:55 AM, Eli Zaretskii wrote: >> 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. >=20 > So is mine. I guess our experiences differ. >=20 >> w32-win.el isn't that bad, especially for a module that loads quite a >> few different image libraries. >=20 > 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. >=20 >> Besides: using modules tightly coupled to the Emacs core doesn't >> actually help. Instead of elisp coupled to one module's stable ABI, yo= u >> 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 woul= d >> say, now you have two problems. >=20 > 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. Well, at least the proposed module design should allow the creation of a CFFI interface _on top_ of it --- a bit like how we can use Java's JNI to implement JNA. By the way: Java does it the proposed Emacs way (via JNI), and the CLR does it the way I propose (via P/Invoke). In my experience, P/Invoke-using modules have been far less painful to use and maintain than JNI-using ones. Speaking of JNI: if you insist on tightly coupling modules to the Emacs core, it's better to use a versioned system like JNI than to just dynamically export symbols from the Emacs core. This way, module A can request interface version 1 and module B can request interface version 2, and as long as a particular Emacs supports both interfaces 1 and 2, you can load both modules into the same Emacs without trouble and without rebuilding anything. > It makes little sense to me to turn the table and make module > compatibility something that core developers need to take care of. With the proposed design, core developers have to take pains to make Emacs itself export a stable ABI. With a CFFI-style interface, Emacs doesn't have to maintain a stable ABI at all. To me, that sounds like making life for core developers easier. >>> 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 bridgin= g >> 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 librar= y >> used the same libc, you'd lose. >=20 > 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. Woah. I had no idea that make supported loading dynamic objects. --LBUIhVL4BH52pxfwAVCMQHNfJxtALnOOS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJU3jagAAoJEN4WImmbpWBlWU0P/0JujP+/9X+KtNQ6iEyKiic2 ChUEQIqK+1A68GjT8n3wo62KEMdnXjtzE5ojA6ttxA0jKekZjxHohRk3lNZfnY9L kiQ3Qy0+PlFwS5JrH+1s2SOSqr1ANXpCca54NgY73M6aU7v3VXVeQEMaGuLYewrm 3AjDlRwDSABw4y3qm4Ns9nVLVpBziRt2a3VAltrLlcNMHNbUW+0EBgIGp0M29hw2 qvj7T65LAxqDCAIBlFkix8htwzBgyPJnGkL0Eu/yH2Iq7QpUcpXhdrsEeLfh+fDe /ccmMwVJAKAUpHxnxuD7BsvVqgzr+YfY+mpUsu/Fdyx0GDgcn5RVXJ+9oRCIv8BX HoAWkDNxMxHCsyZjMe5q8+2Knw3RKybNx+Kn7NQMVEP+4+0yN13CeXX9hEISi9x5 OliKF9t8ar0x3OoD4XflSZbXGGRhnRxTAg/fePQkClQpNh2u5P/0nUb/GLQ9v0ZK p2Y0KyCP/Vb9d14eXvPV0DLZqwAIDjpR/1w842SOQ4kEgCxMCbiePhtwUkRJ9S53 bvDhHTAU3Q5M0qER4p916Sddegh/R2pC9KibHlm9jVTn2MS3S4EXPHRu/H5w1fFF BSyPyBJpl86Dk5TIT0zSciAULGfmfVuN1Nh5aP6IlJHGYx+/nFWC0CXgUsz0K1IA pdCR3wxUE0gdcBSjYDYW =r3lr -----END PGP SIGNATURE----- --LBUIhVL4BH52pxfwAVCMQHNfJxtALnOOS--