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: Mon, 19 Oct 2015 18:58:53 -0700 Message-ID: <56259FDD.8040401@dancol.org> References: <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@87.69.4.28> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <5610ED13.1010406@dancol.org> <56117F37.9060808@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tlgpvSQEabNCLMihDhxDFSd28TcvVm6Pb" X-Trace: ger.gmane.org 1445306371 18934 80.91.229.3 (20 Oct 2015 01:59:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Oct 2015 01:59:31 +0000 (UTC) Cc: Eli Zaretskii , Stephen Leake , Emacs development discussions To: Philipp Stephani , =?UTF-8?Q?Aur=c3=a9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 20 03:59:29 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 1ZoMD1-00050t-RD for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2015 03:59:28 +0200 Original-Received: from localhost ([::1]:42963 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoMD1-0003fH-1u for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 21:59:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoMCp-0003eb-7G for emacs-devel@gnu.org; Mon, 19 Oct 2015 21:59:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoMCj-00046G-Lx for emacs-devel@gnu.org; Mon, 19 Oct 2015 21:59:15 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:34481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoMCj-0003zI-3R; Mon, 19 Oct 2015 21:59:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=6tJVUv61M2rYSxAEpN4r07mRJcGIDTyxoFjmWJB8jic=; b=C8eVEOwlOXA5do6F314ESojfsRCyJTlQdfLuMVe42/xiBSkjbhqtdKu5rcS7Gzg7J99SY/OemWYHCnpEc0bSbNUBjE8CHHHVVdJbpV3NuEB+f8V8SvPl1N/PqQbvoYay2p5XT8lTAyTuZgt8k0Ombjyq6p4Xm/1TWRjSApr3pUJgY+gqexw8/CGA27aR1QJ+8E9WiGHeEK/guKr4ZWf+nbvfDv/IkhkAzMnj7TVltlP/Ohh+FyXFIkRZv6zClKfXMPBbtdJ6IIQ9SQV/zqhMMXEBd6CVfl6Qy4j8JdsJyHjRsWnczqwcu2SztF8c7/3qQbLV4yQ1e22KvJV3If9btw==; Original-Received: from [2620:10d:c090:180::1:8cc3] (helo=[IPv6:2620:10d:c081:1101:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZoMCa-0006Ja-8k; Mon, 19 Oct 2015 18:59:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: 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:192142 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tlgpvSQEabNCLMihDhxDFSd28TcvVm6Pb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/19/2015 03:38 PM, Philipp Stephani wrote: > Philipp Stephani >= > schrieb am Fr., 16. Okt. 2015 um 01:15 Uhr: >=20 > I just realized that we need (at least) one more public environment= > function, either "null" or "eq". Otherwise conditions cannot be > written in module code. > I'd vote for bool is_not_null, it seems to be the most basic one, > and doesn't invert the condition. Yes, we do. I'd prefer eq, since the definition will never change, and having a nice convenient way to access eq is useful in more situations than a specialized test for eq nil. > There are still a few open questions: >=20 > 1. How to represent throw/catch. Currently it's not possible to throw= > from modules, but that should change because otherwise modules can'= t > be transparent. For example, the following couldn't work: >=20 > emacs_value top_level =3D env->intern(env, "top-level"); > if (!top_level) return NULL; > return env->funcall(env, top_level, 0, NULL); >=20 > because `top-level' uses `throw'. > There are several ways to represent `throw'. My suggestion would > still be to use an enum instead of the bool value for get_error and= > check_error. Otherwise the fact that a `throw' has happened has to > be encoded somehow in the error symbol, which to me seems rather > hackish and not future-proof. (What happens if Emacs would ever > allow to signal a list?) An enum to indicate the current thread's non-local error propagation state is probably fine. > 2. Whether type_of should return an enum or a symbol. I'd vote for the= > symbol, as in Daniel's original design. A symbol means that we can define as many types as we want. > 3. Can runtime->get_environment ever fail? Maybe we should actually get rid of get_environment and rely entirely on passed-in environment objects. It simplifies the API and avoids definitional problems. > 4. Some of the function (free_global_ref, the int/float extractors) > don't return emacs_value and have no clear way to signal an error. > For these function the caller always has to use > check_error/get_error. Is that good enough? free_global_ref, like all resource-releasing functions, should be infallible. For other functions, asking users to check the error state after a call is fine, although we should also return reasonable dummy values (0 and NaN, probably) as well in case they don't. --tlgpvSQEabNCLMihDhxDFSd28TcvVm6Pb 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 iQIcBAEBCAAGBQJWJZ/dAAoJEN4WImmbpWBls4cP/jOApvscKxTfS8F8HANCXLzD XcRz8SCuSVvDyy+qM9qgCKoNRQog9ZyNRDyAz4Cawkh+PvqrepQFjStBQvrKvKOn JwaDe91499EQ1B30XLwvL6kxLeyGit63hA0o3Mkw+lEfElx9OczbszFdqq1Ir1Ck 91dCNAgY4vxpodG//UsdJTPtyjIZVj7XSaBQK+9YqnQGW4gOKOFmIgdmXZpBOONw /5ClM3YpNml5bFd/ZYIwkr3tfxG1HpQB6WvPV/NtK4ABiDV7oVMtbxfOB1qM9BYv Ks8crppTYMg/w9iAHAvN8fDJ48TbLzDDEiYgU8PyklJjilohChqG16quDAbt+eBE i5St6ZkAG0/4iXwRiCHSWGQb7htmJKLtuTlhX25wuwMd7sXQoaT2qC1db8g5IRWN CosJu2f3TGXcZJyf24Yo7ekbAFqRte0rXFJg+koFYm63YYavJokp5v/YhG3J7Ch4 jUZeohVHuL8BVDv13fmkGoPC1mb3/6Q2CR855CXHxwsFnn932fvwq9vQKwmi5Jek KPc/hp3N8KnfmZTwEzzfP/ry4rAFZebTFUcYDzPCQvPLwjiNf4qBwITTaZ9bQL8E 3SwF7frg/5IYDPjUXUBzM32BoERD35+QvykjgfF78su0HEKMI4+b0Rkp4Ny5bc23 WTdoiNLhmydDbN5/paWg =KQT0 -----END PGP SIGNATURE----- --tlgpvSQEabNCLMihDhxDFSd28TcvVm6Pb--