I want to load a package (my own), fix bugs in it, and reload.
But sbcl keeps reporting name conflicts:
USE-PACKAGE #<PACKAGE "STDLIB"> causes name-conflicts in
#<PACKAGE "COMMON-LISP-USER"> between the following symbols:
STDLIB:MY-NEW-FOOBAR-UNDEFINED-SYMBOL, MY-NEW-FOOBAR-UNDEFINED-SYMBOL
I tried unuse-package and even do-package/unintern on all its symbols,
but I'm still getting name conflicts. I couldn't find the answer in
the Hyperspec
http://www.lisp.org/HyperSpec/Body/sec_11-1-1-2-5.html
and I even tried this:
(defun load-stdlib ()
(when (find-package :stdlib)
(do-symbols (s1 :stdlib)
(let ((s2 (find-symbol (symbol-name s1))))
(when s2
(unintern s2)
(unintern s1))))
(unuse-package :stdlib))
(load "/usr/home/dan/progg/lib/cl/stdlib.l")
( use-package :stdlib))
Still getting name conflicts, even on the first load.
I can load from the repl, but not from the function.
Surely there must be a way to do this?
--
Dan
www.prairienet.org/~dsb/
On May 16, 2:03 pm, Dan Bensen <··········@cyberspace.net> wrote:
> I want to load a package (my own), fix bugs in it, and reload.
> But sbcl keeps reporting name conflicts:
> USE-PACKAGE #<PACKAGE "STDLIB"> causes name-conflicts in
> #<PACKAGE "COMMON-LISP-USER"> between the following symbols:
> STDLIB:MY-NEW-FOOBAR-UNDEFINED-SYMBOL, MY-NEW-FOOBAR-UNDEFINED-SYMBOL
>
> Still getting name conflicts, even on the first load.
> I can load from the repl, but not from the function.
> Surely there must be a way to do this?
You almost certainly have a symbol called MY-NEW-FOOBAR-UNDEFINED-
SYMBOL in the package you're in when you are loading it (probably CL-
USER). (a) get rid of it and (b) work out how it got there (for
instance are you doing something like causing the DEFPACKAGE form to
intern symbols in the package current when it's evaluated, which is a
common mistake)
In article <············@wildfire.prairienet.org>,
Dan Bensen <··········@cyberspace.net> wrote:
> I want to load a package (my own), fix bugs in it, and reload.
You can't 'load a package' or reload it. A package is not
a module.
You can load source or compiled code as you like. You
can load code a second time.
> But sbcl keeps reporting name conflicts:
> USE-PACKAGE #<PACKAGE "STDLIB"> causes name-conflicts in
> #<PACKAGE "COMMON-LISP-USER"> between the following symbols:
> STDLIB:MY-NEW-FOOBAR-UNDEFINED-SYMBOL, MY-NEW-FOOBAR-UNDEFINED-SYMBOL
Somehow you have a symbol MY-NEW-FOOBAR-UNDEFINED-SYMBOL in
CL-USER when you want to use the package STDLIB in package
CL-USER. Where does the CL-USER::MY-NEW-FOOBAR-UNDEFINED-SYMBOL
come from? (describe 'MY-NEW-FOOBAR-UNDEFINED-SYMBOL) ...
So I guess the error is that you have a symbol MY-NEW-FOOBAR-UNDEFINED-SYMBOL
in package CL-USER.
What does your package declaration look like?
>
> I tried unuse-package and even do-package/unintern on all its symbols,
> but I'm still getting name conflicts. I couldn't find the answer in
> the Hyperspec
> http://www.lisp.org/HyperSpec/Body/sec_11-1-1-2-5.html
>
> and I even tried this:
>
> (defun load-stdlib ()
> (when (find-package :stdlib)
> (do-symbols (s1 :stdlib)
> (let ((s2 (find-symbol (symbol-name s1))))
> (when s2
> (unintern s2)
> (unintern s1))))
> (unuse-package :stdlib))
> (load "/usr/home/dan/progg/lib/cl/stdlib.l")
> ( use-package :stdlib))
>
> Still getting name conflicts, even on the first load.
> I can load from the repl, but not from the function.
> Surely there must be a way to do this?
--
http://lispm.dyndns.org
> Dan Bensen <··········@cyberspace.net> wrote:
>> I want to load a package (my own), fix bugs in it, and reload.
Rainer Joswig wrote:
> You can't 'load a package' or reload it. A package is not
> a module.
I want to load the file ... that contains the source code ...
that defines the package.
> Somehow you have a symbol MY-NEW-FOOBAR-UNDEFINED-SYMBOL in
> CL-USER when you want to use the package STDLIB in package
> CL-USER. Where does the CL-USER::MY-NEW-FOOBAR-UNDEFINED-SYMBOL
> come from?
I have no idea.
dan$ sbcl
This is SBCL 1.0.3, ...
* (load "load.l")
T
* (load-stdlib)
debugger invoked on a SB-INT:NAME-CONFLICT in thread #<THREAD "initial
thread" {A74D881}>:
USE-PACKAGE #<PACKAGE "STDLIB"> causes name-conflicts in
#<PACKAGE "COMMON-LISP-USER"> between the following symbols:
STDLIB:MY-NEW-FOOBAR-UNDEFINED-SYMBOL, MY-NEW-FOOBAR-UNDEFINED-SYMBOL
...
0: [RESOLVE-CONFLICT] Resolve conflict.
1: [ABORT ] Exit debugger, returning to top level.
(SB-INT:NAME-CONFLICT
#<PACKAGE "COMMON-LISP-USER">
USE-PACKAGE
#<PACKAGE "STDLIB">)
0] 1
> (describe 'MY-NEW-FOOBAR-UNDEFINED-SYMBOL)
* (describe 'MY-NEW-FOOBAR-UNDEFINED-SYMBOL)
MY-NEW-FOOBAR-UNDEFINED-SYMBOL is
an internal symbol
in #<PACKAGE "COMMON-LISP-USER">.
*
> So I guess the error is that you have a symbol
> MY-NEW-FOOBAR-UNDEFINED-SYMBOL
> in package CL-USER.
> What does your package declaration look like?
(defpackage :stdlib
(:use :cl)
(:export ... my-new-foobar-undefined-symbol ...)
)
(in-package :stdlib)
.
.
.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen <··········@cyberspace.net> writes:
>> Dan Bensen <··········@cyberspace.net> wrote:
>>> I want to load a package (my own), fix bugs in it, and reload.
>
>> So I guess the error is that you have a symbol
>> MY-NEW-FOOBAR-UNDEFINED-SYMBOL in package CL-USER.
>> What does your package declaration look like?
>
> (defpackage :stdlib
> (:use :cl)
> (:export ... my-new-foobar-undefined-symbol ...)
> )
> (in-package :stdlib)
Reading that DEFPACKAGE form has the side effect of creating a symbol
called MY-NEW-FOOBAR-UNDEFINED-SYMBOL into the current package, if the
current package doesn't already contain a symbol with that name
(example below [1]).
Use (1) uninterned symbols, (2) keywords, or (3) strings to denote
symbol names in DEFPACKAGE forms.
Hope that helps,
RmK
[1] Example:
$ sbcl --noinform
* *package*
#<PACKAGE "COMMON-LISP-USER">
* (find-symbol "MY-NEW-FOOBAR-UNDEFINED-SYMBOL")
NIL
NIL
* (defpackage :stdlib (:use :cl) (:export my-new-foobar-undefined-symbol))
#<PACKAGE "STDLIB">
* (find-symbol "MY-NEW-FOOBAR-UNDEFINED-SYMBOL")
MY-NEW-FOOBAR-UNDEFINED-SYMBOL
:INTERNAL
Dan Bensen <··········@cyberspace.net> writes:
>> Dan Bensen <··········@cyberspace.net> wrote:
>>> I want to load a package (my own), fix bugs in it, and reload.
>
> Rainer Joswig wrote:
>> You can't 'load a package' or reload it. A package is not
>> a module.
> I want to load the file ... that contains the source code ...
> that defines the package.
He's not nitpicking -- packages are really just namespace, and not
understanding this properly casuses problems like the below. Evertime your CL
reads in some code it does so in the current *PACKAGE* and all symbols in your
code will be interned in that package (unless they are already present in the
package or a package it USEs). So loading the below:
> (defpackage :stdlib
> (:use :cl)
> (:export ... my-new-foobar-undefined-symbol ...)
Will intern the symbol my-new-foobar-undefined-symbol in whatever *PACKAGE* is
when you load; most likely CL-USER.
Use #:my-new-foobar-undefined-symbol instead; this specifies an uninterned
symbol.
'as
>> Rainer Joswig wrote:
>>> You can't 'load a package' or reload it. A package is not
>>> a module.
> Dan Bensen <··········@cyberspace.net> writes:
>> I want to load the file ... that contains the source code ...
>> that defines the package.
Alexander Schmolck wrote:
> He's not nitpicking -- packages are really just namespace, and not
> understanding this properly casuses problems like the below. Evertime your CL
> reads in some code it does so in the current *PACKAGE* and all symbols in your
> code will be interned in that package (unless they are already present in the
> package or a package it USEs).
Thanks, that's a good point. I just never had this problem in other
programs that used multiple packages. I sort of skipped over the part
where defpackage is read in the pre-existing environment, and I don't
understand why it worked previously when I was calling LOAD directly
from load.l or the repl, but not from inside a function.
> Use #:my-new-foobar-undefined-symbol instead; this specifies an uninterned
> symbol.
Why would #:foo be better than :foo?
Does it avoid creating an extra symbol?
Thanks to everyone for the help.
--
Dan
www.prairienet.org/~dsb/
On May 16, 3:59 pm, Dan Bensen <··········@cyberspace.net> wrote:
> Why would #:foo be better than :foo?
> Does it avoid creating an extra symbol?
It creates a symbol but that symbol belongs to no package, and so, as
soon as any other references to it are gone, its storage can
potentially be reclaimed. DEFPACKAGE itself almost certainly only
uses the symbol for its name, so won't keep a reference to it.
Dan Bensen <··········@cyberspace.net> writes:
>>> Rainer Joswig wrote:
>>>> You can't 'load a package' or reload it. A package is not
>>>> a module.
>
>> Dan Bensen <··········@cyberspace.net> writes:
>>> I want to load the file ... that contains the source code ...
>>> that defines the package.
>
> Alexander Schmolck wrote:
>> He's not nitpicking -- packages are really just namespace, and not
>> understanding this properly casuses problems like the below. Evertime your CL
>> reads in some code it does so in the current *PACKAGE* and all symbols in your
>> code will be interned in that package (unless they are already present in the
>> package or a package it USEs).
>
> Thanks, that's a good point. I just never had this problem in other
> programs that used multiple packages. I sort of skipped over the part
> where defpackage is read in the pre-existing environment, and I don't
> understand why it worked previously when I was calling LOAD directly
> from load.l or the repl, but not from inside a function.
My guess is that you unitendedly messed up *some* package with the symbols as
you were READing the source, but since you didn't then try to import your
newly defined package into the package you messed up, no conflicts occured).
>> Use #:my-new-foobar-undefined-symbol instead; this specifies an uninterned
>> symbol.
>
> Why would #:foo be better than :foo?
> Does it avoid creating an extra symbol?
It creates a symbol, but the symbol is not interned, i.e. it's not stuffed
into some package. All other symbols do belong to a package, so writing e.g.
DEFUN is typically really just a shorthand for CL:DEFUN. DEFUN in isolation
does not exist. (and :BLAH is really just a shorthand for KEYWORD:BLAH; only
that symbols in this package have the special property that they are
self-evaluating).
'as
On Wed, 16 May 2007 09:59:25 -0500, Dan Bensen <··········@cyberspace.net> wrote:
> Why would #:foo be better than :foo?
> Does it avoid creating an extra symbol?
Yes, it's for sissy boys.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Wed, 16 May 2007 09:59:25 -0500, Dan Bensen <··········@cyberspace.net> wrote:
>> Why would #:foo be better than :foo?
>> Does it avoid creating an extra symbol?
> Yes, it's for sissy boys.
Just as I thought. Something about that #: just didn't look right.
--
Dan
www.prairienet.org/~dsb/
On Wed, 16 May 2007 08:49:06 -0500, Dan Bensen <··········@cyberspace.net> wrote:
> > What does your package declaration look like?
>
> (defpackage :stdlib
> (:use :cl)
> (:export ... my-new-foobar-undefined-symbol ...)
> )
I haven't been following the whole thread, but you should consider
replacing
my-new-foobar-undefined-symbol
above with either
"MY-NEW-FOOBAR-UNDEFINED-SYMBOL"
or
:my-new-foobar-undefined-symbol
That way you don't create unwanted symbols in the CL-USER package at
read time.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On May 16, 2:53 pm, Edi Weitz <········@agharta.de> wrote:
> I haven't been following the whole thread, but you should consider
> replacing
>
> my-new-foobar-undefined-symbol
>
> above with either
>
> "MY-NEW-FOOBAR-UNDEFINED-SYMBOL"
>
> or
>
> :my-new-foobar-undefined-symbol
That's bound to be the problem.
Real Men do this with #:my-new-foobar-undefined-symbol.
Edi Weitz wrote:
> I haven't been following the whole thread, but you should consider
> replacing
> my-new-foobar-undefined-symbol
> above with either
> "MY-NEW-FOOBAR-UNDEFINED-SYMBOL"
> or
> :my-new-foobar-undefined-symbol
> That way you don't create unwanted symbols in the CL-USER package at
> read time.
OMG, that works. I guess it would be nice to know why it works from the
repl but not from being called in a function. At least it works and it
makes sense though. Thanks a lot.
--
Dan
www.prairienet.org/~dsb/