Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Luke Crook <luke@ba...> - 2008-11-07 19:14:27
I'm not sure if the following is a SLIME or SBCL issue.
- SBCL 1.0.22 win32
- Latest SLIME from CVS
Previously, REQUIRE'ing a package that does not exist, for example
(REQUIRE 'WH00T), would result in an error. Choosing 'q' or '3' would
return control to the *slime-repl sbcl* EMACS window.
The latest version of SBCL does not return control to the REPL. It just
sits there pipelining subsequent evals.
From: Luke Crook <luke@ba...> - 2008-12-23 01:05:11
Luke Crook <luke <at> balooga.com> writes:
> I'm not sure if the following is a SLIME or SBCL issue.
> The latest version of SBCL does not return control to the REPL. It just
> sits there pipelining subsequent evals.
A slightly simpler test case:
Using the latest SLIME from CVS and the latest binary release of SBCL for win32
At the SLIME REPL, evaluate anything that causes a restart; for example;
The variable NOT-WORKING is unbound.
[Condition of type UNBOUND-VARIABLE]
0: [RETRY] Retry SLIME REPL evaluation request.
1: [ABORT] Return to SLIME's top level.
2: [CLOSE-CONNECTION] Close SLIME connection
3: [ABORT] Exit debugger, returning to top level.
0: (SB-INT:SIMPLE-EVAL-IN-LEXENV NOT-WORKING #<NULL-LEXENV>)
Entering :c 3 removes the restart, but does not return to the REPL. Attempting
to evaluate anything results in pipelined requests. The only way out is to kill
sbcl, close SLIME and start again.