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:44:47 -0800 Message-ID: <54DE380F.3020508@dancol.org> References: <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> <54DE2F87.8040704@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QpxkefekXa8q29xNOF2XIXLQUB5LIpV7V" X-Trace: ger.gmane.org 1423849509 20289 80.91.229.3 (13 Feb 2015 17:45:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2015 17:45:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 13 18:45:07 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 1YMKIb-0005Pj-4M for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 18:45:05 +0100 Original-Received: from localhost ([::1]:56925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMKIa-0002Yd-Eu for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 12:45:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMKIX-0002Xt-JE for emacs-devel@gnu.org; Fri, 13 Feb 2015 12:45:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMKIW-0007Bu-Ln for emacs-devel@gnu.org; Fri, 13 Feb 2015 12:45:01 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:50020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMKIW-0007AC-Bs; Fri, 13 Feb 2015 12:45:00 -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=Kfnomt0/2TtzB+m+EEcEyMT3vXlwW+BJlgTFu3/19qw=; b=LdUF4B+JOq0jnT7Ss6c7yCl8qgJc+J/WvZuYsrw4DkjbTcBbJQsosfba6SOKptWK89B99c/FMn+P9q1gSInW+MwcKKs2fQ7aT6Cb6JHxU6CLnzmAieu7+ecQLtPdgmygqtITA99j6N0DRonTXLpVzyG6Wwo+I69rca5UsRDKCNZQkY0tkeTzZXHM4UshgPKQY3gPWsPiyHw9bKsf/EsIIzvpqZuAEy68eJLXYqIks/jjjIIOgzVIe4tbE12jhGe1tv6Ij799F1xfRt3MwogBXTMvstZYClqC6g45CPp2Jcy4yRhwTVQs7+ILT4zOEy5TKexxYbxDFJVktZkEXo94YQ==; 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 1YMKIP-0004wZ-MJ; Fri, 13 Feb 2015 09:44:53 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: <54DE2F87.8040704@cs.ucla.edu> 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:183016 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QpxkefekXa8q29xNOF2XIXLQUB5LIpV7V Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/13/2015 09:08 AM, Paul Eggert wrote: > Eli Zaretskii wrote: >> 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. >=20 > Sure, but the cffi/libffi approach has seen a lot more uptake than that= : > GCC, CPython, OpenJDK, PLT Scheme, etc., etc. It's quite a well-trodde= n > path. >=20 >> we have only one problem: design and implement a minimal set of >> APIs necessary for modules to work, and keep it minimal. >=20 > cffi/libffi provides a good framework for that, no? Why reinvent the > wheel? Because that's what we'd need to do, when designing this new > emacs.h file. I was imagining emacs.h looking a lot like jni.h: modules would export some kind of emacs_init symbol that the Emacs core would call --- say, something like this: struct emacs_runtime { /* Return NULL on failure */ struct emacs_interface* (*init)( int interface_version, const char* my_license); }; struct emacs_interface_1 { /* Err, something like this */ struct emacs_value* (*defun)(const char* name, int nargs); struct emacs_value* (*funcall)(struct emacs_value* func, ...); }; /* Exported by loadable modules and called on load. Return 0 on success or -1 on error. */ extern int emacs_init(struct emacs_runtime*); This way, Emacs itself doesn't need to export any symbols and it can support multiple interface versions sanely. I'd still prefer a CFFI-style interface though. --QpxkefekXa8q29xNOF2XIXLQUB5LIpV7V 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 iQIcBAEBCAAGBQJU3jgPAAoJEN4WImmbpWBlqV0QAJsFoSbVZJrfr6vGNDOEB0qD L56yCtIh2PrXhQ0Z5YBy/iRbZOer25O3jjA1AdQefryTL/EdimfyGpPH/yTZ87we 5oekw30JhBukj5Yz5W+Vl04pXH+yPuo+NWqGxi4b+XwHsoajHn8cwx1LEE5xfCWw C4Pxm/u2gNyEdWd84qwAWP1rrL6DEBaBGVEHR3C4E66RPY6Yp/DcBetUubW8fwOk sgBYL1kh5gRocTq1zSrCg8MBvkhd71mkM/oyT5holQ2mwFra/6seLFcKw3vhwa4E iPEZfBW4xdw9QklK8Nut32zrnBAEZbTkl7DohLuzfhdnC/zAY7ivJi/NoEIHQTBU hyTtGroM7CL8bPm32b8OHSxapuMMtpHndddUaZSJpLcR5wo1D1nGEZYGC/XqsFIh /7sYE3moUHmvt9SHd1bI/CKiEnVz7BO30A7R0LetUv1ene9YAWnQPtCbwSw0DdRq 43GAOOV+eNHlZOOtENp7K0n40gCRlhZngpJEklJ1OXVoaajduI9GRDX8WlUwR+KD ZK7CHjsIN/X/OivStPRG7jzHmSJt/murRoaIFo5Y2o+s3Nqo0wuEng8+5+Mc6uUk sh4M34T169gHKL/SQ0eY8+L+vLEy77dVd665XfgZ63Ee3k3cn0QRQWj9L3gLG/ft YhtG3O7NGpWh4F7RytG2 =XnUL -----END PGP SIGNATURE----- --QpxkefekXa8q29xNOF2XIXLQUB5LIpV7V--