GNU bug report logs -
#70357
30.0.50; loadup.el, load nadvice before seq
Previous Next
To reply to this bug, email your comments to 70357 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Fri, 12 Apr 2024 18:21:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Gerd Möllmann <gerd.moellmann <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 12 Apr 2024 18:21:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I would like to propose loading nadvice before seq in loadup.el, for the
following reason:
If a seq.elc exists, and we dump bootstrap-emacs.pdmp, and seq.el gets
loaded, then the cl-generic machinery will want to warn about the fact
that certain method stuff in seq.elc is already compiled. This warning
wants to use somethign from nadvice, and ultimately a recursive load
(warnings.el requires icons.el, which uses seq, which leads to a
warning, etc).
I'm attaching an example log
(I guess one could get more prodictable behaviour if
bootstrap-emacs.pdmp would load only sources.)
[recursive-load.txt (text/plain, attachment)]
[Message part 3 (text/plain, inline)]
In GNU Emacs 30.0.50 (build 1, x86_64-apple-darwin23.4.0, NS
appkit-2487.50 Version 14.4.1 (Build 23E224)) of 2024-04-12 built on
Pro.fritz.box
Repository revision: 21775a936bd3838adaae38bd5c5ec776434736c1
Repository branch: master
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Fri, 12 Apr 2024 19:05:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 70357 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Fri, 12 Apr 2024 20:19:40 +0200
>
> I would like to propose loading nadvice before seq in loadup.el, for the
> following reason:
>
> If a seq.elc exists, and we dump bootstrap-emacs.pdmp, and seq.el gets
> loaded, then the cl-generic machinery will want to warn about the fact
> that certain method stuff in seq.elc is already compiled. This warning
> wants to use somethign from nadvice, and ultimately a recursive load
> (warnings.el requires icons.el, which uses seq, which leads to a
> warning, etc).
>
> I'm attaching an example log
>
> (I guess one could get more prodictable behaviour if
> bootstrap-emacs.pdmp would load only sources.)
Stefan, WDYT about this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Fri, 12 Apr 2024 20:45:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 70357 <at> debbugs.gnu.org (full text, mbox):
> I would like to propose loading nadvice before seq in loadup.el, for the
> following reason:
I'm not opposed to reordering, but ... have you tried? AFAICT, `nadvice`
requires `oclosure` which requires `cl-lib` which uses `seq`, so it
might be tricky.
> If a seq.elc exists, and we dump bootstrap-emacs.pdmp, and seq.el gets
> loaded, then the cl-generic machinery will want to warn about the fact
> that certain method stuff in seq.elc is already compiled. This warning
> wants to use somethign from nadvice, and ultimately a recursive load
> (warnings.el requires icons.el, which uses seq, which leads to a
> warning, etc).
As a general rule, it's better (long term) to try and fix those circular
dependencies by breaking the cycle.
Maybe we could tweak `cl-generic` so it calls the byte-compiler in a way
that silences all the warnings?
Also, I'm not sure loading `icons` is necessary batch mode, so maybe we
could make that conditional.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sat, 13 Apr 2024 04:03:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I would like to propose loading nadvice before seq in loadup.el, for the
>> following reason:
>
> I'm not opposed to reordering, but ... have you tried? AFAICT, `nadvice`
> requires `oclosure` which requires `cl-lib` which uses `seq`, so it
> might be tricky.
Yes, I've tried, and it workds for me (tm). I find it a mess (the whole
thing), but I needed something to get this out of my way so that I can
continue with what I actually want to do. The usual situation...
(Cl-lib using seq is good :-). Made my day :-) :-).).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sat, 13 Apr 2024 05:23:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> As a general rule, it's better (long term) to try and fix those circular
> dependencies by breaking the cycle.
>
> Maybe we could tweak `cl-generic` so it calls the byte-compiler in a way
> that silences all the warnings?
> Also, I'm not sure loading `icons` is necessary batch mode, so maybe we
> could make that conditional.
BTW, do we have a tool that gives us a dependency graph?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sat, 13 Apr 2024 06:20:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 70357 <at> debbugs.gnu.org (full text, mbox):
> Cc: 70357 <at> debbugs.gnu.org
> Date: Fri, 12 Apr 2024 16:43:56 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > If a seq.elc exists, and we dump bootstrap-emacs.pdmp, and seq.el gets
> > loaded, then the cl-generic machinery will want to warn about the fact
> > that certain method stuff in seq.elc is already compiled. This warning
> > wants to use somethign from nadvice, and ultimately a recursive load
> > (warnings.el requires icons.el, which uses seq, which leads to a
> > warning, etc).
>
> As a general rule, it's better (long term) to try and fix those circular
> dependencies by breaking the cycle.
>
> Maybe we could tweak `cl-generic` so it calls the byte-compiler in a way
> that silences all the warnings?
> Also, I'm not sure loading `icons` is necessary batch mode, so maybe we
> could make that conditional.
Me, I don't think I understand the situation well enough. How come
this doesn't happen each time Emacs is built, for example? IOW,
there's something in the situation that triggers this that doesn't
happen "usually", and I don't understand from the description what
that its. This first sentence:
> If a seq.elc exists, and we dump bootstrap-emacs.pdmp, and seq.el gets
> loaded, then the cl-generic machinery will want to warn about the fact
> that certain method stuff in seq.elc is already compiled.
lost me: why is that warning being emitted, if all we need is to load
seq.el during loadup?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sat, 13 Apr 2024 07:09:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: 70357 <at> debbugs.gnu.org
>> Date: Fri, 12 Apr 2024 16:43:56 -0400
>> From: Stefan Monnier via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> > If a seq.elc exists, and we dump bootstrap-emacs.pdmp, and seq.el gets
>> > loaded, then the cl-generic machinery will want to warn about the fact
>> > that certain method stuff in seq.elc is already compiled. This warning
>> > wants to use somethign from nadvice, and ultimately a recursive load
>> > (warnings.el requires icons.el, which uses seq, which leads to a
>> > warning, etc).
>>
>> As a general rule, it's better (long term) to try and fix those circular
>> dependencies by breaking the cycle.
>>
>> Maybe we could tweak `cl-generic` so it calls the byte-compiler in a way
>> that silences all the warnings?
>> Also, I'm not sure loading `icons` is necessary batch mode, so maybe we
>> could make that conditional.
>
> Me, I don't think I understand the situation well enough. How come
> this doesn't happen each time Emacs is built, for example? IOW,
> there's something in the situation that triggers this that doesn't
> happen "usually", and I don't understand from the description what
> that its. This first sentence:
>
>> If a seq.elc exists, and we dump bootstrap-emacs.pdmp, and seq.el gets
>> loaded, then the cl-generic machinery will want to warn about the fact
>> that certain method stuff in seq.elc is already compiled.
>
> lost me: why is that warning being emitted, if all we need is to load
> seq.el during loadup?
loadup.el loads seq.elc in my case, not seq.el, and I think that's the
difference.
My mental model is, Stefan please correct me, that cl-generic calls the
compiler on method functions, effective method function, and such.
If seq.el, the source file, is loaded from loadup, these functions are
not yet compiled. If seq.elc is loaded, the functions are apparently
already compiled, and a warning is emitted.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sat, 13 Apr 2024 07:32:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 70357 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 70357 <at> debbugs.gnu.org
> Date: Sat, 13 Apr 2024 09:07:43 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> If a seq.elc exists, and we dump bootstrap-emacs.pdmp, and seq.el gets
> >> loaded, then the cl-generic machinery will want to warn about the fact
> >> that certain method stuff in seq.elc is already compiled.
> >
> > lost me: why is that warning being emitted, if all we need is to load
> > seq.el during loadup?
>
> loadup.el loads seq.elc in my case, not seq.el, and I think that's the
> difference.
But loadup always loads seq.elc, except when seq.el is newer, so what
am I still missing here?
> My mental model is, Stefan please correct me, that cl-generic calls the
> compiler on method functions, effective method function, and such.
>
> If seq.el, the source file, is loaded from loadup, these functions are
> not yet compiled. If seq.elc is loaded, the functions are apparently
> already compiled, and a warning is emitted.
How to create this situation?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sat, 13 Apr 2024 07:40:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 70357 <at> debbugs.gnu.org
>> Date: Sat, 13 Apr 2024 09:07:43 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> If a seq.elc exists, and we dump bootstrap-emacs.pdmp, and seq.el gets
>> >> loaded, then the cl-generic machinery will want to warn about the fact
>> >> that certain method stuff in seq.elc is already compiled.
>> >
>> > lost me: why is that warning being emitted, if all we need is to load
>> > seq.el during loadup?
>>
>> loadup.el loads seq.elc in my case, not seq.el, and I think that's the
>> difference.
>
> But loadup always loads seq.elc, except when seq.el is newer, so what
> am I still missing here?
I can't answer that. Maybe it's the --temacs=pbootstrap that is used for
dumping? But that's just a guess, I don't know what that does. At least
that seems to be a difference.
>
>> My mental model is, Stefan please correct me, that cl-generic calls the
>> compiler on method functions, effective method function, and such.
>>
>> If seq.el, the source file, is loaded from loadup, these functions are
>> not yet compiled. If seq.elc is loaded, the functions are apparently
>> already compiled, and a warning is emitted.
>
> How to create this situation?
I get that regularly when I make changes in some .c file, build in src,
which builds a new temacs, and so on, and all while seq.elc exists.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sat, 13 Apr 2024 09:30:05 GMT)
Full text and
rfc822 format available.
Message #32 received at 70357 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca, 70357 <at> debbugs.gnu.org
> Date: Sat, 13 Apr 2024 09:39:10 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> If seq.el, the source file, is loaded from loadup, these functions are
> >> not yet compiled. If seq.elc is loaded, the functions are apparently
> >> already compiled, and a warning is emitted.
> >
> > How to create this situation?
>
> I get that regularly when I make changes in some .c file, build in src,
> which builds a new temacs, and so on, and all while seq.elc exists.
Strange. I just tried to reproduce this, but couldn't. I did
"touch src/data.c", then "make", and I see no problem. Moreover,
loadup says
Loading emacs-lisp/seq...
both when it dumps bootstrap-emacs and when it dumps emacs, and that
means it loads seq.elc, not seq.el.
So there's something else here we are missing, I suppose.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sat, 13 Apr 2024 12:45:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 70357 <at> debbugs.gnu.org (full text, mbox):
>> Me, I don't think I understand the situation well enough. How come
>> this doesn't happen each time Emacs is built, for example? IOW,
>> there's something in the situation that triggers this that doesn't
>> happen "usually", and I don't understand from the description what
>> that its. This first sentence:
The bootstrap is quite delicate, in part because depending on which file
is already compiled and which one is not, the execution can be different
(usually the difference is itself caused by hacks needed to get the
bootstrap working).
I did not look in enough detail to see the specific problem.
E.g. I don't know what is the actual warning that we're trying to emit.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sun, 14 Apr 2024 02:31:02 GMT)
Full text and
rfc822 format available.
Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> I did not look in enough detail to see the specific problem. E.g. I
> don't know what is the actual warning that we're trying to emit.
It says
byte-compile-report-error((void-function advice--cd*r))
This should be the occurrence in `byte-compile--function-signature', no?
And nadvice.el maybe not loaded?
AFAIU this could be the cause of the circle and its recursion.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sun, 14 Apr 2024 02:31:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sun, 14 Apr 2024 06:27:04 GMT)
Full text and
rfc822 format available.
Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> I did not look in enough detail to see the specific problem. E.g. I
>> don't know what is the actual warning that we're trying to emit.
>
> It says
>
> byte-compile-report-error((void-function advice--cd*r))
Right, that's where I got the idea from that loading nadvice first might
help.
>
> This should be the occurrence in `byte-compile--function-signature', no?
> And nadvice.el maybe not loaded?
>
> AFAIU this could be the cause of the circle and its recursion.
What Stefan said about the different behaviour when some files are
compiled and others are not, is, I guess, what I see here. Sometimes
things work, sometimes they don't. Eli's attempt to reproduce the
problem also shows that, I think. Hence my thought if it wouldn't be an
idea to ignore .elcs when dumping bootstrap-emacs.pdmp. It doesn't help
with circular dependencies, but at least it is easier to reproduce when
it happens.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sun, 14 Apr 2024 06:27:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sun, 14 Apr 2024 07:32:03 GMT)
Full text and
rfc822 format available.
Message #50 received at 70357 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org>, Stefan Monnier
> <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>,
> 70357 <at> debbugs.gnu.org
> Date: Sun, 14 Apr 2024 08:26:04 +0200
>
> What Stefan said about the different behaviour when some files are
> compiled and others are not, is, I guess, what I see here. Sometimes
> things work, sometimes they don't. Eli's attempt to reproduce the
> problem also shows that, I think. Hence my thought if it wouldn't be an
> idea to ignore .elcs when dumping bootstrap-emacs.pdmp. It doesn't help
> with circular dependencies, but at least it is easier to reproduce when
> it happens.
If we load only *.el files into bootstrap-emacs, then bootstrap-emacs
will be much slower. And since it is used to compile many Lisp files,
the net effect will be to make the build (not just bootstrap, but
_every_ build) slower. This is a serious disadvantage from where I
stand. So I hope we can find a better way of fixing this. Especially
since the problem seems to be marginal and rare, so punishing everyone
because of it doesn't sound TRT to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sun, 14 Apr 2024 12:49:13 GMT)
Full text and
rfc822 format available.
Message #53 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
>> text editors" <bug-gnu-emacs <at> gnu.org>, Stefan Monnier
>> <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>,
>> 70357 <at> debbugs.gnu.org
>> Date: Sun, 14 Apr 2024 08:26:04 +0200
>>
>> What Stefan said about the different behaviour when some files are
>> compiled and others are not, is, I guess, what I see here. Sometimes
>> things work, sometimes they don't. Eli's attempt to reproduce the
>> problem also shows that, I think. Hence my thought if it wouldn't be an
>> idea to ignore .elcs when dumping bootstrap-emacs.pdmp. It doesn't help
>> with circular dependencies, but at least it is easier to reproduce when
>> it happens.
>
> If we load only *.el files into bootstrap-emacs, then bootstrap-emacs
> will be much slower. And since it is used to compile many Lisp files,
> the net effect will be to make the build (not just bootstrap, but
> _every_ build) slower. This is a serious disadvantage from where I
> stand. So I hope we can find a better way of fixing this. Especially
> since the problem seems to be marginal and rare, so punishing everyone
> because of it doesn't sound TRT to me.
Well, it's only 10% of the files that are compiled with bootstrap-emacs
(148 vs. 1464 which are compiled with emacs.pdmp). Anyway, I have a
workaround now in my local repo.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Sun, 14 Apr 2024 14:15:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 70357 <at> debbugs.gnu.org (full text, mbox):
> I did not look in enough detail to see the specific problem.
> E.g. I don't know what is the actual warning that we're trying to emit.
Oh, I see the origin of the problem: `cl-generic` calls `byte-compile`
too early during the bootstrap. Normally, this is avoided with:
(defvar cl--generic-compiler
;; Don't byte-compile the dispatchers if cl-generic itself is not
;; compiled. Otherwise the byte-compiler and all the code on
;; which it depends needs to be usable before cl-generic is loaded,
;; which imposes a significant burden on the bootstrap.
(if (not (compiled-function-p (lambda (x) (+ x 1))))
(lambda (exp) (eval exp t))
;; But do byte-compile the dispatchers once bootstrap is passed:
;; the performance difference is substantial (like a 5x speedup on
;; the `eieio' elisp-benchmark)).
;; To avoid loading the byte-compiler during the final preload,
;; see `cl--generic-prefill-dispatchers'.
#'byte-compile))
but in your case `cl-generic.el` has been compiled, so the `if` test
decides to use the byte-compiler. I haven't figured out why this
doesn't bite more often nor why it bites in this specific case (I
haven't been able to reproduce the problem).
A quick fix could be the patch below.
Stefan
diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index fb3278c08ab..c402f91d67c 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1492,7 +1492,8 @@ byte-compile--function-signature
(and (eq 'macro (car-safe f)) (setq f (cdr f)))
;; Advice wrappers have "catch all" args, so fetch the actual underlying
;; function to find the real arguments.
- (setq f (advice--cd*r f))
+ (when (fboundp 'advice--cd*r) ;;nil during early bootstrap.
+ (setq f (advice--cd*r f)))
(if (eq (car-safe f) 'declared)
(byte-compile-arglist-signature (nth 1 f))
(condition-case nil
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Mon, 15 Apr 2024 03:12:03 GMT)
Full text and
rfc822 format available.
Message #59 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> A quick fix could be the patch below.
Thanks Stefan. I'm now using your change locally to see if anything
doesn't work (but I don't expect that).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Mon, 15 Apr 2024 06:17:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 70357 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> A quick fix could be the patch below.
>
> Thanks Stefan. I'm now using your change locally to see if anything
> doesn't work (but I don't expect that).
I have something, but I'm 100% unsure if this has anything to do with
your patch, not the least because I never got so far in the build
before.
This is with MPS-based GC, and a build from git clean -xdf.
bootstrap-emacs.pdmp is built, some Lisp is compiled, and emacs.pdmp is
about to be dumped.
When loading ns-win (compiled), I get
*** MPS GC start: Generation 0 of a chain has reached capacity: start a minor collection.
Loading term/ns-win...
Error: error ("Missing cl-generic dispatcher in the prefilled cache!
Missing for: ((&context . window-system) cl--generic-eql-generalizer cl--generic-t-generalizer)
You might need to add: (cl--generic-prefill-dispatchers (&context . window-system) (eql 'x))")
signal(error ("Missing cl-generic dispatcher in the prefilled cache!\nMissing for: ((&context . window-system) cl--generic-eql-generalizer cl--generic-t-generalizer)\nYou might need to add: (cl--generic-prefill-dispatchers (&context . window-system) (eql 'x))"))
I'm attaching the full backtrace.
As I said, I have no idea yet what that means. I'll try a build without
MPS a bit later.
[build.log (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Mon, 15 Apr 2024 07:03:05 GMT)
Full text and
rfc822 format available.
Message #65 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> As I said, I have no idea yet what that means. I'll try a build without
> MPS a bit later.
Works without MPS :-|. Only 347293 problems remaining...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Mon, 15 Apr 2024 07:56:04 GMT)
Full text and
rfc822 format available.
Message #68 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> As I said, I have no idea yet what that means. I'll try a build without
>> MPS a bit later.
>
> Works without MPS :-|. Only 347293 problems remaining...
And the reason seems to be that in the non-MPS build purify-flag is nil,
while it isn't in the MPS build. That was too easy. Only (1- 347293)
problems remaining :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Mon, 15 Apr 2024 08:02:04 GMT)
Full text and
rfc822 format available.
Message #71 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> As I said, I have no idea yet what that means. I'll try a build without
>>> MPS a bit later.
>>
>> Works without MPS :-|. Only 347293 problems remaining...
>
> And the reason seems to be that in the non-MPS build purify-flag is nil,
> while it isn't in the MPS build. That was too easy. Only (1- 347293)
> problems remaining :-).
Erm, which begs the question if this answers the FIXME, maybe?
Depending on what the "final" dump is...
(when (and purify-flag ;FIXME: Is this a reliable test of the final dump?
(eq cl--generic-compiler #'byte-compile))
;; We don't want to preload the byte-compiler!!
(error
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Mon, 15 Apr 2024 12:12:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 70357 <at> debbugs.gnu.org (full text, mbox):
> Erm, which begs the question if this answers the FIXME, maybe?
> Depending on what the "final" dump is...
>
> (when (and purify-flag ;FIXME: Is this a reliable test of the final dump?
Yeah, that question is rhetorical.
Especially given that we want to get rid of the pure space anyway.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70357
; Package
emacs
.
(Mon, 15 Apr 2024 12:49:07 GMT)
Full text and
rfc822 format available.
Message #77 received at 70357 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Erm, which begs the question if this answers the FIXME, maybe?
>> Depending on what the "final" dump is...
>>
>> (when (and purify-flag ;FIXME: Is this a reliable test of the final dump?
>
> Yeah, that question is rhetorical.
> Especially given that we want to get rid of the pure space anyway.
👍
I've BTW used one of your patches to get rid of pure space when I added
packages to my local Emacs, which is what the MPS stuff is built on.
Didn't want to ride a dead horse ;-).
This bug report was last modified 1 year and 63 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.