[Sbcl-devel] How to resolve name conflicts between packages?

I use SBCL with Slime and I don't know which is causing this issue, so I
thought I'd start here.
For a long time if I ran into name conflicts between packages I had the
option to select which one to proceed with. I update SBCL every other
release or so. Within the last three or four months the option to select
the source to use for a name seems to have disappeared, and instead an
error is generated:
error:
(during compile-time-too processing)
USE-PACKAGE #<PACKAGE "CL-EXTRA"> causes name-conflicts in #<PACKAGE "FINANCE">
between the following symbols:
CL-EXTRA:DATE, FINANCE::DATE
--> EVAL-WHEN
==>
I miss the old behavior - particularly as very often the name conflicts
are caused by including a package I had forgotten, so that one of the
"packages" is the interned function name which doesn't even exist (i.e.,
there is no real conflict).
Is this the desired behavior? If so, short of killing the
*inferior-lisp* instance and restarting the whole thing, how might one
proceed once a name conflict is encountered. FMAKUNBOUND doesn't fix
anything.
Regards,
Jeff Cunningham

Thread view

I use SBCL with Slime and I don't know which is causing this issue, so I
thought I'd start here.
For a long time if I ran into name conflicts between packages I had the
option to select which one to proceed with. I update SBCL every other
release or so. Within the last three or four months the option to select
the source to use for a name seems to have disappeared, and instead an
error is generated:
error:
(during compile-time-too processing)
USE-PACKAGE #<PACKAGE "CL-EXTRA"> causes name-conflicts in #<PACKAGE "FINANCE">
between the following symbols:
CL-EXTRA:DATE, FINANCE::DATE
--> EVAL-WHEN
==>
I miss the old behavior - particularly as very often the name conflicts
are caused by including a package I had forgotten, so that one of the
"packages" is the interned function name which doesn't even exist (i.e.,
there is no real conflict).
Is this the desired behavior? If so, short of killing the
*inferior-lisp* instance and restarting the whole thing, how might one
proceed once a name conflict is encountered. FMAKUNBOUND doesn't fix
anything.
Regards,
Jeff Cunningham

Hi,
"J. K. Cunningham" <J.k.cunningham@...> writes:
> I miss the old behavior - particularly as very often the name
> conflicts are caused by including a package I had forgotten, so that
> one of the "packages" is the interned function name which doesn't even
> exist (i.e., there is no real conflict).
Yes, I miss it too. It seems there are some hairy issues with packages,
hash tables, and threads. IIRC, they are supposed to be resolved at some
point.
> If so, short of killing the *inferior-lisp* instance and restarting
> the whole thing, how might one proceed once a name conflict is
> encountered. FMAKUNBOUND doesn't fix anything.
use UNINTERN.
(unintern 'symbol :package)
works.
Regards,
Mario.

m_mommer@... (Mario S. Mommer) writes:
> Hi,
>
> "J. K. Cunningham" <J.k.cunningham@...> writes:
>> I miss the old behavior - particularly as very often the name
>> conflicts are caused by including a package I had forgotten, so that
>> one of the "packages" is the interned function name which doesn't even
>> exist (i.e., there is no real conflict).
>
> Yes, I miss it too. It seems there are some hairy issues with packages,
> hash tables, and threads. IIRC, they are supposed to be resolved at some
> point.
It's already resolved.
The problem here is that SBCL no longer invokes
debugger during compilation errors, but just records them.
--
With Best Regards, Stas.

"J. K. Cunningham" <J.k.cunningham@...> writes:
> I use SBCL with Slime and I don't know which is causing this issue, so I
> thought I'd start here.
>
> For a long time if I ran into name conflicts between packages I had the
> option to select which one to proceed with. I update SBCL every other
> release or so. Within the last three or four months the option to select
> the source to use for a name seems to have disappeared, and instead an
> error is generated:
>
>
> error:
> (during compile-time-too processing)
> USE-PACKAGE #<PACKAGE "CL-EXTRA"> causes name-conflicts in #<PACKAGE "FINANCE">
> between the following symbols:
> CL-EXTRA:DATE, FINANCE::DATE
> --> EVAL-WHEN
> ==>
>
>
> I miss the old behavior - particularly as very often the name conflicts
> are caused by including a package I had forgotten, so that one of the
> "packages" is the interned function name which doesn't even exist (i.e.,
> there is no real conflict).
>
> Is this the desired behavior? If so, short of killing the
> *inferior-lisp* instance and restarting the whole thing, how might one
> proceed once a name conflict is encountered. FMAKUNBOUND doesn't fix
> anything.
For the time being, use C-M-x rather than C-c C-c on the DEFPACKAGE
form.
-T.