bug#55414: 29.0.50; Byte compilation error for the modus-themes

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Lars Ingebrigtsen]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Lars Ingebrigtsen]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

> 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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

> 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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

> 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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

> 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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

> 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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Lars Ingebrigtsen]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Eli Zaretskii]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Mattias Engdegård]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

> 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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Mattias Engdegård]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Lars Ingebrigtsen]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Lars Ingebrigtsen]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

> 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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Lars Ingebrigtsen]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Lars Ingebrigtsen]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Protesilaos Stavrou]

> 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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Lars Ingebrigtsen]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Mattias Engdegård]

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?

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Richard Stallman]

[[[ 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)

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Mattias Engdegård]

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.

bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

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