Name conflict. How can I solve this?
sun...@cad.strath.ac.uk
I loaded some source code on MCL 4.0 and got the following error.
> Error: Name conflict detected by EXPORT :
> EXPORT'ing SCROLLER from #1=#<Package "CCL"> would cause a name conflict with
> the present symbol PAIL-LIB::SCROLLER in the package #<Package "PAIL-LIB">, which
uses #1#.
> While executing: RESOLVE-EXPORT-CONFLICTS
How could I fix this error? Should I change whole name 'scroller' or is there
something else I can do?
Thanks,
Sungwoo
Sent via Deja.com http://www.deja.com/
Before you buy.
Erik Naggum
| I loaded some source code on MCL 4.0 and got the following error.
|
| > Error: Name conflict detected by EXPORT :
| > EXPORT'ing SCROLLER from #1=#<Package "CCL"> would cause a name conflict with
| > the present symbol PAIL-LIB::SCROLLER in the package #<Package "PAIL-LIB">, which uses #1#.
| > While executing: RESOLVE-EXPORT-CONFLICTS
|
| How could I fix this error? Should I change whole name 'scroller' or
| is there something else I can do?
The first thing you need to do is to determine if the two symbols
really should be the same symbol. Chances are they should, but that
one symbol is internal to a package by accident. If you load and
execute all your defpackage forms before you load any other files or
data, this kind of error is unlikely to come up accidentally.
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
Thomas A. Russ
> Hello,
>
> I loaded some source code on MCL 4.0 and got the following error.
>
> > Error: Name conflict detected by EXPORT :
> > EXPORT'ing SCROLLER from #1=#<Package "CCL"> would cause a name conflict with
> > the present symbol PAIL-LIB::SCROLLER in the package #<Package "PAIL-LIB">, which
> uses #1#.
> > While executing: RESOLVE-EXPORT-CONFLICTS
>
> How could I fix this error? Should I change whole name 'scroller' or is there
> something else I can do?
Well, changing the name is one option.
Other options would be to do one of the following changes to the package
definition of PAIL-LIB:
1) Have PAIL-LIB shadow the symbol SCROLLER. That way it would use
its own symbol in preference to the CCL:SCROLLER symbol available via
the :USE CCL declaration.
2) Have the PAIL-LIB package only :USE the COMMON-LISP package and
not the CCL package.
#2 will elminiate more potential conflicts than #1, but if you actually
end up using a lot of MCL extensions to Common Lisp, then you might want
to go with solution #1.
Background: The reason you are getting a conflict is that the package
PAIL-LIB is defined to :USE the package CCL. This might even be the
default action for newly created packages in MCL, but I may be wrong
about that. Any exported symbols in the CCL package are therefore
visible in the PAIL-LIB package. In particular, that means if you
export any additional symbols from CCL, they will also be visible in
PAIL-LIB. The file that you are loading apparently does just that.
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
sun...@my-deja.com
> 1) Have PAIL-LIB shadow the symbol SCROLLER. That way it would use
> its own symbol in preference to the CCL:SCROLLER symbol available via
> the :USE CCL declaration.
Sorry about my ignorance... What does mean that having shadow?
> 2) Have the PAIL-LIB package only :USE the COMMON-LISP package and
> not the CCL package.
Also.... how could I have one specific package only..?
Thanks again.
sun...@cad.strath.ac.uk
> 1) Have PAIL-LIB shadow the symbol SCROLLER. That way it would use
> its own symbol in preference to the CCL:SCROLLER symbol available via
> the :USE CCL declaration.
>
> 2) Have the PAIL-LIB package only :USE the COMMON-LISP package and
> not the CCL package.
>
Now I understand. I started MCL without any other extensions, then didn't get
this name conflict. But I still don't know... what does mean first one....
Pierre R. Mai
> Background: The reason you are getting a conflict is that the package
> PAIL-LIB is defined to :USE the package CCL. This might even be the
> default action for newly created packages in MCL, but I may be wrong
> about that. Any exported symbols in the CCL package are therefore
> visible in the PAIL-LIB package. In particular, that means if you
> export any additional symbols from CCL, they will also be visible in
> PAIL-LIB. The file that you are loading apparently does just that.
Which IMHO seems suspicious, given that IIRC CCL is one of the system
packages in MCL (which started out as Coral Common Lisp, hence CCL).
Those should not be changed by user code, except perhaps in
exceptional circumstances. So I'd look into why the code wants to
mess with CCL...
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Thomas A. Russ
There are some graphical interface elements provided with MCL that are
not loaded by default, but are instead present in library files that can
be loaded later. Since they are provided by Digitool, the fact that
they affect the system's CCL package is not that surprising, although
one could imagine it being friendlier to include and export the symbols
in the default configuration.
Thomas A. Russ
Shadowing means that you tell your package to create its own local
symbol in such a way that it will block the visibility of inherited
symbols.
Anybody know of a good pointer to a CL package tutorial?