From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:43033) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iywBX-0003Xl-Nr for guix-patches@gnu.org; Tue, 04 Feb 2020 06:16:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iywBW-00059n-Is for guix-patches@gnu.org; Tue, 04 Feb 2020 06:16:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:36698) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iywBW-00059j-Eu for guix-patches@gnu.org; Tue, 04 Feb 2020 06:16:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iywBW-0002CL-5h for guix-patches@gnu.org; Tue, 04 Feb 2020 06:16:02 -0500 Subject: [bug#39412] [PATCH 0/2] gnu: emacs-telega: Build with emacs-wide-int on 32-bit systems. Resent-Message-ID: Date: Tue, 4 Feb 2020 13:14:24 +0200 From: Efraim Flashner Message-ID: <20200204111424.GE19864@E5400> References: <20200204094351.18671-1-dnbarbato@posteo.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k3qmt+ucFURmlhDS" Content-Disposition: inline In-Reply-To: <20200204094351.18671-1-dnbarbato@posteo.de> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Diego Nicola Barbato Cc: 39412@debbugs.gnu.org --k3qmt+ucFURmlhDS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'll start by saying I'm not a user of emacs or of emacs-telega. On Tue, Feb 04, 2020 at 10:43:51AM +0100, Diego Nicola Barbato wrote: > Hi Guix, >=20 > Telega requires wide Emacs integers (62-bit), so it checks whether > `most-positive-fixnum' is equal to 2305843009213693951. Due to a > performance penalty [0] wide Emacs integers have to be explicitly > enabled on 32-bit architectures. Because of this `emacs-telega' > currently fails to build on armhf-linux and i686-linux. I assume it actually needs '--with-wide-ints' and that patching out the check wouldn't actually fix the problem. > The following two patches fix this by first adding a variant of > `emacs' with wide ints enabled and then using this `emacs-wide-int' > instead of `emacs' to build `emacs-telega' on 32-bit systems. >=20 > I am not completely happy with this solution, because wide ints are > not required to build Telega but to run it: A user installing > `emacs-telega' alongside "vanilla" `emacs' on a 32-bit machine will be > greeted with cryptic parse errors when trying to run Telega. Would it > be enough to mention that `emacs-telega' has to be installed alongside > `emacs-wide-int' on 32-bit systems in the description? I don't like this plan so much. It means relying on the users to read the description which is something I normally only do when I don't know what package I'm looking for. > I have chosen this approach over building the regular Emacs package > with the "--with-wide-ints" flag because I do not think the > performance penalty is justified. What do others think? 10-30% performance penalty across the board in emacs is pretty severe for one package. Otherwise that would've been my suggestion. > In the long run it should be possible to drop this workaround once > Emacs 27, which introduces bignums, is released. With those Telega > should work on 32-bit Emacs without wide ints. Do we know how long it may be before Emacs 27 is out? If it's not that long I wonder if it'd be better for it to be unbuildable on 32-bit systems than to make it installable but unusable without changing other installed packages. >=20 > Regards, >=20 > Diego >=20 > [0]: Emacs' configure.ac file talks about a 10% to 30% slowdown of the > Lisp interpreter and a larger memory footprint. Thank you for looking into this! --=20 Efraim Flashner =D7=90=D7=A4=D7=A8=D7=99=D7=9D = =D7=A4=D7=9C=D7=A9=D7=A0=D7=A8 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --k3qmt+ucFURmlhDS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAl45UhAACgkQQarn3Mo9 g1Hc3Q//VDYuVBcauWFGhE3j1IfyU3aD1F7YnCvHP8oX/y4Fw7HpRG+FWAotQB9i bhnXNTyWxe1sG42373TJOEes57EjBggyZtAZvg/utGZxPGvj45MsqSHxFg6jn8N4 +vAwp0yolX3tdpFDJKX8ZQI138sKtKCHka4J8sKWmKlGOP3UZ5POhKwcl05uWYq6 E7DDWHN5vwfqJUDusUsRsRFmHio9Gj6dtRPyIEDKzzK0rYHOhYJf344+/9CEbynp tFZd5Owmf/6mVEayqYUqX4+wKyP4rJesST4sbLqrb3SLOiWL/K9Y/Cu+MGTj+GUO gYqRtG0c+HT5OsZ8XM6mTGpUdQ0pMge3W7zjp7eywC5VfnMPK5+IR2vnUbJOvOt/ e18GxObK2TUXsrnvWw41NcI6uOiAqwZ0HiZHBaVaZM2el66X3BlPeOMgK/fuUy4H EgVS7Bh2vOe9Pc8R/CkLMTjCNklIffeHDed/issf3qd7ZS75bJjBM/9LnprnIrsr pthz5jo2ipvoXRYqXIrpFBM5sgWouznfG5ChS08/PRYV5QqoIJC6Fmdywz3yKU1h 94zKIebkzYUQXtwqo2VYq7cafDRr+kvuVuIXBJ7Of6WcusY2YGE1CndR5cWXt77n 4mJZ85MeSRcnCo2FnQd0Qq8xzbs74mqShass0bmXiq4rdn4IVk8= =6q3B -----END PGP SIGNATURE----- --k3qmt+ucFURmlhDS--