* bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
@ 2014-02-24 0:50 Nathan Trapuzzano
2014-02-24 1:06 ` Glenn Morris
2014-02-24 21:03 ` Stefan Monnier
0 siblings, 2 replies; 10+ messages in thread
From: Nathan Trapuzzano @ 2014-02-24 0:50 UTC (permalink / raw
To: 16857
I'm seeing incorrect behavior from `list-load-path-shadows'. I just
installed Slime from the github master branch. Since it relies on
cl-lib, it comes with its own copy so it will work on older versions of
Emacs. Now, when I do `list-load-path-shadows', here's what it shows:
/home/nathan/opt/elisp/js2-mode-20131118.1516/.dir-locals hides /opt/emacs-trunk/share/emacs/24.3.50/lisp/gnus/.dir-locals
/opt/emacs-trunk/share/emacs/24.3.50/lisp/emacs-lisp/cl-lib hides /home/nathan/opt/elisp/slime/lib/cl-lib
/opt/emacs-trunk/share/emacs/24.3.50/lisp/emacs-lisp/ert hides /home/nathan/opt/elisp/slime/lib/ert
/opt/emacs-trunk/share/emacs/24.3.50/lisp/emacs-lisp/ert-x hides /home/nathan/opt/elisp/slime/lib/ert-x
4 Emacs Lisp load-path shadowings were found
It says that the version of cl-lib that comes with Emacs shadows Slime's
copy. In fact, it's the other way around. I know this is the case
because:
1. Slime's directory comes first in `load-path'.
2. I get warning messages on startup about Emacs' cl-lib being
shadowed ("Real cl-lib shadowed by compatibility cl-lib?
(/home/nathan/opt/elisp/slime/lib/cl-lib.elc)").
3. After removing Slime's copy, Slime no longer exceeds
max-list-eval-depth and max-specpdl-size.
Moreover, when I remove Slime's copy of cl-lib and restart Emacs, here's
what `list-load-path-shadows' prints:
/home/nathan/opt/elisp/js2-mode-20131118.1516/.dir-locals hides /opt/emacs-trunk/share/emacs/24.3.50/lisp/gnus/.dir-locals
/home/nathan/opt/elisp/slime/lib/ert-x hides /opt/emacs-trunk/share/emacs/24.3.50/lisp/emacs-lisp/ert-x
/home/nathan/opt/elisp/slime/lib/ert hides /opt/emacs-trunk/share/emacs/24.3.50/lisp/emacs-lisp/ert
3 Emacs Lisp load-path shadowings were found
For some reason, it now gets the "what shadows what" correct.
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
2014-02-24 0:50 bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows' Nathan Trapuzzano
@ 2014-02-24 1:06 ` Glenn Morris
2014-02-24 1:20 ` Nathan Trapuzzano
2014-02-24 21:03 ` Stefan Monnier
1 sibling, 1 reply; 10+ messages in thread
From: Glenn Morris @ 2014-02-24 1:06 UTC (permalink / raw
To: Nathan Trapuzzano; +Cc: 16857
Nathan Trapuzzano wrote:
> Emacs. Now, when I do `list-load-path-shadows', here's what it shows:
Please show us the full value of `load-path' at that point. Thanks.
> /opt/emacs-trunk/share/emacs/24.3.50/lisp/emacs-lisp/cl-lib hides /home/nathan/opt/elisp/slime/lib/cl-lib
Per the commentary of elpa's cl-lib, this is exactly as it should be.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
2014-02-24 1:06 ` Glenn Morris
@ 2014-02-24 1:20 ` Nathan Trapuzzano
2014-02-24 1:41 ` Glenn Morris
0 siblings, 1 reply; 10+ messages in thread
From: Nathan Trapuzzano @ 2014-02-24 1:20 UTC (permalink / raw
To: Glenn Morris; +Cc: 16857
Glenn Morris <rgm@gnu.org> writes:
> Please show us the full value of `load-path' at that point. Thanks.
Sorry, I was mistaken. Slime's directories are higher, except for
`lib', which contains cl-lib.el. If `list-load-path-shadows' is
behaving correctly, something else has to be wrong. It's as though some
of Slime's cl-lib's definitions are being loaded before the directory
gets moved to the end of `load-path':
1. Slime was exceeding max-lisp-eval-depth at startup.
2. I removed Slime's copy of cl-lib and restarted Emacs.
3. Slime no longer has the problem described in (1).
("/home/nathan/opt/elisp/csharp-mode-20130824.1200/"
"/home/nathan/opt/elisp/expand-region-20131111.329/"
"/home/nathan/opt/elisp/haskell-mode-13.7/"
"/home/nathan/opt/elisp/ido-ubiquitous-20131009.1047/"
"/home/nathan/opt/elisp/ido-vertical-mode-20131209.938/"
"/home/nathan/opt/elisp/js2-mode-20131118.1516/"
"/home/nathan/opt/elisp/sml-mode-6.4/"
"/home/nathan/.emacs.d/lisp"
"/home/nathan/opt/elisp/archives"
"/home/nathan/opt/elisp/bbdb"
"/home/nathan/opt/elisp/csharp-mode-20130824.1200"
"/home/nathan/opt/elisp/emacs-w3m"
"/home/nathan/opt/elisp/expand-region-20131111.329"
"/home/nathan/opt/elisp/haskell-mode-13.7"
"/home/nathan/opt/elisp/ido-ubiquitous-20131009.1047"
"/home/nathan/opt/elisp/ido-vertical-mode-20131209.938"
"/home/nathan/opt/elisp/js2-mode-20131118.1516"
"/home/nathan/opt/elisp/paredit"
"/home/nathan/opt/elisp/slime"
"/home/nathan/opt/elisp/sml-mode-6.4"
"/home/nathan/opt/elisp/web-mode"
"/home/nathan/opt/elisp/archives/gnu"
"/home/nathan/opt/elisp/archives/marmalade"
"/home/nathan/opt/elisp/archives/melpa"
"/home/nathan/opt/elisp/emacs-w3m/share"
"/home/nathan/opt/elisp/slime/contrib"
"/home/nathan/opt/elisp/slime/doc"
"/home/nathan/opt/elisp/emacs-w3m/share/emacs"
"/home/nathan/opt/elisp/emacs-w3m/share/info"
"/home/nathan/opt/elisp/slime/contrib/test"
"/home/nathan/opt/elisp/emacs-w3m/share/emacs/site-lisp"
"/home/nathan/opt/elisp/emacs-w3m/share/emacs/site-lisp/w3m"
"/opt/emacs-trunk/share/emacs/24.3.50/site-lisp"
"/opt/emacs-trunk/share/emacs/site-lisp"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/vc"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/url"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/textmodes"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/progmodes"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/play"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/org"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/nxml"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/net"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/mh-e"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/mail"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/leim"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/language"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/international"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/gnus"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/eshell"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/erc"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/emulation"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/emacs-lisp"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/cedet"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/calendar"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/calc"
"/opt/emacs-trunk/share/emacs/24.3.50/lisp/obsolete"
"/home/nathan/opt/elisp/slime/lib")
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
2014-02-24 0:50 bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows' Nathan Trapuzzano
2014-02-24 1:06 ` Glenn Morris
@ 2014-02-24 21:03 ` Stefan Monnier
2014-02-24 23:16 ` Nathan Trapuzzano
1 sibling, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2014-02-24 21:03 UTC (permalink / raw
To: Nathan Trapuzzano; +Cc: 16857
> 2. I get warning messages on startup about Emacs' cl-lib being
> shadowed ("Real cl-lib shadowed by compatibility cl-lib?
> (/home/nathan/opt/elisp/slime/lib/cl-lib.elc)").
This message comes from slime's cl-lib which shadows Emacs's.
But slime's cl-lib detects the problem, outputs the message, and tries
to work around the problem by changing load-path so that slime's cl-lib
doesn't hide Emacs's any more.
So the "what shadows what" question depends on whether you ask it before
loading cl-lib or afterwards.
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
2014-02-24 21:03 ` Stefan Monnier
@ 2014-02-24 23:16 ` Nathan Trapuzzano
2014-02-24 23:34 ` Glenn Morris
0 siblings, 1 reply; 10+ messages in thread
From: Nathan Trapuzzano @ 2014-02-24 23:16 UTC (permalink / raw
To: Stefan Monnier; +Cc: 16857
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> ... and tries to work around the problem by changing load-path
That's what I thought.
The infinite recursion is happening in slime's cl-lib's cl-position
advice, which itself calls cl-position, which triggers the advice again,
and so on. But that's as much as I've had time to look.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
2014-02-24 23:16 ` Nathan Trapuzzano
@ 2014-02-24 23:34 ` Glenn Morris
2014-02-25 21:56 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Glenn Morris @ 2014-02-24 23:34 UTC (permalink / raw
To: Nathan Trapuzzano; +Cc: 16857
Nathan Trapuzzano wrote:
> The infinite recursion is happening in slime's cl-lib's cl-position
> advice, which itself calls cl-position, which triggers the advice again,
> and so on. But that's as much as I've had time to look.
Sounds like someone needs to install his fix for
http://debbugs.gnu.org/16671
and presumably slime needs to copy it, if they bundle cl-lib.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
2014-02-24 23:34 ` Glenn Morris
@ 2014-02-25 21:56 ` Stefan Monnier
2014-02-26 3:49 ` Nathan Trapuzzano
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2014-02-25 21:56 UTC (permalink / raw
To: Glenn Morris; +Cc: 16857, Nathan Trapuzzano
>> The infinite recursion is happening in slime's cl-lib's cl-position
>> advice, which itself calls cl-position, which triggers the advice again,
>> and so on. But that's as much as I've had time to look.
> Sounds like someone needs to install his fix for
> http://debbugs.gnu.org/16671
I think someone just did a few hours ago,
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
2014-02-25 21:56 ` Stefan Monnier
@ 2014-02-26 3:49 ` Nathan Trapuzzano
0 siblings, 0 replies; 10+ messages in thread
From: Nathan Trapuzzano @ 2014-02-26 3:49 UTC (permalink / raw
To: Stefan Monnier; +Cc: 16857
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> The infinite recursion is happening in slime's cl-lib's cl-position
>>> advice, which itself calls cl-position, which triggers the advice again,
>>> and so on. But that's as much as I've had time to look.
>> Sounds like someone needs to install his fix for
>> http://debbugs.gnu.org/16671
> I think someone just did a few hours ago,
I think this can be closed, thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-02-26 3:49 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-24 0:50 bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows' Nathan Trapuzzano
2014-02-24 1:06 ` Glenn Morris
2014-02-24 1:20 ` Nathan Trapuzzano
2014-02-24 1:41 ` Glenn Morris
2014-02-24 1:51 ` Nathan Trapuzzano
2014-02-24 21:03 ` Stefan Monnier
2014-02-24 23:16 ` Nathan Trapuzzano
2014-02-24 23:34 ` Glenn Morris
2014-02-25 21:56 ` Stefan Monnier
2014-02-26 3:49 ` Nathan Trapuzzano
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).