GNU bug report logs - #16857
24.3.50; Incorrect output from `list-load-path-shadows'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16857 in the body.
You can then email your comments to 16857 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Sun, 23 Feb 2014 19:50:18 -0500

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.

Message #8 received at 16857 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 16857 <at> debbugs.gnu.org
Subject: Re: bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Sun, 23 Feb 2014 20:06:56 -0500

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.

Message #11 received at 16857 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16857 <at> debbugs.gnu.org
Subject: Re: bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Sun, 23 Feb 2014 20:20:52 -0500

Glenn Morris <rgm <at> 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")

Message #14 received at 16857 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 16857 <at> debbugs.gnu.org
Subject: Re: bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Sun, 23 Feb 2014 20:41:25 -0500

So the actual bug is "slime does not work with Emacs trunk", is that
right?

Message #17 received at 16857 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16857 <at> debbugs.gnu.org
Subject: Re: bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Sun, 23 Feb 2014 20:51:24 -0500

Glenn Morris <rgm <at> gnu.org> writes:

> So the actual bug is "slime does not work with Emacs trunk", is that
> right?

I don't think so.  Slime is manifesting a problem, but it seems that the
problem is not Slime's.  I'll have to dig deeper into the backtrace.

Message #20 received at 16857 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 16857 <at> debbugs.gnu.org
Subject: Re: bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Mon, 24 Feb 2014 16:03:03 -0500

>   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

Message #23 received at 16857 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 16857 <at> debbugs.gnu.org
Subject: Re: bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Mon, 24 Feb 2014 18:16:18 -0500

Stefan Monnier <monnier <at> 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.

Message #26 received at 16857 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 16857 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Mon, 24 Feb 2014 18:34:53 -0500

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.

Message #31 received at 16857 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16857 <at> debbugs.gnu.org, Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Subject: Re: bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Tue, 25 Feb 2014 16:56:58 -0500

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

Message #34 received at 16857 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 16857 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#16857: 24.3.50; Incorrect output from `list-load-path-shadows'
Date: Tue, 25 Feb 2014 22:49:42 -0500

Stefan Monnier <monnier <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.