GNU bug report logs -
#12548
24.2.50; Eager macro-expansion skipped due to cycle
Previous Next
Reported by: Eli Zaretskii <eliz <at> gnu.org>
Date: Mon, 1 Oct 2012 12:55:02 UTC
Severity: minor
Found in version 24.2.50
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12548 in the body.
You can then email your comments to 12548 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Mon, 01 Oct 2012 12:55:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 01 Oct 2012 12:55:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org. Please check that
the From: line contains a valid email address. After a delay of up
to one day, you should receive an acknowledgment at that address.
Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.
Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug. If you can, give a recipe
starting from `emacs -Q':
The recipe is:
configure
make bootstrap
Since about 2 weeks ago, I see these warning messages while
bootstrapping on MS-Windows, when Lisp files are being byte-compiled.
Two typical examples:
Warning: Eager macro-expansion skipped due to cycle:
Γאª => (load "erc-backend.el") => (macroexpand-all (defun erc-server-connect Γאª)) => (macroexpand (erc-log Γאª)) => (load "erc.el") => (load "erc-backend.el")
Wrote d:/gnu/bzr/emacs/test2/lisp/erc/erc-autoaway.elc
Warning: Eager macro-expansion skipped due to cycle:
Γאª => (load "tramp.el") => (macroexpand-all (defun tramp-action-login Γאª)) => (macroexpand (with-connection-property Γאª)) => (load "tramp-cache.el") => (load "tramp.el")
Wrote d:/gnu/bzr/emacs/test2/lisp/eshell/esh-module.elc
(I don't know what is that binary garbage, maybe some byte code.)
AFAICS, all of these messages are related either to loading tramp.el
or erc-backend.el. But I may have missed others, not sure.
Please remember that byte compilation during bootstrap on Windows is
done with an Emacs binary dumped with .el version of the byte compiler
and its subroutines. I never saw anything similar in "regular" byte
compilation after updating from the master repository, FWIW.
If I can give more information about this, please ask.
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/gnu/bzr/emacs/trunk/etc/DEBUG.
In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600)
of 2012-10-01 on HOME-C4E4A596F7
Bzr revision: 110321 rgm <at> gnu.org-20121001102100-dz558kg6c659l9f6
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (3.4) --no-opt --enable-checking --cflags
-Id:/usr/include/libxml2 -DGLYPH_DEBUG=1'
Important settings:
value of $LANG: ENU
locale-coding-system: cp1255
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x r e p o r t - e m <tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Mon, 01 Oct 2012 15:14:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 12548 <at> debbugs.gnu.org (full text, mbox):
> Since about 2 weeks ago, I see these warning messages while
> bootstrapping on MS-Windows, when Lisp files are being byte-compiled.
Hmm.. you should have seen them since when I introduced the
eager-macroexpansion, which is a bit more than 2 weeks.
> Warning: Eager macro-expansion skipped due to cycle:
> Γאª => (load "erc-backend.el") => (macroexpand-all (defun erc-server-connect Γאª)) => (macroexpand (erc-log Γאª)) => (load "erc.el") => (load "erc-backend.el")
[ Not sure what this Γאª is about, but I'll assume it's some incorrect
encoding of … ]
> AFAICS, all of these messages are related either to loading tramp.el
> or erc-backend.el. But I may have missed others, not sure.
Yes, IIRC there are two such problematic cycles, one with Tramp and
another with ERC (there were a couple more, but I fixed them).
I'm not completely sure how best to fix them, so I preferred to leave
them in and wait for the ERC and Tramp maintainers to fix them later.
They're harmless in the sense that the resulting .elc files should be
correct (and probably even identical).
I think the warning prints a clear and concise description of the cycle,
so it should not be too hard for the maintainers of those packages to
understand the problem and decide how best to fix it.
> and its subroutines. I never saw anything similar in "regular" byte
> compilation after updating from the master repository, FWIW.
A bootstrap under GNU/Linux shows those same warnings.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Mon, 01 Oct 2012 15:32:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 12548 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 12548 <at> debbugs.gnu.org
> Date: Mon, 01 Oct 2012 11:13:04 -0400
>
> > Since about 2 weeks ago, I see these warning messages while
> > bootstrapping on MS-Windows, when Lisp files are being byte-compiled.
>
> Hmm.. you should have seen them since when I introduced the
> eager-macroexpansion, which is a bit more than 2 weeks.
What can I say? I don't bootstrap too often ;-)
> > Warning: Eager macro-expansion skipped due to cycle:
> > Γאª => (load "erc-backend.el") => (macroexpand-all (defun erc-server-connect Γאª)) => (macroexpand (erc-log Γאª)) => (load "erc.el") => (load "erc-backend.el")
>
> [ Not sure what this Γאª is about, but I'll assume it's some incorrect
> encoding of … ]
Most probably. The Windows console is notorious for screwing up
non-ASCII characters, since the encoding used by GUI applications and
by console programs is different.
> > AFAICS, all of these messages are related either to loading tramp.el
> > or erc-backend.el. But I may have missed others, not sure.
>
> Yes, IIRC there are two such problematic cycles, one with Tramp and
> another with ERC (there were a couple more, but I fixed them).
> I'm not completely sure how best to fix them, so I preferred to leave
> them in and wait for the ERC and Tramp maintainers to fix them later.
> They're harmless in the sense that the resulting .elc files should be
> correct (and probably even identical).
>
> I think the warning prints a clear and concise description of the cycle,
> so it should not be too hard for the maintainers of those packages to
> understand the problem and decide how best to fix it.
>
> > and its subroutines. I never saw anything similar in "regular" byte
> > compilation after updating from the master repository, FWIW.
>
> A bootstrap under GNU/Linux shows those same warnings.
Thanks for the info.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Mon, 01 Oct 2012 15:33:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 12548 <at> debbugs.gnu.org (full text, mbox):
Perhaps this should be merged with bug #12473?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Mon, 01 Oct 2012 16:44:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 12548 <at> debbugs.gnu.org (full text, mbox):
> Perhaps this should be merged with bug #12473?
No, 12473 is an actual bug (that is fixed in the trunk AFAIK).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Mon, 01 Oct 2012 17:02:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 12548 <at> debbugs.gnu.org (full text, mbox):
> > Perhaps this should be merged with bug #12473?
>
> No, 12473 is an actual bug (that is fixed in the trunk AFAIK).
Really? I received no notification that it has been fixed.
In fact, I've received no reply at all after my posting that bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Tue, 02 Oct 2012 06:49:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 12548 <at> debbugs.gnu.org (full text, mbox):
This is explained in NEWS, so can this be closed?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Tue, 02 Oct 2012 16:47:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 12548 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 12548 <at> debbugs.gnu.org
> Date: Tue, 02 Oct 2012 02:47:34 -0400
>
>
> This is explained in NEWS, so can this be closed?
I think the relevant maintainers (erc and Tramp) should be made aware
of this, and hopefully fix the problem reported here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Tue, 02 Oct 2012 16:54:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 12548 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> This is explained in NEWS, so can this be closed?
>
> I think the relevant maintainers (erc and Tramp) should be made aware
> of this, and hopefully fix the problem reported here.
It's just that there are many warnings compiling Emacs, this one is
harmless, and we don't normally open reports for them all. (Also, no
offence meant to anyone, but I'm not sure if anyone is maintaining erc,
and I don't think they would find this report anyway.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Tue, 02 Oct 2012 18:09:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 12548 <at> debbugs.gnu.org (full text, mbox):
PS also this for several files:
Compiling emacs-lisp/ert-x.el
Warning: Eager macro-expansion skipped due to cycle:
=> (load "gv.el") => (macroexpand-all (defun gv--defun-declaration
)) => (macroexpand (pcase )) => (load "pcase.el") =>
(macroexpand-all (defmacro pcase-let )) => (macroexpand (dolist ))
=> (load "gv.el")
PPS does using the ellipsis character add anything?
As you can see I lost it during copy-paste from a graphical Emacs to a
-nw one; and it was somehow corrupted in the initial report.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Wed, 03 Oct 2012 01:43:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 12548 <at> debbugs.gnu.org (full text, mbox):
> Compiling emacs-lisp/ert-x.el
> Warning: Eager macro-expansion skipped due to cycle:
> => (load "gv.el") => (macroexpand-all (defun gv--defun-declaration
> )) => (macroexpand (pcase )) => (load "pcase.el") =>
> (macroexpand-all (defmacro pcase-let )) => (macroexpand (dolist ))
> => (load "gv.el")
I think this is the problem due to "loading cl.el causes pcase's use of
dolist to load cl-macs, which loads gv, which loads pcase, ...".
The occurrence of this problem depends on when pcase gets byte-compiled
(since pcase.elc does not require macroexpansion of dolist).
The best fix I can think of is to ban cl.el's dolist, but I have the
strange feeling this suggestion is not going to fly.
> PPS does using the ellipsis character add anything?
As compared to using "..."? It's more concise.
As compared to not writing it at all, the advantage is that it preserves
the Elisp syntax, making the result more clear.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Wed, 03 Oct 2012 01:43:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 12548 <at> debbugs.gnu.org (full text, mbox):
>> This is explained in NEWS, so can this be closed?
> I think the relevant maintainers (erc and Tramp) should be made aware
> of this, and hopefully fix the problem reported here.
I hope the byte-compiler warning will do that for us.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Wed, 03 Oct 2012 07:08:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 12548 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> The best fix I can think of is to ban cl.el's dolist, but I have the
> strange feeling this suggestion is not going to fly.
You mean, drop cl.el's alias of dolist to cl-dolist? Irrespective, it
would be good to do that to remove the confusion of having two
"dolist"s. I guess it depends whether anyone was actually intentionally
requiring cl to get the cl version of dolist...
For the erc one, looks like just moving erc-log and erc-with-buffer from
erc to erc-backend (or a new erc-macs) would solve it. erc requires
erc-backend, so this could not cause any problems other than aesthetic
ones.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Wed, 03 Oct 2012 13:06:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 12548 <at> debbugs.gnu.org (full text, mbox):
>> The best fix I can think of is to ban cl.el's dolist, but I have the
>> strange feeling this suggestion is not going to fly.
> You mean, drop cl.el's alias of dolist to cl-dolist?
Yes.
> Irrespective, it would be good to do that to remove the confusion of
> having two "dolist"s.
Yes.
> I guess it depends whether anyone was actually intentionally requiring
> cl to get the cl version of dolist...
There are definitely users of CL's dolist (i.e. uses of dolist where the
body uses `return').
> For the erc one, looks like just moving erc-log and erc-with-buffer from
> erc to erc-backend (or a new erc-macs) would solve it. erc requires
> erc-backend, so this could not cause any problems other than aesthetic
> ones.
I suggest you send the patch to the ERC maintainers to see what they
think of it. It's not like it's an urgent problem to fix.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Wed, 03 Oct 2012 16:20:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 12548 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> I suggest you send the patch to the ERC maintainers to see what they
> think of it.
I don't think there are any.
http://savannah.gnu.org/projects/erc
has no commits in over 3 years.
> It's not like it's an urgent problem to fix.
No, so I guess we can close this report after all...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Wed, 03 Oct 2012 17:47:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 12548 <at> debbugs.gnu.org (full text, mbox):
>> I suggest you send the patch to the ERC maintainers to see what they
>> think of it.
> I don't think there are any.
> http://savannah.gnu.org/projects/erc
> has no commits in over 3 years.
Hmm... I guess we should ask Michael Olson if he still considers himself
maintainer, and if not, just install whichever patch we think is
cleanest (and update the `erc' package on Savannah to redirect the
curious to the Emacs package).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Thu, 04 Oct 2012 01:40:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 12548 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've been eyeballing patches that get sent to emacs-devel and Cc:'d to me
and signing off on them, but not doing much more than that. We had a
maintainer volunteer a couple years ago, but haven't heard from him since.
I think it would be reasonable to modify sv.gnu.org/p/erc to point to the
Emacs package. The only other users of that package would be users of
Emacs 21 or XEmacs. Emacs 21 doesn't matter much anymore, and XEmacs
already has ERC in their source tree I believe, with their own patches.
On Wed, Oct 3, 2012 at 10:46 AM, Stefan Monnier <monnier <at> iro.umontreal.ca>wrote:
> >> I suggest you send the patch to the ERC maintainers to see what they
> >> think of it.
> > I don't think there are any.
> > http://savannah.gnu.org/projects/erc
> > has no commits in over 3 years.
>
> Hmm... I guess we should ask Michael Olson if he still considers himself
> maintainer, and if not, just install whichever patch we think is
> cleanest (and update the `erc' package on Savannah to redirect the
> curious to the Emacs package).
>
>
> Stefan
>
--
Michael Olson | http://mwolson.org/
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Fri, 05 Oct 2012 20:22:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 12548 <at> debbugs.gnu.org (full text, mbox):
Michael Olson wrote:
> I think it would be reasonable to modify sv.gnu.org/p/erc to point to the
> Emacs package.
If you log in to your Savannah account, you should be able to add a
notice to the erc front page. An explicit notice to erc-announce would
probably be good too.
Do you want us to set "Maintainer: FSF" in all lisp/erc/*.el files
(except erc-desktop-notifications.el)? None of the listed
authors/maintainers have made any changes in ~ 4 years.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12548
; Package
emacs
.
(Fri, 05 Oct 2012 22:26:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 12548 <at> debbugs.gnu.org (full text, mbox):
On Fri, Oct 5, 2012 at 1:21 PM, Glenn Morris <rgm <at> gnu.org> wrote:
> Michael Olson wrote:
>
>> I think it would be reasonable to modify sv.gnu.org/p/erc to point to the
>> Emacs package.
>
> If you log in to your Savannah account, you should be able to add a
> notice to the erc front page. An explicit notice to erc-announce would
> probably be good too.
Done.
> Do you want us to set "Maintainer: FSF" in all lisp/erc/*.el files
> (except erc-desktop-notifications.el)? None of the listed
> authors/maintainers have made any changes in ~ 4 years.
Sounds good.
--
Michael Olson | http://mwolson.org/
bug closed, send any further explanations to
12548 <at> debbugs.gnu.org and Eli Zaretskii <eliz <at> gnu.org>
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Wed, 07 Nov 2012 23:38:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 06 Dec 2012 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 199 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.