[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43138: Stack overflow in emacs 27 because of preloading emacs-seq

From: Pierre Langlois
Subject: bug#43138: Stack overflow in emacs 27 because of preloading emacs-seq
Date: Fri, 04 Sep 2020 12:30:53 +0100
User-agent: mu4e 1.4.13; emacs 27.1

Hi Mark,

Replying with the bug on CC, I didn't realise your last email didn't
include it. I assume that was a mistake?

Mark H Weaver writes:

> Hi Pierre,
> Pierre Langlois <pierre.langlois@gmx.com> writes:
>> Mark H Weaver writes:
>>> If 'emacs-seq' is included in Emacs 27, it seems to me that we should
>>> just delete it, unless there's something I'm missing.
>> Agreed, I was curious if there was another reason for needing it, since
>> I /believe/ it's been in emacs proper since 25, but emacs-seq was added
>> in to guix after that. I suspect it it's still listed as a dependency
>> for packages, even though it's not actually needed.
> It might be that the copy of 'emacs-seq' in Emacs 26 was relatively old,
> and that some users and other emacs packages wanted a newer version.  I
> guess that's the rationale for 'emacs-org', and I vaguely recall that we
> might have had an updated Gnus package in the past as well, for the same
> reason.
> Hopefully the version of 'emacs-seq' bundled with Emacs 27 is now
> sufficiently up-to-date.
>> Anyways, I've reconfigured my system with the following patch to fix the
>> issue, let me know if that looks OK!
> Except for a minor typo in the commit log "alongisde", looks good to me.
> Thank you!  I think you should go ahead and push it to 'master', since
> things are currently broken and this is certainly an improvement.  If
> there are remaining issues, they can be addressed in future commits.

OK, pushed to master with 852ae64e11ef9107afabbdb307770f946376addd ,
I'll close the bug as well, I suppose we can open new ones in case
problems arise later.

>> Oh, another thing, I wanted to warn potential users of emacs-seq with a
>> deprecation warning using (guix deprecation), like:
>>     ;; seq.el is included into emacs.
>>     (define-deprecated emacs-seq emacs)
> It's a good thought, but I'm not sure if 'define-deprecated' is the
> right thing here.  This might be a question for Ludovic.
>> It would be good to do that so somebody isn't tempted to re-add it when
>> it's listed a dependency.  But that triggers errors:
>>     error: emacs: unbound variable
>>     hint: Did you forget a `use-modules' form?
>> Am I using it wrong? The (gnu packages emacs) module is included of
>> course.
> I guess that this is most likely caused by a cyclic dependency between
> the (gnu packages emacs) and (gnu packages emacs-xyz) modules.  When
> there's a cyclic dependency between modules, Guile cannot ensure that
> the definitions of imported modules are evaluated first.
> In this case, I guess that (define-deprecated emacs-seq emacs) is
> evaluated before the definition of 'emacs' is evaluated, and that it
> fails to cope with that.
> I wish that we didn't have any cyclic module dependencies, but at this
> point it would require a *major* reorganization of our package modules
> to avoid it.

Ouch, yeah that seems like the problem, I'll see if I can get it to work
as a follow-up, but it seems not really worth the effort :-).


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]