From: Tamas K P. <tk...@gm...> - 2010-04-05 10:45:26
|
Hi, Since about a few months ago, I lost the ability to resolve name conflicts in SBCL (running within SLIME). SLIME used to offer a couple of restarts, but it no longer does, I just get the errors. Is this a known bug, or an error in my setup? I am using SBCL 1.0.37 and the latest SLIME from CVS. Thanks, Tamas |
From: Stas B. <sta...@gm...> - 2010-04-05 10:48:39
|
Tamas K Papp <tk...@gm...> writes: > Hi, > > Since about a few months ago, I lost the ability to resolve name > conflicts in SBCL (running within SLIME). SLIME used to offer a > couple of restarts, but it no longer does, I just get the errors. > > Is this a known bug, or an error in my setup? I am using SBCL 1.0.37 > and the latest SLIME from CVS. > https://bugs.launchpad.net/bugs/511072 -- With Best Regards, Stas. |
From: Tamas K P. <tk...@gm...> - 2010-04-05 10:55:33
|
On Mon, 05 Apr 2010 14:48:30 +0400, Stas Boukarev wrote: > Tamas K Papp <tk...@gm...> writes: > >> Hi, >> >> Since about a few months ago, I lost the ability to resolve name >> conflicts in SBCL (running within SLIME). SLIME used to offer a couple >> of restarts, but it no longer does, I just get the errors. >> >> Is this a known bug, or an error in my setup? I am using SBCL 1.0.37 >> and the latest SLIME from CVS. >> > https://bugs.launchpad.net/bugs/511072 Thanks. Is there a workaround (no matter how ugly?). I just need it for the following case: I develop some functions/macros in package A that I am currently working in. When I decide that the solution is more general, I move them to package B, which is loaded by A. Then I get a conflict. Tamas |
From: <m_m...@ya...> - 2010-04-05 12:38:12
|
Tamas K Papp <tk...@gm...> writes: > Thanks. Is there a workaround (no matter how ugly?). I just need it > for the following case: I develop some functions/macros in package A > that I am currently working in. When I decide that the solution is > more general, I move them to package B, which is loaded by A. Then I > get a conflict. Same here, and I would guess everywhere. The ugly workaround is to unintern the symbol from the target package, and retry. Or downgrade sbcl. Regards, Mario. |