[bug#39412] [PATCH 0/2] gnu: emacs-telega: Build with emacs-wide-int on 32-bit systems.

[Diego Nicola Barbato]

Hi Efraim,

Sorry for the long delay.

Efraim Flashner <address@hidden> writes:

> 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,
>> 
>> 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.

Yes, that would lead to the same cryptic errors (i.e. assertion
failures) I mentioned below when running it (although it would build
successfully) on 32-bit systems.

>> 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.
>> 
>> 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

The release cycle for Emacs 27 was started in late December [1] and a
pretest has been released [2], but I don't know how long it's going to
be until 27.1.

> 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.

IMO it's ok for it to require changing other installed packages during a
transitional period (e.g. guix repl currently doesn't work with
`guile-readline' and requires that the guile3.0 variant be installed
instead due to the transition in progress from Guile 2 to Guile 3).  I
do believe that the failure mode of Telega running with `emacs' instead
of `emacs-wide-int' on a 32-bit system is problematic because it doesn't
make it clear what's wrong and how to fix it.  I have tried to address
this in v2 of my patch series by patching Telega to run
`telega-test-env' (the failing test) on startup (i.e. `M-x telega').
That way it fails immediately with the following error message:

  Emacs with wide ints (--with-wide-int) is required

This should hopefully lead users on the right track.

If v2 is still considered inadequate I'm fine with dropping the patches
and waiting for Emacs 27 instead (the failing test would still have to
be tweaked to make it aware of bignums).

> Thank you for looking into this!

Thanks for your feedback!

Diego

>> [0]: Emacs' configure.ac file talks about a 10% to 30% slowdown of the
>> Lisp interpreter and a larger memory footprint.
[1]: https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00635.html
[2]: https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00045.html