f



SLIME C-c C-k causes name-conflicts

Hello,
I have this problem: I visit a file defining a package in emacs slime,
compile and load it with C-c C-k, then switch to the REPL, and do (use-
package ...) and get a condition sb-int:name-conflict. (emacs 22.1.1,
slime 3.0-alpha, sbcl 1.0.6). I believe my lisp file complies with
lisp standards, so give me a hint!

Here is the lisp file I load


(defpackage #:seidel-sparse
  (:use :cl)
  (:export
   *eps*
   #:seidel-sparse))

(in-package #:seidel-sparse)

(defvar *eps* 5d-6)

(defun seidel-sparse(A b x)
  (declare ;(type (simple-array double-float (*)) b x)
	   ;(type (array list (*)) A)
	   (special *eps*))
  "Seidel algorithm for sparse matrices. Solves x=Ax+b for x.
   A[i] = ( (i . aii) . rest )"
  (labels ((seidel1 ()
	     (let ((tmp 0d0)
		   (accur 0d0)
		   (aii 0d0)
		   (n (array-dimension x 0)))
	       (dotimes (i n accur)
		 (setq tmp 0d0
		       aii (/ (- 1d0 (cdar (aref A i)))))
		 (dolist (aij (rest (aref A i)))
		   (incf tmp (* (cdr aij) (aref x (car aij)) aii)))
		 (incf tmp (* (aref b i) aii))
		 (setq accur (max accur (abs (- tmp (aref x i)))))
		 (setf (aref x i) tmp)))))
    (do ((iter 0 (+ 1 iter))
	 (accur (seidel1) (seidel1)))
	((or (> iter 50)
	     (< accur *eps*))))))

Here is what I get:

USE-PACKAGE #<PACKAGE "SEIDEL-SPARSE"> causes name-conflicts in
#<PACKAGE "COMMON-LISP-USER"> between the following symbols:
  SEIDEL-SPARSE:*EPS*, COMMON-LISP-USER::*EPS*
   [Condition of type SB-INT:NAME-CONFLICT]
See also:
  Common Lisp Hyperspec, 11.1.1.2.5 [:section]
0
zoav1602 (22)
6/18/2009 6:14:34 AM
comp.lang.lisp 16861 articles. 5 followers. Post Follow

6 Replies
380 Views

Similar Articles

[PageSpeed] 33

On 18 Jun., 08:14, zoav1602 <zoav1...@gmail.com> wrote:
> Hello,
> I have this problem: I visit a file defining a package in emacs slime,
> compile and load it with C-c C-k, then switch to the REPL, and do (use-
> package ...) and get a condition sb-int:name-conflict. (emacs 22.1.1,
> slime 3.0-alpha, sbcl 1.0.6). I believe my lisp file complies with
> lisp standards, so give me a hint!
>
> Here is the lisp file I load
>
> (defpackage #:seidel-sparse
> =A0 (:use :cl)
> =A0 (:export
> =A0 =A0*eps*
> =A0 =A0#:seidel-sparse))
>
> (in-package #:seidel-sparse)
>
> (defvar *eps* 5d-6)
>
> (defun seidel-sparse(A b x)
> =A0 (declare ;(type (simple-array double-float (*)) b x)
> =A0 =A0 =A0 =A0 =A0 =A0;(type (array list (*)) A)
> =A0 =A0 =A0 =A0 =A0 =A0(special *eps*))
> =A0 "Seidel algorithm for sparse matrices. Solves x=3DAx+b for x.
> =A0 =A0A[i] =3D ( (i . aii) . rest )"
> =A0 (labels ((seidel1 ()
> =A0 =A0 =A0 =A0 =A0 =A0 =A0(let ((tmp 0d0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(accur 0d0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(aii 0d0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(n (array-dimension x 0)))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(dotimes (i n accur)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(setq tmp 0d0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0aii (/ (- 1d0 (cdar (aref =
A i)))))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(dolist (aij (rest (aref A i)))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(incf tmp (* (cdr aij) (aref x (ca=
r aij)) aii)))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(incf tmp (* (aref b i) aii))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(setq accur (max accur (abs (- tmp (ar=
ef x i)))))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(setf (aref x i) tmp)))))
> =A0 =A0 (do ((iter 0 (+ 1 iter))
> =A0 =A0 =A0 =A0 =A0(accur (seidel1) (seidel1)))
> =A0 =A0 =A0 =A0 ((or (> iter 50)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0(< accur *eps*))))))
>
> Here is what I get:
>
> USE-PACKAGE #<PACKAGE "SEIDEL-SPARSE"> causes name-conflicts in
> #<PACKAGE "COMMON-LISP-USER"> between the following symbols:
> =A0 SEIDEL-SPARSE:*EPS*, COMMON-LISP-USER::*EPS*
> =A0 =A0[Condition of type SB-INT:NAME-CONFLICT]
> See also:
> =A0 Common Lisp Hyperspec, 11.1.1.2.5 [:section]

You should escape the *EPS* symbol in the DEFPACKAGE form. Otherwise
it may create something like cl-user::*eps*
depending which package is *package* when you read the defpackage
form.

Use one of these

  "*EPS*"
  :*EPS*
  #:*EPS*

Where I prefer to use strings for all symbol names in DEFPACKAGE,
since it avoids the creation of possibly unwanted symbols.

0
joswig8642 (2203)
6/18/2009 7:29:22 AM
On 18 =C9=C0=CE, 11:29, Rainer Joswig <jos...@lisp.de> wrote:
Nope, this doesn't help. I have the problem even when I load the files
using asdf and then type use-package.
> Use one of these
>
> =9A "*EPS*"
> =9A :*EPS*
> =9A #:*EPS*
>
> Where I prefer to use strings for all symbol names in DEFPACKAGE,
> since it avoids the creation of possibly unwanted symbols.

0
zoav1602 (22)
6/18/2009 7:44:45 AM
On 18 Jun., 09:44, zoav1602 <zoav1...@gmail.com> wrote:
> On 18 =C9=C0=CE, 11:29, Rainer Joswig <jos...@lisp.de> wrote:
> Nope, this doesn't help. I have the problem even when I load the files
> using asdf and then type use-package.

Sure, it has nothing to do with loading, asdf, ...

It is a package problem, read the error.

>
>
>
> > Use one of these
>
> > =9A "*EPS*"
> > =9A :*EPS*
> > =9A #:*EPS*
>
> > Where I prefer to use strings for all symbol names in DEFPACKAGE,
> > since it avoids the creation of possibly unwanted symbols.

Sure it helps.


What does (FIND-SYBMOL "*EPS*" "CL-USER")  return?

If there is a symbol cl-user::*eps*  you need to find out where it is
coming from.
The first guess it is coming from your DEFPACKAGE form.
It might additionally already be present in CL-USER from somewhere
else.

If CL-USER has an *EPS* symbol and you USE your package, which also
exports a symbol
with *EPS* as its name then you get a name clash.

possible actions then:

* why is there *eps* in CL-USER? possibly get rid of it, especially if
it is accidentally introduced
* shadow the cl-user::*eps*
* change the export list of your package


(defpackage #:seidel-sparse
  (:use :cl)
  (:export
   "*EPS*"
   #:seidel-sparse))

0
joswig8642 (2203)
6/18/2009 7:56:44 AM
Rainer Joswig <joswig@lisp.de> writes:
> If CL-USER has an *EPS* symbol and you USE your package, which also
> exports a symbol
> with *EPS* as its name then you get a name clash.
>
> possible actions then:
>
> * why is there *eps* in CL-USER? possibly get rid of it, especially if
>   it is accidentally introduced
> * shadow the cl-user::*eps*
> * change the export list of your package
    and then either shadow cl-user::*eps* before reloading the package
    file and re-using it, or quit and reload everything to reset
    cl-user.

  * do not use cl-user.
      (defpackage "SEIDEL-SPARSE-USER"
         (:nicknames "SSU")
         (:use "CL" "SEIDEL-SPARSE"))
      (in-package "SSU") ; instead of "CL-USER"
      

-- 
__Pascal Bourguignon__
0
pjb (7869)
6/18/2009 8:13:39 AM
When I do all the same things in plain sbcl running in terminal
everything works fine!
When I run a new slime session, find-symbol returns nil for both
"*EPS*" and "SEIDEL-SPARSE", so I load the file into lisp and get this
name-conflict. After changing *eps* into "*EPS*" this complain
disappeared, now Im' facing name-conflict with sparse-seidel. Changing
it to "SPARSE-SEIDEL" doesn't help either. So I think something goes
wrong inside slime+emacs


On 18 =C9=C0=CE, 12:13, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Rainer Joswig <jos...@lisp.de> writes:
> > If CL-USER has an *EPS* symbol and you USE your package, which also
> > exports a symbol
> > with *EPS* as its name then you get a name clash.
>
> > possible actions then:
>
> > * why is there *eps* in CL-USER? possibly get rid of it, especially if
> > =9A it is accidentally introduced
> > * shadow the cl-user::*eps*
> > * change the export list of your package
>
> =9A =9A and then either shadow cl-user::*eps* before reloading the packag=
e
> =9A =9A file and re-using it, or quit and reload everything to reset
> =9A =9A cl-user.
>
> =9A * do not use cl-user.
> =9A =9A =9A (defpackage "SEIDEL-SPARSE-USER"
> =9A =9A =9A =9A =9A(:nicknames "SSU")
> =9A =9A =9A =9A =9A(:use "CL" "SEIDEL-SPARSE"))
> =9A =9A =9A (in-package "SSU") ; instead of "CL-USER"
>
> --
> __Pascal Bourguignon__

0
zoav1602 (22)
6/18/2009 8:24:01 AM
On 18 Jun., 10:24, zoav1602 <zoav1...@gmail.com> wrote:
> When I do all the same things in plain sbcl running in terminal
> everything works fine!

 Your original code shows the error in a simple terminal session with
SBCL:

RJMBP:~ joswig$ sbcl
This is SBCL 1.0.22, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (defpackage #:seidel-sparse
  (:use :cl)
  (:export
   *eps*
   #:seidel-sparse))

#<PACKAGE "SEIDEL-SPARSE">
* (use-package "SEIDEL-SPARSE")

debugger invoked on a NAME-CONFLICT:
  USE-PACKAGE #<PACKAGE "SEIDEL-SPARSE"> causes name-conflicts in
  #<PACKAGE "COMMON-LISP-USER"> between the following symbols:
    SEIDEL-SPARSE:*EPS*, COMMON-LISP-USER::*EPS*
See also:
  The ANSI Standard, Section 11.1.1.2.5

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RESOLVE-CONFLICT] Resolve conflict.
  1: [ABORT           ] Exit debugger, returning to top level.

(NAME-CONFLICT
 #<PACKAGE "COMMON-LISP-USER">
 USE-PACKAGE
 #<PACKAGE "SEIDEL-SPARSE">)[:EXTERNAL]
0]

This goes away when you use "*EPS*" in defpackage (remember, symbols
have uppercase
names internally by default) - as mentioned before.

Also remember, Lisp reads forms with something like READ. READ already
creates the symbols during reading, if necessary - before the code is
compiled and executed.

> When I run a new slime session, find-symbol returns nil for both
> "*EPS*" and "SEIDEL-SPARSE", so I load the file into lisp and get this
> name-conflict. After changing *eps* into "*EPS*" this complain
> disappeared, now Im' facing name-conflict with sparse-seidel. Changing
> it to "SPARSE-SEIDEL" doesn't help either. So I think something goes
> wrong inside slime+emacs
>

You might want to post the error and how to reproduce it...
0
joswig8642 (2203)
6/18/2009 9:33:23 AM
Reply: