* bug#55414: 29.0.50; Byte compilation error for the modus-themes @ 2022-05-14 18:07 Protesilaos Stavrou 2022-05-15 13:45 ` Lars Ingebrigtsen 2022-05-26 15:30 ` Mattias Engdegård 0 siblings, 2 replies; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-14 18:07 UTC (permalink / raw) To: 55414 Dear maintainers, Since commit 850074636e73509b09c28e965c1af054a84f4069, my modus-themes no longer byte compile when installing from source. The message is: Error: Lisp nesting exceeds ‘max-lisp-eval-depth’ Steps to reproduce: * Build Emacs with commit 850074636e73509b09c28e965c1af054a84f4069. * git clone https://git.sr.ht/~protesilaos/modus-themes /preferred/path/to/modus-themes * Launch with 'emacs -Q' and evaluate: (require 'package) (package-install-file "/preferred/path/to/modus-themes") * You get the error. The same steps on an earlier commit, such as 2b6a1c98dfba09d6922f1074047853366d26e31e, do not cause any problem. Is there some other information I can provide you with? I was planning to release modus-themes version 2.4.0 and sync it with emacs.git, but cannot do it until this is resolved. Thank you for your time! All the best, Protesilaos (or simply "Prot") -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-14 18:07 bug#55414: 29.0.50; Byte compilation error for the modus-themes Protesilaos Stavrou @ 2022-05-15 13:45 ` Lars Ingebrigtsen [not found] ` <87lev296hl.fsf@protesilaos.com> 2022-05-26 15:30 ` Mattias Engdegård 1 sibling, 1 reply; 45+ messages in thread From: Lars Ingebrigtsen @ 2022-05-15 13:45 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: Alan Mackenzie, 55414 Protesilaos Stavrou <info@protesilaos.com> writes: > Since commit 850074636e73509b09c28e965c1af054a84f4069, my modus-themes > no longer byte compile when installing from source. The message is: > > Error: Lisp nesting exceeds ‘max-lisp-eval-depth’ Could you switch on debug-on-error and post the backtrace? It'd be interesting to see whether it's inflooping or whether the eval depth really is just too small. We've seen similar things (i.e., Emacs now using a bigger depth to compile) with other modules after the symbols-with-positions feature was added, so I've added Alan to the CCs; perhaps he has some comments. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 45+ messages in thread
[parent not found: <87lev296hl.fsf@protesilaos.com>]
* bug#55414: 29.0.50; Byte compilation error for the modus-themes [not found] ` <87lev296hl.fsf@protesilaos.com> @ 2022-05-15 15:16 ` Lars Ingebrigtsen 2022-05-16 7:58 ` Alan Mackenzie 0 siblings, 1 reply; 45+ messages in thread From: Lars Ingebrigtsen @ 2022-05-15 15:16 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: Alan Mackenzie, 55414 Protesilaos Stavrou <info@protesilaos.com> writes: > Thank you! I attach the backtrace with commit 850074636e and also with > the current master (4aa8115855). Looks like it's `byte-compile--first-symbol-with-pos' that's very recursive. Perhaps it should be rewritten to not recurse (i.e., use a stack)? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-15 15:16 ` Lars Ingebrigtsen @ 2022-05-16 7:58 ` Alan Mackenzie 2022-05-16 8:21 ` Protesilaos Stavrou 2022-05-16 11:15 ` Eli Zaretskii 0 siblings, 2 replies; 45+ messages in thread From: Alan Mackenzie @ 2022-05-16 7:58 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Protesilaos Stavrou, 55414 Hello, Lars and Prot. On Sun, May 15, 2022 at 17:16:07 +0200, Lars Ingebrigtsen wrote: > Protesilaos Stavrou <info@protesilaos.com> writes: > > Thank you! I attach the backtrace with commit 850074636e and also with > > the current master (4aa8115855). > Looks like it's `byte-compile--first-symbol-with-pos' that's very > recursive. Perhaps it should be rewritten to not recurse (i.e., use a > stack)? Looking a bit more carefully at the backtrace, it's evident there were two lisp eval depth overflows. The first was in the compilation of the library, where a condition-case was used to discard the diagnostic data (I hate it when this is done). This was in the macro displaying-byte-compile-warnings in .../lisp/emacs-lisp/bytecomp.el. This failure then called the byte compiler error routines, which caused the second overflow, in byte-compile--first-symbol-with-pos. This second overflow is "only just" happening - another few spare slots, and it would have succeeded; at least on this particular part of the program structure. My feeling is that the first overflow is a real overflow, not an infinite recursion, and could you (Prot) please test this by compiling with a larger max-lisp-eval-depth, something like M-: (let ((max-lisp-eval-depth (* 2 max-lisp-eval-depth))) (byte-compile-file "~/Git/Projects/modus-themes/modus-operandi-theme.e...")) If this compilation succeeds, then perhaps we need to increase our default max-lisp-eval-depth. Thanks! > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 7:58 ` Alan Mackenzie @ 2022-05-16 8:21 ` Protesilaos Stavrou 2022-05-16 11:15 ` Eli Zaretskii 1 sibling, 0 replies; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-16 8:21 UTC (permalink / raw) To: Alan Mackenzie, Lars Ingebrigtsen; +Cc: 55414 > From: Alan Mackenzie <acm@muc.de> > Date: Mon, 16 May 2022 07:58:02 +0000 > > Hello, Lars and Prot. Good day Alan (and Lars)! > [... 22 lines elided] > > My feeling is that the first overflow is a real overflow, not an > infinite recursion, and could you (Prot) please test this by compiling > with a larger max-lisp-eval-depth, something like > > M-: (let ((max-lisp-eval-depth (* 2 max-lisp-eval-depth))) > (byte-compile-file > "~/Git/Projects/modus-themes/modus-operandi-theme.e...")) > > If this compilation succeeds, then perhaps we need to increase our > default max-lisp-eval-depth. If I start a new Emacs session and evaluate the form you provided, it still reproduces the error. I need to change it to * 6 to get the desired result. If, however, I delete the .elc file that was just created and retry with * 2 then byte compilation works. Whatever I do, the original max-lisp-eval-depth is not enough. -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 7:58 ` Alan Mackenzie 2022-05-16 8:21 ` Protesilaos Stavrou @ 2022-05-16 11:15 ` Eli Zaretskii 2022-05-16 12:03 ` Alan Mackenzie 1 sibling, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2022-05-16 11:15 UTC (permalink / raw) To: Alan Mackenzie; +Cc: larsi, info, 55414 > Cc: Protesilaos Stavrou <info@protesilaos.com>, 55414@debbugs.gnu.org > Date: Mon, 16 May 2022 07:58:02 +0000 > From: Alan Mackenzie <acm@muc.de> > > M-: (let ((max-lisp-eval-depth (* 2 max-lisp-eval-depth))) > (byte-compile-file > "~/Git/Projects/modus-themes/modus-operandi-theme.e...")) > > If this compilation succeeds, then perhaps we need to increase our > default max-lisp-eval-depth. We do we need to do that by default in Emacs, when the problem is local to this theme? Can't the package arrange for enlarging the threshold only for itself? ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 11:15 ` Eli Zaretskii @ 2022-05-16 12:03 ` Alan Mackenzie 2022-05-16 12:26 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Alan Mackenzie @ 2022-05-16 12:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, info, 55414 Hello, Eli. On Mon, May 16, 2022 at 14:15:38 +0300, Eli Zaretskii wrote: > > Cc: Protesilaos Stavrou <info@protesilaos.com>, 55414@debbugs.gnu.org > > Date: Mon, 16 May 2022 07:58:02 +0000 > > From: Alan Mackenzie <acm@muc.de> > > M-: (let ((max-lisp-eval-depth (* 2 max-lisp-eval-depth))) > > (byte-compile-file > > "~/Git/Projects/modus-themes/modus-operandi-theme.e...")) > > If this compilation succeeds, then perhaps we need to increase our > > default max-lisp-eval-depth. > But do we need to do that by default in Emacs, when the problem is > local to this theme? Can't the package arrange for enlarging the > threshold only for itself? We could. But I get the feeling that there are quite a lot of places which increase max-lisp-eval-depth for their own use. Rather than increase this number of such places, couldn't we just increase the default? Put another way, is there any overwhelming disadvantage to having a larger default value of max-lisp-eval-depth, and possibly max-specpdl-size? These values are not great, particularly compared with the amount of RAM used by Emacs in general. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 12:03 ` Alan Mackenzie @ 2022-05-16 12:26 ` Eli Zaretskii 2022-05-16 13:48 ` Alan Mackenzie 2022-05-26 16:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 2 replies; 45+ messages in thread From: Eli Zaretskii @ 2022-05-16 12:26 UTC (permalink / raw) To: Alan Mackenzie; +Cc: larsi, info, 55414 > Date: Mon, 16 May 2022 12:03:05 +0000 > Cc: larsi@gnus.org, info@protesilaos.com, 55414@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > > > If this compilation succeeds, then perhaps we need to increase our > > > default max-lisp-eval-depth. > > > But do we need to do that by default in Emacs, when the problem is > > local to this theme? Can't the package arrange for enlarging the > > threshold only for itself? > > We could. But I get the feeling that there are quite a lot of places > which increase max-lisp-eval-depth for their own use. Examples of those places? > Put another way, is there any overwhelming disadvantage to having a > larger default value of max-lisp-eval-depth, and possibly > max-specpdl-size? The disadvantage is that higher values prolong the time needed to detect real infinite recursions, and enlarge the probability of hitting C stack overflows, whose consequences are much more serious and harder to endure without losing the session and its edits. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 12:26 ` Eli Zaretskii @ 2022-05-16 13:48 ` Alan Mackenzie 2022-05-16 13:56 ` Eli Zaretskii 2022-05-26 16:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 1 reply; 45+ messages in thread From: Alan Mackenzie @ 2022-05-16 13:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, info, 55414 Hello, Eli. On Mon, May 16, 2022 at 15:26:57 +0300, Eli Zaretskii wrote: > > Date: Mon, 16 May 2022 12:03:05 +0000 > > Cc: larsi@gnus.org, info@protesilaos.com, 55414@debbugs.gnu.org > > From: Alan Mackenzie <acm@muc.de> > > > > If this compilation succeeds, then perhaps we need to increase our > > > > default max-lisp-eval-depth. > > > But do we need to do that by default in Emacs, when the problem is > > > local to this theme? Can't the package arrange for enlarging the > > > threshold only for itself? > > We could. But I get the feeling that there are quite a lot of places > > which increase max-lisp-eval-depth for their own use. > Examples of those places? OK, i've kind of conflated max-lisp-eval-depth with max-specpdl-size, as they seem to be the same sort of thing. In recent months I've increased max-specpdl-size to 5000 in emacs-lisp/comp.el, and also to 5000 (default is 2500) in leim/Makefile.in for the generation of leim-list.el. Also max-specpdl-size to 5000 in admin/grammars/Makefile.in. With a bit of grepping, max-lisp-eval-depth is increased in edebug.el, regexp-opt.el, gnus-sum.el, .... So, apologies, I was thinking more about max-specpdl-size. But surely the default values of both these variables should be sufficiently large to handle almost any evaluation, with only the rarest/most specialised of evaluations needing them increased. > > Put another way, is there any overwhelming disadvantage to having a > > larger default value of max-lisp-eval-depth, and possibly > > max-specpdl-size? > The disadvantage is that higher values prolong the time needed to > detect real infinite recursions, and enlarge the probability of > hitting C stack overflows, whose consequences are much more serious > and harder to endure without losing the session and its edits. Yes. I seem to remember the Elisp manual saying only that these values can be increased considerably without danger. Or something like that. Perhaps we should be a little less vague on this point. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 13:48 ` Alan Mackenzie @ 2022-05-16 13:56 ` Eli Zaretskii 2022-05-16 14:52 ` Protesilaos Stavrou 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2022-05-16 13:56 UTC (permalink / raw) To: Alan Mackenzie; +Cc: larsi, info, 55414 > Date: Mon, 16 May 2022 13:48:27 +0000 > Cc: larsi@gnus.org, info@protesilaos.com, 55414@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > In recent months I've increased max-specpdl-size to 5000 in > emacs-lisp/comp.el, and also to 5000 (default is 2500) in > leim/Makefile.in for the generation of leim-list.el. Also > max-specpdl-size to 5000 in admin/grammars/Makefile.in. What value does modus-themes need? > So, apologies, I was thinking more about max-specpdl-size. But surely > the default values of both these variables should be sufficiently large > to handle almost any evaluation, with only the rarest/most specialised of > evaluations needing them increased. I'm asking why cannot modus-themes be just another exception, since otherwise we do comply with the "handle almost any evaluation" rule of thumb. > > The disadvantage is that higher values prolong the time needed to > > detect real infinite recursions, and enlarge the probability of > > hitting C stack overflows, whose consequences are much more serious > > and harder to endure without losing the session and its edits. > > Yes. I seem to remember the Elisp manual saying only that these values > can be increased considerably without danger. Or something like that. > Perhaps we should be a little less vague on this point. Feel free to make that text less vague. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 13:56 ` Eli Zaretskii @ 2022-05-16 14:52 ` Protesilaos Stavrou 2022-05-16 15:56 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-16 14:52 UTC (permalink / raw) To: Eli Zaretskii, Alan Mackenzie; +Cc: larsi, 55414 > From: Eli Zaretskii <eliz@gnu.org> > Date: Mon, 16 May 2022 16:56:28 +0300 > >> Date: Mon, 16 May 2022 13:48:27 +0000 >> Cc: larsi@gnus.org, info@protesilaos.com, 55414@debbugs.gnu.org >> From: Alan Mackenzie <acm@muc.de> >> >> In recent months I've increased max-specpdl-size to 5000 in >> emacs-lisp/comp.el, and also to 5000 (default is 2500) in >> leim/Makefile.in for the generation of leim-list.el. Also >> max-specpdl-size to 5000 in admin/grammars/Makefile.in. > > What value does modus-themes need? These are the lowest: (setq max-lisp-eval-depth 2800 max-specpdl-size 2900) >> So, apologies, I was thinking more about max-specpdl-size. But surely >> the default values of both these variables should be sufficiently large >> to handle almost any evaluation, with only the rarest/most specialised of >> evaluations needing them increased. > > I'm asking why cannot modus-themes be just another exception, since > otherwise we do comply with the "handle almost any evaluation" rule of > thumb. I am willing to do whatever you consider the best course of action. -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 14:52 ` Protesilaos Stavrou @ 2022-05-16 15:56 ` Eli Zaretskii 2022-05-22 13:10 ` Alan Mackenzie 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2022-05-16 15:56 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: acm, larsi, 55414 > From: Protesilaos Stavrou <info@protesilaos.com> > Cc: larsi@gnus.org, 55414@debbugs.gnu.org > Date: Mon, 16 May 2022 17:52:54 +0300 > > >> In recent months I've increased max-specpdl-size to 5000 in > >> emacs-lisp/comp.el, and also to 5000 (default is 2500) in > >> leim/Makefile.in for the generation of leim-list.el. Also > >> max-specpdl-size to 5000 in admin/grammars/Makefile.in. > > > > What value does modus-themes need? > > These are the lowest: > > (setq max-lisp-eval-depth 2800 > max-specpdl-size 2900) If all we need is to increase the default from 2500 to 3000, I don't mind. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 15:56 ` Eli Zaretskii @ 2022-05-22 13:10 ` Alan Mackenzie 2022-05-22 13:25 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Alan Mackenzie @ 2022-05-22 13:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Protesilaos Stavrou, larsi, 55414 Hello, Eli, Lars, and Prot. On Mon, May 16, 2022 at 18:56:25 +0300, Eli Zaretskii wrote: > > From: Protesilaos Stavrou <info@protesilaos.com> > > Cc: larsi@gnus.org, 55414@debbugs.gnu.org > > Date: Mon, 16 May 2022 17:52:54 +0300 > > >> In recent months I've increased max-specpdl-size to 5000 in > > >> emacs-lisp/comp.el, and also to 5000 (default is 2500) in > > >> leim/Makefile.in for the generation of leim-list.el. Also > > >> max-specpdl-size to 5000 in admin/grammars/Makefile.in. > > > What value does modus-themes need? > > These are the lowest: > > (setq max-lisp-eval-depth 2800 > > max-specpdl-size 2900) > If all we need is to increase the default from 2500 to 3000, I don't > mind. Progress on this bug seems to have stalled. There are actually two (or maybe several) pairs of default values for max-lisp-eval-depth and max-specpdl-size. They are set in src/eval.c in init_eval_once. For when native compilation is enabled the defaults are 1600/2500. When it's not, they're 800/1800. modus-themes needs just short of 3000/3000, presumably when native compilation is enabled. How about setting both pairs of defaults to 3000/3000 (i.e. no longer distinguishing between native compilation being set or not), and closing the bug? It is, in any case, our medium term goal to have native compilation enabled by default. If everybody is OK on this increase, I'm willing to do the patching. I'm still not very clear on the disadvantages of increasing max-lisp-eval-depth and max-specpdl-size substantially (say by 50% or 100%, not by a factor of 10 or so). There are quite a lot of libraries (maybe the order of 10) which have their own (increased) values for one or both of these limit variables. I don't see why it wouldn't be beneficial to use larger defaults, and purge these "private" settings. We may even be able to do this with the proposed 3000/3000 defaults. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-22 13:10 ` Alan Mackenzie @ 2022-05-22 13:25 ` Eli Zaretskii 2022-05-23 3:51 ` Protesilaos Stavrou 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2022-05-22 13:25 UTC (permalink / raw) To: Alan Mackenzie; +Cc: info, larsi, 55414 > Date: Sun, 22 May 2022 13:10:20 +0000 > Cc: Protesilaos Stavrou <info@protesilaos.com>, larsi@gnus.org, > 55414@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > There are actually two (or maybe several) pairs of default values for > max-lisp-eval-depth and max-specpdl-size. They are set in src/eval.c in > init_eval_once. For when native compilation is enabled the defaults are > 1600/2500. When it's not, they're 800/1800. > > modus-themes needs just short of 3000/3000, presumably when native > compilation is enabled. > > How about setting both pairs of defaults to 3000/3000 (i.e. no longer > distinguishing between native compilation being set or not), and closing > the bug? That's too much an increase for the non-native compilation, IMO. > It is, in any case, our medium term goal to have native > compilation enabled by default. How does the default value affect this? I don't want to make the values too large for the reasons I've explained up-thread (and you agreed, AFAIU). Do we know what value is necessary for modus-themes to successfully byte-compile? If so, let's increase the value separately for each case: byte compilation and native-compilation. > I'm still not very clear on the disadvantages of increasing > max-lisp-eval-depth and max-specpdl-size substantially (say by 50% or > 100%, not by a factor of 10 or so). There are quite a lot of libraries > (maybe the order of 10) which have their own (increased) values for one > or both of these limit variables. I don't see why it wouldn't be > beneficial to use larger defaults, and purge these "private" settings. Once again, the benefit was explained up-thread: we get to detect infinite recursion sooner, faster, and more reliably. With that in mind, I cannot understand why you are lobbying for significant increase in these values. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-22 13:25 ` Eli Zaretskii @ 2022-05-23 3:51 ` Protesilaos Stavrou 2022-05-23 10:57 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-23 3:51 UTC (permalink / raw) To: Eli Zaretskii, Alan Mackenzie; +Cc: larsi, 55414 Good day everyone! > From: Alan Mackenzie <acm@muc.de> > Date: Sun, 22 May 2022 13:10:20 +0000 > > There are actually two (or maybe several) pairs of default values for > max-lisp-eval-depth and max-specpdl-size. They are set in src/eval.c in > init_eval_once. For when native compilation is enabled the defaults are > 1600/2500. When it's not, they're 800/1800. > > modus-themes needs just short of 3000/3000, presumably when native > compilation is enabled. I tried Emacs builds with and without native compilation. In both cases, the test succeeds when I set both values close to 3000. > From: Eli Zaretskii <eliz@gnu.org> > Date: Sun, 22 May 2022 16:25:23 +0300 > >> Date: Sun, 22 May 2022 13:10:20 +0000 >> Cc: Protesilaos Stavrou <info@protesilaos.com>, larsi@gnus.org, >> 55414@debbugs.gnu.org >> From: Alan Mackenzie <acm@muc.de> >> >> It is, in any case, our medium term goal to have native >> compilation enabled by default. > > How does the default value affect this? I don't want to make the > values too large for the reasons I've explained up-thread (and you > agreed, AFAIU). > > Do we know what value is necessary for modus-themes to successfully > byte-compile? If so, let's increase the value separately for each > case: byte compilation and native-compilation. Then I should add local variables? I am fine with this. Just need to have your verdict on the matter. -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-23 3:51 ` Protesilaos Stavrou @ 2022-05-23 10:57 ` Eli Zaretskii 2022-05-24 4:37 ` Protesilaos Stavrou 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2022-05-23 10:57 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: acm, larsi, 55414 > From: Protesilaos Stavrou <info@protesilaos.com> > Cc: larsi@gnus.org, 55414@debbugs.gnu.org > Date: Mon, 23 May 2022 06:51:10 +0300 > > > Do we know what value is necessary for modus-themes to successfully > > byte-compile? If so, let's increase the value separately for each > > case: byte compilation and native-compilation. > > Then I should add local variables? I am fine with this. Just need to > have your verdict on the matter. No, I assumed that we could increase the global values separately for each case. But if you can use local values, that'd be fine with me. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-23 10:57 ` Eli Zaretskii @ 2022-05-24 4:37 ` Protesilaos Stavrou 2022-05-24 11:09 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-24 4:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, larsi, 55414 > From: Eli Zaretskii <eliz@gnu.org> > Date: Mon, 23 May 2022 13:57:32 +0300 > >> From: Protesilaos Stavrou <info@protesilaos.com> >> Cc: larsi@gnus.org, 55414@debbugs.gnu.org >> Date: Mon, 23 May 2022 06:51:10 +0300 >> >> > Do we know what value is necessary for modus-themes to successfully >> > byte-compile? If so, let's increase the value separately for each >> > case: byte compilation and native-compilation. >> >> Then I should add local variables? I am fine with this. Just need to >> have your verdict on the matter. > > No, I assumed that we could increase the global values separately for > each case. > > But if you can use local values, that'd be fine with me. I tried setting local values, both by writing them to the files and adding them to .dir-locals.el, but they are ignored. They are also ignored when I visit the files, as I keep getting a warning about risky local variables even after adding those to safe-local-variable-values and ensuring that ignored-local-variable-values is nil. -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-24 4:37 ` Protesilaos Stavrou @ 2022-05-24 11:09 ` Eli Zaretskii 2022-05-25 3:24 ` Protesilaos Stavrou 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2022-05-24 11:09 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: acm, larsi, 55414 > From: Protesilaos Stavrou <info@protesilaos.com> > Cc: acm@muc.de, larsi@gnus.org, 55414@debbugs.gnu.org > Date: Tue, 24 May 2022 07:37:02 +0300 > > > But if you can use local values, that'd be fine with me. > > I tried setting local values, both by writing them to the files and > adding them to .dir-locals.el, but they are ignored. They are also > ignored when I visit the files, as I keep getting a warning about risky > local variables even after adding those to safe-local-variable-values > and ensuring that ignored-local-variable-values is nil. Not sure I understand how you tried that. You should bind those variables to larger values while byte- and native-compiling. If you use a Makefile to do that, do it there; see lisp/Makefile.in for some examples. If the above misses the point, please tell more how you compile the package and how you tried to enlarge the values of those variables. Thanks. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-24 11:09 ` Eli Zaretskii @ 2022-05-25 3:24 ` Protesilaos Stavrou 2022-05-25 13:12 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-25 3:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, larsi, 55414 > From: Eli Zaretskii <eliz@gnu.org> > Date: Tue, 24 May 2022 14:09:28 +0300 > >> From: Protesilaos Stavrou <info@protesilaos.com> >> Cc: acm@muc.de, larsi@gnus.org, 55414@debbugs.gnu.org >> Date: Tue, 24 May 2022 07:37:02 +0300 >> >> > But if you can use local values, that'd be fine with me. >> >> I tried setting local values, both by writing them to the files and >> adding them to .dir-locals.el, but they are ignored. They are also >> ignored when I visit the files, as I keep getting a warning about risky >> local variables even after adding those to safe-local-variable-values >> and ensuring that ignored-local-variable-values is nil. > > Not sure I understand how you tried that. You should bind those > variables to larger values while byte- and native-compiling. If you > use a Makefile to do that, do it there; see lisp/Makefile.in for some > examples. The first approach was to add the following at the end of the relevant files: ;; Local Variables: ;; max-lisp-eval-depth: 3000 ;; max-specpdl-size: 3000 ;; End: Then M-x byte-compile-file with modus-operandi-theme.el: the local variables were ignored. Same for: (package-install-file "/preferred/path/to/modus-themes") The second approach I tried was to add those variables in a .dir-locals.el file which was located in the same directory as the modus-themes. The contents of that file looked like this: ((emacs-lisp-mode . ((max-lisp-eval-depth . 3000) (max-specpdl-size . 3000)))) Again, the values were ignored. These methods work for other variables but not those two. Perhaps because they are considered "risky" as file-local? > If the above misses the point, please tell more how you compile the > package and how you tried to enlarge the values of those variables. I don't use a Makefile. The recipe I shared in the first message to this bug report affects installation via package.el and, by extension, GNU ELPA. -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-25 3:24 ` Protesilaos Stavrou @ 2022-05-25 13:12 ` Eli Zaretskii 2022-05-26 5:55 ` Protesilaos Stavrou 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2022-05-25 13:12 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: acm, larsi, 55414 > From: Protesilaos Stavrou <info@protesilaos.com> > Cc: acm@muc.de, larsi@gnus.org, 55414@debbugs.gnu.org > Date: Wed, 25 May 2022 06:24:46 +0300 > > The first approach was to add the following at the end of the relevant > files: > > ;; Local Variables: > ;; max-lisp-eval-depth: 3000 > ;; max-specpdl-size: 3000 > ;; End: > > Then M-x byte-compile-file with modus-operandi-theme.el: the local > variables were ignored. Same for: > > (package-install-file "/preferred/path/to/modus-themes") > > The second approach I tried was to add those variables in a > .dir-locals.el file which was located in the same directory as the > modus-themes. The contents of that file looked like this: > > ((emacs-lisp-mode . ((max-lisp-eval-depth . 3000) > (max-specpdl-size . 3000)))) > > Again, the values were ignored. How about advising package-install-file? Also, how do other packages overcome similar problems? Surely, this isn't the first or the second package that needs such measures? And finally, any ideas why a package that is just a theme need such large values of these variables? > These methods work for other variables but not those two. Perhaps > because they are considered "risky" as file-local? No, I think that's because these facilities visit the file literally. > > If the above misses the point, please tell more how you compile the > > package and how you tried to enlarge the values of those variables. > > I don't use a Makefile. The recipe I shared in the first message to > this bug report affects installation via package.el and, by extension, > GNU ELPA. If all else fails, perhaps package.el should acquire a feature whereby these variables could be overridden during byte-compilation. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-25 13:12 ` Eli Zaretskii @ 2022-05-26 5:55 ` Protesilaos Stavrou 2022-05-26 11:32 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-26 5:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, larsi, 55414 > From: Eli Zaretskii <eliz@gnu.org> > Date: Wed, 25 May 2022 16:12:37 +0300 > >> From: Protesilaos Stavrou <info@protesilaos.com> >> Cc: acm@muc.de, larsi@gnus.org, 55414@debbugs.gnu.org >> Date: Wed, 25 May 2022 06:24:46 +0300 >> >> The first approach was to add the following at the end of the relevant >> files: >> >> ;; Local Variables: >> ;; max-lisp-eval-depth: 3000 >> ;; max-specpdl-size: 3000 >> ;; End: >> >> Then M-x byte-compile-file with modus-operandi-theme.el: the local >> variables were ignored. Same for: >> >> (package-install-file "/preferred/path/to/modus-themes") >> >> The second approach I tried was to add those variables in a >> .dir-locals.el file which was located in the same directory as the >> modus-themes. The contents of that file looked like this: >> >> ((emacs-lisp-mode . ((max-lisp-eval-depth . 3000) >> (max-specpdl-size . 3000)))) >> >> Again, the values were ignored. > > How about advising package-install-file? You mean at the theme level? I am not sure how that would work and what its potential downsides are. > Also, how do other packages overcome similar problems? Surely, this > isn't the first or the second package that needs such measures? I am not aware of other such cases. This one is specific to the recent changes in Emacs 29 (as noted earlier in this thread). > And finally, any ideas why a package that is just a theme need such > large values of these variables? Because the theme covers about 3300 faces. Assuming other things constant, to get it to byte compile again I need to remove more than 1200 faces, including popular groups like those of Gnus and Helm. >> These methods work for other variables but not those two. Perhaps >> because they are considered "risky" as file-local? > > No, I think that's because these facilities visit the file literally. I see. Thanks! >> > If the above misses the point, please tell more how you compile the >> > package and how you tried to enlarge the values of those variables. >> >> I don't use a Makefile. The recipe I shared in the first message to >> this bug report affects installation via package.el and, by extension, >> GNU ELPA. > > If all else fails, perhaps package.el should acquire a feature whereby > these variables could be overridden during byte-compilation. I am happy with whatever is best for Emacs. Though I do not know enough about package.el to have an informed opinion on the matter. -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-26 5:55 ` Protesilaos Stavrou @ 2022-05-26 11:32 ` Eli Zaretskii 2022-05-26 11:57 ` Lars Ingebrigtsen 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2022-05-26 11:32 UTC (permalink / raw) To: Protesilaos Stavrou, Stefan Monnier; +Cc: acm, larsi, 55414 > From: Protesilaos Stavrou <info@protesilaos.com> > Cc: acm@muc.de, larsi@gnus.org, 55414@debbugs.gnu.org > Date: Thu, 26 May 2022 08:55:00 +0300 > > >> ((emacs-lisp-mode . ((max-lisp-eval-depth . 3000) > >> (max-specpdl-size . 3000)))) > >> > >> Again, the values were ignored. > > > > How about advising package-install-file? > > You mean at the theme level? I am not sure how that would work and what > its potential downsides are. > > > Also, how do other packages overcome similar problems? Surely, this > > isn't the first or the second package that needs such measures? > > I am not aware of other such cases. This one is specific to the recent > changes in Emacs 29 (as noted earlier in this thread). > > > And finally, any ideas why a package that is just a theme need such > > large values of these variables? > > Because the theme covers about 3300 faces. Assuming other things > constant, to get it to byte compile again I need to remove more than > 1200 faces, including popular groups like those of Gnus and Helm. > > >> These methods work for other variables but not those two. Perhaps > >> because they are considered "risky" as file-local? > > > > No, I think that's because these facilities visit the file literally. > > I see. Thanks! > > >> > If the above misses the point, please tell more how you compile the > >> > package and how you tried to enlarge the values of those variables. > >> > >> I don't use a Makefile. The recipe I shared in the first message to > >> this bug report affects installation via package.el and, by extension, > >> GNU ELPA. > > > > If all else fails, perhaps package.el should acquire a feature whereby > > these variables could be overridden during byte-compilation. > > I am happy with whatever is best for Emacs. Though I do not know enough > about package.el to have an informed opinion on the matter. Stefan, WDYT about adding such a facility to package.el? Lars, is it just me, or are you also concerned by a large increase in the default values of these variables? ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-26 11:32 ` Eli Zaretskii @ 2022-05-26 11:57 ` Lars Ingebrigtsen 2022-05-26 12:59 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: Lars Ingebrigtsen @ 2022-05-26 11:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, Protesilaos Stavrou, Stefan Monnier, 55414 Eli Zaretskii <eliz@gnu.org> writes: > Lars, is it just me, or are you also concerned by a large increase in > the default values of these variables? I'm not really that concerned in general, but in this case, the entire problem is apparently due to one function -- byte-compile--first-symbol-with-pos -- that's very recursive. It could be rewritten to not be recursive, and these problems would go away (which we've seen in many contexts now), if I understand correctly. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-26 11:57 ` Lars Ingebrigtsen @ 2022-05-26 12:59 ` Eli Zaretskii 2022-05-26 15:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-27 9:52 ` Alan Mackenzie 2 siblings, 0 replies; 45+ messages in thread From: Eli Zaretskii @ 2022-05-26 12:59 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: acm, info, monnier, 55414 > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: Protesilaos Stavrou <info@protesilaos.com>, Stefan Monnier > <monnier@iro.umontreal.ca>, acm@muc.de, 55414@debbugs.gnu.org > Date: Thu, 26 May 2022 13:57:09 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Lars, is it just me, or are you also concerned by a large increase in > > the default values of these variables? > > I'm not really that concerned in general, but in this case, the entire > problem is apparently due to one function -- > byte-compile--first-symbol-with-pos -- that's very recursive. It could > be rewritten to not be recursive, and these problems would go away > (which we've seen in many contexts now), if I understand correctly. Alan, can you do this, please? ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-26 11:57 ` Lars Ingebrigtsen 2022-05-26 12:59 ` Eli Zaretskii @ 2022-05-26 15:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-26 15:42 ` Protesilaos Stavrou 2022-05-27 9:52 ` Alan Mackenzie 2 siblings, 1 reply; 45+ messages in thread From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-26 15:20 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: acm, Eli Zaretskii, Protesilaos Stavrou, 55414 Lars Ingebrigtsen [2022-05-26 13:57:09] wrote: > Eli Zaretskii <eliz@gnu.org> writes: > >> Lars, is it just me, or are you also concerned by a large increase in >> the default values of these variables? > > I'm not really that concerned in general, but in this case, the entire > problem is apparently due to one function -- > byte-compile--first-symbol-with-pos -- that's very recursive. It could > be rewritten to not be recursive, and these problems would go away > (which we've seen in many contexts now), if I understand correctly. The patch below should significantly reduce the recursion depth (and hopefully make it faster, to boot) because the (loop (cdr form)) call is in tail position (and named-let should hence apply TCO to it). Does it help for modus-themes? Stefan diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index 87798288fb5..6e9ad39c6a7 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -1183,28 +1183,23 @@ byte-compile-abbreviate-file (defun byte-compile--first-symbol-with-pos (form) "Return the \"first\" symbol with position found in form, or 0 if none. Here, \"first\" is by a depth first search." - (let (sym) - (cond - ((symbol-with-pos-p form) form) - ((consp form) - (or (and (symbol-with-pos-p (setq sym (byte-compile--first-symbol-with-pos (car form)))) - sym) - (and (symbolp (setq sym (byte-compile--first-symbol-with-pos (cdr form)))) - sym) - 0)) - ((and (or (vectorp form) (recordp form)) - (> (length form) 0)) - (let ((i 0) - (len (length form)) - elt) - (catch 'sym - (while (< i len) - (when (symbol-with-pos-p - (setq elt (byte-compile--first-symbol-with-pos (aref form i)))) - (throw 'sym elt)) - (setq i (1+ i))) - 0))) - (t 0)))) + (or (named-let loop ((form form)) + (cond + ((symbol-with-pos-p form) form) + ((consp form) + (or (loop (car form)) + (loop (cdr form)))) + ((and (or (vectorp form) (recordp form)) + (> (length form) 0)) + (let ((i 0) + (len (length form)) + elt) + (catch 'sym + (while (< i len) + (when (setq elt (loop (aref form i))) + (throw 'sym elt)) + (setq i (1+ i)))))))) + 0)) (defun byte-compile--warning-source-offset () "Return a source offset from `byte-compile-form-stack'. ^ permalink raw reply related [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-26 15:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-26 15:42 ` Protesilaos Stavrou 0 siblings, 0 replies; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-26 15:42 UTC (permalink / raw) To: Stefan Monnier, Lars Ingebrigtsen; +Cc: acm, Eli Zaretskii, 55414 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Thu, 26 May 2022 11:20:14 -0400 > > The patch below should significantly reduce the recursion depth (and > hopefully make it faster, to boot) because the (loop (cdr form)) call > is in tail position (and named-let should hence apply TCO to it). > > Does it help for modus-themes? Hello Stefan, I applied your patch and in the new build evaluated these: (require 'package) (package-install-file "/path/to/modus-themes") Everything worked as expected. Thank you! -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-26 11:57 ` Lars Ingebrigtsen 2022-05-26 12:59 ` Eli Zaretskii 2022-05-26 15:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-27 9:52 ` Alan Mackenzie 2022-05-27 10:25 ` Lars Ingebrigtsen 2 siblings, 1 reply; 45+ messages in thread From: Alan Mackenzie @ 2022-05-27 9:52 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: acm, Eli Zaretskii, Protesilaos Stavrou, 55414, Stefan Monnier Hello, Lars. On Thu, May 26, 2022 at 13:57:09 +0200, Lars Ingebrigtsen wrote: > Eli Zaretskii <eliz@gnu.org> writes: > > Lars, is it just me, or are you also concerned by a large increase in > > the default values of these variables? > I'm not really that concerned in general, but in this case, the entire > problem .... Which problem would that be, exactly? If it's the failure of modus-themes to compile without causing a stack overflow error, then ... > .... is apparently due to one function -- > byte-compile--first-symbol-with-pos -- that's very recursive. No, no, no, no. byte-compile--first-symbol-with-pos is NOT the cause of the stack overflow - it's part of the handling of that stack overflow, and unfortunately causes a second stack overflow. Having examined Prot's backtraces (around 16th May), I explained this in my post of 2022-05-16 as follows: ######################################################################### Looking a bit more carefully at the backtrace, it's evident there were two lisp eval depth overflows. The first was in the compilation of the library, where a condition-case was used to discard the diagnostic data (I hate it when this is done). This was in the macro displaying-byte-compile-warnings in .../lisp/emacs-lisp/bytecomp.el. This failure then called the byte compiler error routines, which caused the second overflow, in byte-compile--first-symbol-with-pos. This second overflow is "only just" happening - another few spare slots, and it would have succeeded; at least on this particular part of the program structure. ######################################################################### > It could be rewritten to not be recursive, and these problems would go > away (which we've seen in many contexts now), if I understand > correctly. You're saying byte-compile--first-symbol-with-pos could be reformulated to be non-recursive, I think. I don't understand that. It is a function working on an arbitrary tree structure. Such functions are always coded using recursion, aren't they? What am I missing here? > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 9:52 ` Alan Mackenzie @ 2022-05-27 10:25 ` Lars Ingebrigtsen 0 siblings, 0 replies; 45+ messages in thread From: Lars Ingebrigtsen @ 2022-05-27 10:25 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eli Zaretskii, Protesilaos Stavrou, 55414, Stefan Monnier Alan Mackenzie <acm@muc.de> writes: > No, no, no, no. byte-compile--first-symbol-with-pos is NOT the cause of > the stack overflow - it's part of the handling of that stack overflow, > and unfortunately causes a second stack overflow. Prot said that fixing that function made the stack overflow go away, though. > You're saying byte-compile--first-symbol-with-pos could be reformulated > to be non-recursive, I think. I don't understand that. It is a > function working on an arbitrary tree structure. Such functions are > always coded using recursion, aren't they? What am I missing here? Any recursive algorithm can be reformulated as a non-recursive algorithm -- either through tail call optimisation (if you're lucky) or by using a list/stack to stash the data. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-16 12:26 ` Eli Zaretskii 2022-05-16 13:48 ` Alan Mackenzie @ 2022-05-26 16:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 0 replies; 45+ messages in thread From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-26 16:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Mackenzie, larsi, info, 55414 > The disadvantage is that higher values prolong the time needed to > detect real infinite recursions, In my experience, this is rarely the case (or at least, the difference is not large enough to make up for the annoyance of having to deal with those somewhat arbitrary limits). > and enlarge the probability of hitting C stack overflows, This OTOH is the real issue. FWIW, the specpdl stack does not use the C stack, so I'd be happy to completely get rid of this `max-specpdl-size` artificial limit (or set it to a much larger value). Increasing `max-lisp-eval-depth` is much more delicate. > whose consequences are much more serious and harder to endure without > losing the session and its edits. Indeed, C stack overflows are really nasty (and it's difficult/impossible to avoid them reliably, sadly, so we're stuck with conservative approximations like `max-lisp-eval-depth`). Stefan ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-14 18:07 bug#55414: 29.0.50; Byte compilation error for the modus-themes Protesilaos Stavrou 2022-05-15 13:45 ` Lars Ingebrigtsen @ 2022-05-26 15:30 ` Mattias Engdegård 2022-05-27 9:03 ` Mattias Engdegård 2022-05-27 13:59 ` Alan Mackenzie 1 sibling, 2 replies; 45+ messages in thread From: Mattias Engdegård @ 2022-05-26 15:30 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: Alan Mackenzie, Eli Zaretskii, Protesilaos Stavrou, 55414, Stefan Monnier > I'm not really that concerned in general, but in this case, the entire problem is apparently due to one function -- byte-compile--first-symbol-with-pos -- that's very recursive. It could be rewritten to not be recursive, and these problems would go away (which we've seen in many contexts now), if I understand correctly. The cdr-traversal of lists has now been eliminated on master (e05acb07d3). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-26 15:30 ` Mattias Engdegård @ 2022-05-27 9:03 ` Mattias Engdegård 2022-05-27 10:23 ` Lars Ingebrigtsen 2022-05-27 13:59 ` Alan Mackenzie 1 sibling, 1 reply; 45+ messages in thread From: Mattias Engdegård @ 2022-05-27 9:03 UTC (permalink / raw) To: Stefan Monnier Cc: Lars Ingebrigtsen, Alan Mackenzie, Eli Zaretskii, Protesilaos Stavrou, 55414 > The patch below should significantly reduce the recursion depth (and > hopefully make it faster, to boot) because the (loop (cdr form)) call is > in tail position (and named-let should hence apply TCO to it). Sorry Stefan, I didn't see your message until after pushing my change. If you prefer yours, feel free to swap. (They should be equivalent.) ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 9:03 ` Mattias Engdegård @ 2022-05-27 10:23 ` Lars Ingebrigtsen 2022-05-27 10:39 ` Protesilaos Stavrou 0 siblings, 1 reply; 45+ messages in thread From: Lars Ingebrigtsen @ 2022-05-27 10:23 UTC (permalink / raw) To: Mattias Engdegård Cc: Alan Mackenzie, Eli Zaretskii, Stefan Monnier, 55414, Protesilaos Stavrou Mattias Engdegård <mattiase@acm.org> writes: > Sorry Stefan, I didn't see your message until after pushing my > change. If you prefer yours, feel free to swap. (They should be > equivalent.) Duelling patches. 😀 Prot, can you confirm that the change Mattias' pushed also fixed the problem you were seeing? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 10:23 ` Lars Ingebrigtsen @ 2022-05-27 10:39 ` Protesilaos Stavrou 2022-05-27 10:42 ` Lars Ingebrigtsen 0 siblings, 1 reply; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-27 10:39 UTC (permalink / raw) To: Lars Ingebrigtsen, Mattias Engdegård Cc: Alan Mackenzie, Eli Zaretskii, Stefan Monnier, 55414 > From: Lars Ingebrigtsen <larsi@gnus.org> > Date: Fri, 27 May 2022 12:23:08 +0200 > > Mattias Engdegård <mattiase@acm.org> writes: > >> Sorry Stefan, I didn't see your message until after pushing my >> change. If you prefer yours, feel free to swap. (They should be >> equivalent.) > > Duelling patches. 😀 > > Prot, can you confirm that the change Mattias' pushed also fixed the > problem you were seeing? I confirm that Mattias' patch fixes the problem. -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 10:39 ` Protesilaos Stavrou @ 2022-05-27 10:42 ` Lars Ingebrigtsen 2022-05-27 11:32 ` Alan Mackenzie 0 siblings, 1 reply; 45+ messages in thread From: Lars Ingebrigtsen @ 2022-05-27 10:42 UTC (permalink / raw) To: Protesilaos Stavrou Cc: Mattias Engdegård, Eli Zaretskii, Stefan Monnier, 55414, Alan Mackenzie Protesilaos Stavrou <info@protesilaos.com> writes: > I confirm that Mattias' patch fixes the problem. Thanks, I'm closing this bug report, then. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 10:42 ` Lars Ingebrigtsen @ 2022-05-27 11:32 ` Alan Mackenzie 2022-05-27 11:52 ` Lars Ingebrigtsen 2022-05-27 12:15 ` Protesilaos Stavrou 0 siblings, 2 replies; 45+ messages in thread From: Alan Mackenzie @ 2022-05-27 11:32 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: Protesilaos Stavrou, 55414, Mattias Engdegård, Stefan Monnier, acm, Eli Zaretskii Hello, Lars. On Fri, May 27, 2022 at 12:42:41 +0200, Lars Ingebrigtsen wrote: > Protesilaos Stavrou <info@protesilaos.com> writes: > > I confirm that Mattias' patch fixes the problem. How? It's not even clear what problem you and Prot are talking about, even whether it's exactly the same problem. Mattias's patch CAN NOT have fixed Prot's original stack overflow problem. Unless you believe in magic. You have conflated two problems into one, and believe that a solution to the second (the problems with byte-compile--first-symbol-with-pos) somehow have solved the first (the stack overflow in modus-themes). This cannot possibly be. Mattias's patch looks faulty to me. (Background: I wrote byte-compile--first-symbol-with-pos.) > Thanks, I'm closing this bug report, then. Please don't do that yet. The bug is not yet resolved. If you have already done this, do you mind if I reopen it? > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 11:32 ` Alan Mackenzie @ 2022-05-27 11:52 ` Lars Ingebrigtsen 2022-05-27 13:42 ` Alan Mackenzie 2022-05-27 12:15 ` Protesilaos Stavrou 1 sibling, 1 reply; 45+ messages in thread From: Lars Ingebrigtsen @ 2022-05-27 11:52 UTC (permalink / raw) To: Alan Mackenzie Cc: Mattias Engdegård, Protesilaos Stavrou, Eli Zaretskii, Stefan Monnier, 55414 Alan Mackenzie <acm@muc.de> writes: >> Thanks, I'm closing this bug report, then. > > Please don't do that yet. The bug is not yet resolved. If you have > already done this, do you mind if I reopen it? No problem, but it's fine to continue discussion in a closed bug report -- debbugs doesn't care. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 11:52 ` Lars Ingebrigtsen @ 2022-05-27 13:42 ` Alan Mackenzie 2022-05-27 13:50 ` Lars Ingebrigtsen 0 siblings, 1 reply; 45+ messages in thread From: Alan Mackenzie @ 2022-05-27 13:42 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: Protesilaos Stavrou, 55414, Mattias Engdegård, Stefan Monnier, acm, Eli Zaretskii Hello, Lars. On Fri, May 27, 2022 at 13:52:57 +0200, Lars Ingebrigtsen wrote: > Alan Mackenzie <acm@muc.de> writes: > >> Thanks, I'm closing this bug report, then. > > Please don't do that yet. The bug is not yet resolved. If you have > > already done this, do you mind if I reopen it? > No problem, but it's fine to continue discussion in a closed bug > report -- debbugs doesn't care. I'm unhappy about you stating falsehoods on this list, and then ignoring me when I draw your attention to this. You have twice falsely stated that byte-compile--first-symbol-with-pos was responsible for Prot's stack overflow. The first time, on 2022-05-15 was a mistake, and I corrected you. The second time, yesterday was .... what? Why did you ignore me drawing your attention to this today? Why did you repeat this falsehood yesterday? Why did you close the bug on the basis of this falsehood? Or, have I misunderstood something? Please deal with all the points in this post. > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 13:42 ` Alan Mackenzie @ 2022-05-27 13:50 ` Lars Ingebrigtsen 2022-05-28 23:13 ` Richard Stallman 0 siblings, 1 reply; 45+ messages in thread From: Lars Ingebrigtsen @ 2022-05-27 13:50 UTC (permalink / raw) To: Alan Mackenzie Cc: Mattias Engdegård, Protesilaos Stavrou, Eli Zaretskii, Stefan Monnier, 55414 Alan Mackenzie <acm@muc.de> writes: > You have twice falsely stated that byte-compile--first-symbol-with-pos > was responsible for Prot's stack overflow. The first time, on > 2022-05-15 was a mistake, and I corrected you. Sorry, I missed that. > The second time, yesterday was .... what? > > Why did you ignore me drawing your attention to this today? > > Why did you repeat this falsehood yesterday? Why did you close the bug > on the basis of this falsehood? Prot said that Mattias' change fixed the issue. Take a chill pill. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 13:50 ` Lars Ingebrigtsen @ 2022-05-28 23:13 ` Richard Stallman 0 siblings, 0 replies; 45+ messages in thread From: Richard Stallman @ 2022-05-28 23:13 UTC (permalink / raw) To: Lars Ingebrigtsen, acm; +Cc: mattiase, info, eliz, 55414, monnier [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Please, people, be kind to each other. We all make mistakes -- indeed, anyone can make factual statements that are not true. I trust that such mistakes here are usually honest mistakes. When you think someone else is repeating a mistake, it's useful to say so -- in a kind way. For instance, I think that's a mistake, because of XYZ. I'm surprised you insist that it's true. Why do you think so? It's sometimes proper to suggest that a person calm down and be less emotional, less insistent. That suggestion is likely to be more effective if it is said in a way that shows empathy. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 11:32 ` Alan Mackenzie 2022-05-27 11:52 ` Lars Ingebrigtsen @ 2022-05-27 12:15 ` Protesilaos Stavrou 1 sibling, 0 replies; 45+ messages in thread From: Protesilaos Stavrou @ 2022-05-27 12:15 UTC (permalink / raw) To: Alan Mackenzie, Lars Ingebrigtsen Cc: Mattias Engdegård, Eli Zaretskii, Stefan Monnier, 55414, acm > From: Alan Mackenzie <acm@muc.de> > Date: Fri, 27 May 2022 11:32:05 +0000 > >> > I confirm that Mattias' patch fixes the problem. > > How? It's not even clear what problem you and Prot are talking about, > even whether it's exactly the same problem. > > Mattias's patch CAN NOT have fixed Prot's original stack overflow > problem. Unless you believe in magic. > > You have conflated two problems into one, and believe that a solution to > the second (the problems with byte-compile--first-symbol-with-pos) > somehow have solved the first (the stack overflow in modus-themes). > This cannot possibly be. > > Mattias's patch looks faulty to me. (Background: I wrote > byte-compile--first-symbol-with-pos.) I have no technical insight here. All I can do is note that I no longer get the error I originally reported, namely: Error: Lisp nesting exceeds ‘max-lisp-eval-depth’ The themes byte compile with the following on emacs -Q: (require 'package) (package-install-file "/path/to/modus-themes") Whereas before I would get the error and no .elc files would be produced. I am happy to help you test this further. -- Protesilaos Stavrou https://protesilaos.com ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-26 15:30 ` Mattias Engdegård 2022-05-27 9:03 ` Mattias Engdegård @ 2022-05-27 13:59 ` Alan Mackenzie 2022-05-27 16:53 ` Mattias Engdegård 1 sibling, 1 reply; 45+ messages in thread From: Alan Mackenzie @ 2022-05-27 13:59 UTC (permalink / raw) To: Mattias Engdegård Cc: Protesilaos Stavrou, 55414, Stefan Monnier, acm, Lars Ingebrigtsen, Eli Zaretskii Hello, Mattias. On Thu, May 26, 2022 at 17:30:39 +0200, Mattias Engdegård wrote: > > I'm not really that concerned in general, but in this case, the > > entire problem is apparently due to one function -- > > byte-compile--first-symbol-with-pos -- that's very recursive. It > > could be rewritten to not be recursive, and these problems would go > > away (which we've seen in many contexts now), if I understand > > correctly. > The cdr-traversal of lists has now been eliminated on master > (e05acb07d3). Thanks! But you've reduced the functionality - you're removed the code which handled records. Why? Any chance you could restore this, at least until the issues around it have been resolved. Thanks! -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 13:59 ` Alan Mackenzie @ 2022-05-27 16:53 ` Mattias Engdegård 2022-05-27 18:24 ` Alan Mackenzie 0 siblings, 1 reply; 45+ messages in thread From: Mattias Engdegård @ 2022-05-27 16:53 UTC (permalink / raw) To: Alan Mackenzie Cc: 55414, Lars Ingebrigtsen, Eli Zaretskii, Stefan Monnier, Protesilaos Stavrou 27 maj 2022 kl. 15.59 skrev Alan Mackenzie <acm@muc.de>: > Thanks! But you've reduced the functionality - you're removed the code > which handled records. Why? Any chance you could restore this, at > least until the issues around it have been resolved. Certainly, anything can be changed. But records don't need to be handled there since symbols are never read with position inside those. In other words there is no way this could affect how the code behaves, is there? ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 16:53 ` Mattias Engdegård @ 2022-05-27 18:24 ` Alan Mackenzie 2022-05-29 9:18 ` Mattias Engdegård 0 siblings, 1 reply; 45+ messages in thread From: Alan Mackenzie @ 2022-05-27 18:24 UTC (permalink / raw) To: Mattias Engdegård Cc: Protesilaos Stavrou, 55414, Stefan Monnier, acm, Lars Ingebrigtsen, Eli Zaretskii Hello, Mattias. On Fri, May 27, 2022 at 18:53:34 +0200, Mattias Engdegård wrote: > 27 maj 2022 kl. 15.59 skrev Alan Mackenzie <acm@muc.de>: > > Thanks! But you've reduced the functionality - you're removed the code > > which handled records. Why? Any chance you could restore this, at > > least until the issues around it have been resolved. > Certainly, anything can be changed. Then please do it. > But records don't need to be handled there since symbols are never > read with position inside those. This is a poor argument. Records are typically not read as such by the reader. They are created by macro expansion from cl-defstruct or the like. These expansions contain symbols with position. > In other words there is no way this could affect how the code behaves, > is there? I may be wrong, but I think there is. However, the burden of proof is on your side. Please fulfil it. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-27 18:24 ` Alan Mackenzie @ 2022-05-29 9:18 ` Mattias Engdegård 2022-05-29 13:38 ` Alan Mackenzie 0 siblings, 1 reply; 45+ messages in thread From: Mattias Engdegård @ 2022-05-29 9:18 UTC (permalink / raw) To: Alan Mackenzie Cc: 55414, Lars Ingebrigtsen, Eli Zaretskii, Stefan Monnier, Protesilaos Stavrou 27 maj 2022 kl. 20.24 skrev Alan Mackenzie <acm@muc.de>: > Records are typically not read as such by the > reader. They are created by macro expansion from cl-defstruct or the > like. While that could happen, it doesn't change the fact that once built, that record literal is an opaque piece of data inside which no further diagnostics will be reported. (Much like vectors for that matter.) However there is no appreciable cost to traverse records as well so that has now been changed. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#55414: 29.0.50; Byte compilation error for the modus-themes 2022-05-29 9:18 ` Mattias Engdegård @ 2022-05-29 13:38 ` Alan Mackenzie 0 siblings, 0 replies; 45+ messages in thread From: Alan Mackenzie @ 2022-05-29 13:38 UTC (permalink / raw) To: Mattias Engdegård Cc: 55414, Lars Ingebrigtsen, Eli Zaretskii, Stefan Monnier, Protesilaos Stavrou Hello, Mattias. On Sun, May 29, 2022 at 11:18:51 +0200, Mattias Engdegård wrote: > 27 maj 2022 kl. 20.24 skrev Alan Mackenzie <acm@muc.de>: > > Records are typically not read as such by the > > reader. They are created by macro expansion from cl-defstruct or the > > like. > While that could happen, it doesn't change the fact that once built, > that record literal is an opaque piece of data inside which no further > diagnostics will be reported. (Much like vectors for that matter.) You're telling me (I didn't know already) that, e.g., lambda forms inside vectors do not normally get byte compiled. This might be regarded as a bug. However, consider the following: (defvar asdf nil) (defun foo () "doc string" (eval-when-compile (let ((baz [ (lambda () (message "bar")) ] )) (aset baz 0 (byte-compile (aref baz 0))) (setq asdf baz)))) .. It will be seen that the element of the vector baz gets compiled, and the vector gets written to the global variable asdf. Admittedly, the position information is currently stripped from the object before the byte-compile is evaluated, but there is no reason this will necessarily always be the case. > However there is no appreciable cost to traverse records as well so > that has now been changed. Thanks! -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2022-05-29 13:38 UTC | newest] Thread overview: 45+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-05-14 18:07 bug#55414: 29.0.50; Byte compilation error for the modus-themes Protesilaos Stavrou 2022-05-15 13:45 ` Lars Ingebrigtsen [not found] ` <87lev296hl.fsf@protesilaos.com> 2022-05-15 15:16 ` Lars Ingebrigtsen 2022-05-16 7:58 ` Alan Mackenzie 2022-05-16 8:21 ` Protesilaos Stavrou 2022-05-16 11:15 ` Eli Zaretskii 2022-05-16 12:03 ` Alan Mackenzie 2022-05-16 12:26 ` Eli Zaretskii 2022-05-16 13:48 ` Alan Mackenzie 2022-05-16 13:56 ` Eli Zaretskii 2022-05-16 14:52 ` Protesilaos Stavrou 2022-05-16 15:56 ` Eli Zaretskii 2022-05-22 13:10 ` Alan Mackenzie 2022-05-22 13:25 ` Eli Zaretskii 2022-05-23 3:51 ` Protesilaos Stavrou 2022-05-23 10:57 ` Eli Zaretskii 2022-05-24 4:37 ` Protesilaos Stavrou 2022-05-24 11:09 ` Eli Zaretskii 2022-05-25 3:24 ` Protesilaos Stavrou 2022-05-25 13:12 ` Eli Zaretskii 2022-05-26 5:55 ` Protesilaos Stavrou 2022-05-26 11:32 ` Eli Zaretskii 2022-05-26 11:57 ` Lars Ingebrigtsen 2022-05-26 12:59 ` Eli Zaretskii 2022-05-26 15:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-26 15:42 ` Protesilaos Stavrou 2022-05-27 9:52 ` Alan Mackenzie 2022-05-27 10:25 ` Lars Ingebrigtsen 2022-05-26 16:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-26 15:30 ` Mattias Engdegård 2022-05-27 9:03 ` Mattias Engdegård 2022-05-27 10:23 ` Lars Ingebrigtsen 2022-05-27 10:39 ` Protesilaos Stavrou 2022-05-27 10:42 ` Lars Ingebrigtsen 2022-05-27 11:32 ` Alan Mackenzie 2022-05-27 11:52 ` Lars Ingebrigtsen 2022-05-27 13:42 ` Alan Mackenzie 2022-05-27 13:50 ` Lars Ingebrigtsen 2022-05-28 23:13 ` Richard Stallman 2022-05-27 12:15 ` Protesilaos Stavrou 2022-05-27 13:59 ` Alan Mackenzie 2022-05-27 16:53 ` Mattias Engdegård 2022-05-27 18:24 ` Alan Mackenzie 2022-05-29 9:18 ` Mattias Engdegård 2022-05-29 13:38 ` Alan Mackenzie
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).