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 20:13:42 -0700 Message-ID: <5625B166.3080104@dancol.org> References: <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> <56259FDD.8040401@dancol.org> <87zizeme8k.fsf@tromey.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wVi8JrR8OrMfUD8RJ5SkTBNK1RfBJJTis" X-Trace: ger.gmane.org 1445310844 17196 80.91.229.3 (20 Oct 2015 03:14:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Oct 2015 03:14:04 +0000 (UTC) Cc: =?UTF-8?Q?Aur=c3=a9lien_Aptel?= , Philipp Stephani , Stephen Leake , Eli Zaretskii , Emacs development discussions To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 20 05:14:02 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 1ZoNNB-0005dR-45 for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2015 05:14:01 +0200 Original-Received: from localhost ([::1]:43322 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoNNA-0006q7-Fh for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 23:14:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoNN5-0006pb-J5 for emacs-devel@gnu.org; Mon, 19 Oct 2015 23:13:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoNN4-0007xp-JE for emacs-devel@gnu.org; Mon, 19 Oct 2015 23:13:55 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:34903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoNN4-0007xl-6w; Mon, 19 Oct 2015 23:13:54 -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=/Tj55uFCLFiYOiFG6MOYLuTRLc9/T8P/p5/YNvHKQzs=; b=EyLUpQTp7YosJLfk2EkvEmDVkA9xFYAZ0nxoY3KKRfBHnNx6pj3Jo0DYC03BueLXdIsDkcnxaYPHj2E8XlNVtChNjT169juQ3XcOrgCIRrtdVQJrOvY6OSNpb+VlNXlOHlxkLIAIdTC7MXR9VWwil+k4jESYGQav9qS7+Prv6fM/Mnz6cZRYzdPUsrf0OToRWeVyw2WXuqtQzbkm7ciLJ7zBe1xqAkYvkVqlHWiTKSLRkvIUoqthjpVRrn7mdJ8fRpmK/cw5drViicLqRESEsSvGBSWmBLjUuv1F5lriQEdAMNtTMk3IIpZ1vyDM6GclrXEAK5lnAK4ApgtJ20Ww3Q==; 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 1ZoNN1-0006qQ-Ch; Mon, 19 Oct 2015 20:13:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <87zizeme8k.fsf@tromey.com> 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:192145 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wVi8JrR8OrMfUD8RJ5SkTBNK1RfBJJTis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/19/2015 08:05 PM, Tom Tromey wrote: > Daniel> Yes, we do. I'd prefer eq, since the definition will never chan= ge, and > Daniel> having a nice convenient way to access eq is useful in more sit= uations > Daniel> than a specialized test for eq nil. >=20 > Both are useful and it is cheap to provide a method, so why not have > both eq and nilp? I have no objection to including both. > Daniel> Maybe we should actually get rid of get_environment and rely en= tirely on > Daniel> passed-in environment objects. It simplifies the API and avoids= > Daniel> definitional problems. >=20 > Yeah, I brought this up earlier and I still don't understand the reason= > for the runtime/environment split. A runtime describes Emacs as a whole. It lives forever and has no thread affinity. An environment represents a specific stack activation of an Emacs module function. It has thread affinity. Because environments have thread affinity, we can very cheaply store local references, error context, and whatever else we want in them. We could probably get away with only defining environments, but then we'd have no way to allow routines to call Emacs routines at any time. (Useful future runtime routines might be "attach this thread to the Lisp engine", "send QUIT to the main thread", "abort spectacularly", "get Emacs version", and so on.) >>> 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? >=20 > Daniel> free_global_ref, like all resource-releasing functions, should = be > Daniel> infallible. For other functions, asking users to check the erro= r state > Daniel> after a call is fine, although we should also return reasonable= dummy > Daniel> values (0 and NaN, probably) as well in case they don't. >=20 > It might be handy if there was a special emacs_value meaning that an > error occurred. We have a perfectly good sentinel: NULL. NULL will never be a valid local or global reference, so it's safe to use it to indicate that something went wrong. --wVi8JrR8OrMfUD8RJ5SkTBNK1RfBJJTis 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 iQIcBAEBCAAGBQJWJbFmAAoJEN4WImmbpWBlxyYP/0bCMcdeKvpAsAN73T0HlAx9 AyY6qvn/Yj08acg8piVB03qNYZ0BBd522npOi+nOheVx0dqSydvy0Tr3+YQDnJYn bP5l8FW1czltbRRaErdk9KjadSeOKhwiYDDzl8uSzuUNZxGCoMpvPgRgmsJDEkMk Xaf4npig3HtWKaP2ltp4PnH0/W55NWM3Uc7EQeDQEKMoa7xEakVr3zLuqM6TaiKQ d7jbpXujDa71c9RR5GhvGnnvu604hivG4dBx05Ley836JLfLELLpWGwk7VeCsEtI Aw9mwmRC4vCcXqZaHPKM6c7KES12kIKRXyvq+laKSH9SbZaZ8Yf9XYZ8pkH1Yv44 stj5IIqtn8dT0xxqLaOvatJlmkg9lXOrduEWZO8aBKbuiqRKzdzLxyJReghEJqEZ Ezr0BOZm54bIBph0rejFxFUoOpD37XvyhgiKULgBj0LI82HpMaG3IbK9bixj0GYD F24S+CV4jyPGjI0sX2MkFZ1/8NFCWZrXKpHO8JXsPKtQhRiNuej2nbbaBCtM7+SE lol+flf5ybE0wJ1S3WQcfezFDf7gJXQ9Lx//8/D/koie3sZnjxfR3sjz0xSB4cMT c4J6UaDK03n7LZnqMbRUlNJaqCH7XaQGGIAKgqsLOb+TUmOAfMtGq540ihCIpAEg Yq7jdSjEJuygUxPK7cNk =l4/X -----END PGP SIGNATURE----- --wVi8JrR8OrMfUD8RJ5SkTBNK1RfBJJTis--