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 07:06:17 -0800 Message-ID: <54DE12E9.5040606@dancol.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0NGkRpPvc0BNQTue4xJkP9GsJl85RosHR" X-Trace: ger.gmane.org 1423840001 6443 80.91.229.3 (13 Feb 2015 15:06:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2015 15:06:41 +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 16:06:34 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 1YMHpC-00061W-3O for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 16:06:34 +0100 Original-Received: from localhost ([::1]:55881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMHpB-0003pM-C7 for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 10:06:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMHp6-0003ls-D1 for emacs-devel@gnu.org; Fri, 13 Feb 2015 10:06:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMHp3-0003hY-1W for emacs-devel@gnu.org; Fri, 13 Feb 2015 10:06:28 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:49266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMHp2-0003hP-NY; Fri, 13 Feb 2015 10:06:24 -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=LWpanXC5XDiJsHatHordYGkvM6QU1TScHKQBnXtB0XE=; b=PS4yKNDpsHFTYo30j9vnmb6ZCJAM5PP3ey7rmHpH/8Ywu3/nQ64z9jL5AL4IXDQzLWqfjNULtCi/uscjdRb9m5qWjk1Q/bGcLpJJB0dqnjGmBZkv/miqPIqjNBfcwYn3+XVB65tM4E27bXNUjBZWqEXREsW+wGzlgF5425mQrrsP6OHMrj2Bbp5m+WaLbphpQifrqsFdZ18HydcC22DVOuCntsLgyQTVH9NiKzcTyb17hXwpNEycRdd90VMUkVWDe6dynvM6YazV78VQxBJoDu9ThbCsiMIOe2US9Op+gghyy4GDUFCO3BQcIPjCCwvo4Bfa25upqf7FrmWmlLP2bg==; Original-Received: from c-73-221-38-18.hsd1.wa.comcast.net ([73.221.38.18] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YMHp2-00047q-5l; Fri, 13 Feb 2015 07:06:24 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: <83egpt4zz6.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:183008 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0NGkRpPvc0BNQTue4xJkP9GsJl85RosHR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/13/2015 07:01 AM, Eli Zaretskii wrote: >> Date: Fri, 13 Feb 2015 04:17:17 -0800 >> From: Daniel Colascione >> CC: emacs-devel@gnu.org >> >> That's why this whole module effort is misguided and dangerous. With a= >> CFFI-style approach to loading code dynamically, shared modules don't >> need to know anything about Emacs internal structure, so there are no >> ABI or source compatibility issues. >> >> I still think a CFFI port would be less work than trying to extract a >> stable Emacs internals API that modules can include. >=20 > I don't understand how CFFI would solve the problem, at least not all > of it. We'd still need to write code to allow modules create Lisp > objects, right? That code would still be Emacs version dependent, > right? What am I missing? In a CFFI world, modules don't know about lisp at all. Lisp code describes the signatures of functions in loaded modules and calls into the automatically generated wrapper functions. The called code has no idea it's being called from lisp. If native code needs to create an object, it creates it in the normal way and returns a pointer; lisp then manages that pointer as an opaque value, possibly supplying it to further calls to that module's functions. This way, instead of loaded modules needing to track Emacs' historically unstable internal data structures, elisp needs to track module ABIs, which _have_ historically been stable; elisp interfaces can also be updated without requiring users have a compiler. --0NGkRpPvc0BNQTue4xJkP9GsJl85RosHR 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 iQIcBAEBCAAGBQJU3hLqAAoJEN4WImmbpWBl54IP/jFSi3qSPagJT0J3qic3UilZ qMzOcFo4tEiimd/Lff17zarUpQuap8ii1apT9bU3PyIYnV7VdbPmLYIqy/eXmSyW zdKO4u5/fkntLdwWtDn14pr3Z3Zn4i4ggPL3qKEtDLzzlNHi/UARbExdNt+zsK6U bmztGogsbQy/oNvg6cRRjC0qpAxX6JZXuBda6IbIYI709EZL9giA3U4yJlyoK4Xm cUDObrdiBRzlvtknZwgLTyyzJykpZDWe7QmZgKlwol3fwa6oikMpO9PzsHtWS7dX TOsCMfBjMePooDqyHCM/gc/AcSjAS9Qv3QGTWBp/t0Zi+IK+2baqvXlu9tUXzlhf 6eGdEmNwr/MG0QcwlfW3Q9IP3+OJiIsyXiYqYFDdkwSHwyo2OaZd6E+/PT+QETyT YeRsvNVBKepefEsu3IvaSwSnedk71R/cfVGj82ba8I89e26JUn12AdXRA3AsHgse lOpjimtFUXU2V70xIxvKwJTL+CRX55jlQb+FniuOanuFVIlWO0EnmVkdfa/0aKeM zSpX32qyh14W7+13NMQBv51qlPgmYZSVLr45heGT8spsDVM+3W59bkqmwcNX1Sye ZVef1YeTGeLMSb2XcRL7scpT1VUC70nb/vBR3jTwhmWoJkPyuaRtTsk0FYLjM7r5 IvbqUPlqfiJXG6Oil01P =GUlw -----END PGP SIGNATURE----- --0NGkRpPvc0BNQTue4xJkP9GsJl85RosHR--