bug#46818: closed (leim bootstrap: Variable binding depth exceeds max-specpdl-size)

[GNU bug Tracking System]

Your message dated Mon, 01 Mar 2021 12:02:50 -0500
with message-id <jwvo8g2q02n.fsf-monnier+emacs@gnu.org>
and subject line Re: bug#46818: leim bootstrap: Variable binding depth exceeds 
max-specpdl-size
has caused the debbugs.gnu.org bug report #46818,
regarding leim bootstrap: Variable binding depth exceeds max-specpdl-size
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
46818: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=46818
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> leim bootstrap: Variable binding depth exceeds max-specpdl-size
>
>
>
>
> Date: 
>
> Sat, 27 Feb 2021 13:17:54 -0500
>
>
>
>
> User-agent: 
>
> Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
>
>
>
>
> Package: emacs
> Version: 28.0.50
>
> When building in a completely clean tree (new checkout or make extraclean)
> at rev a4d7235f1a, I see the following errors when building the leim files:
>
>   GEN      ../lisp/language/pinyin.el
>   GEN      ../lisp/leim/leim-list.el
> Eager macro-expansion failure: (error "Variable binding depth exceeds
>   max-specpdl-size")
>
>   [...]
>   INFO     Processing OKURI-NASI entries...done
>   Eager macro-expansion failure: (error "Variable binding depth exceeds
>   max-specpdl-size")
>
> These issues don't seem to be present at rev 6bf56a; ref
> https://hydra.nixos.org/build/137524247
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#46818: leim bootstrap: Variable binding depth exceeds max-specpdl-size
>
>
>
>
> Date: 
>
> Mon, 01 Mar 2021 12:02:50 -0500
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
>
>
>
>
> >>> In any case, rather than bump the pdl limit, I suggest the patch below,
> >>> which completely avoids the need to macroexpand all that code we won't
> >>> be using anyway.
> >> I'd rather increase the pdl limit.  Having code that subtly evades
> >> using our normal machinery sounds a maintenance headache in the long
> >> run.
> > I agree with Eli here -- increasing the pdl limit here certainly sounds
> > like a less subtle fix.
>
> OK, I've done that now, thanks,
>
>
>         Stefan
>
>
>
> --- End Message ---