[Slime-devel] I think I need a little help

Paul Bowyer pbowyer at olynet.com
Fri May 23 23:17:29 UTC 2014

On 05/23/2014 03:06 AM, João Távora wrote:
> Paul Bowyer <pbowyer at olynet.com> writes:
>> I corrected my install script to use the suggested ordering and the
>> test suite completes successfully
>> with the one expected failure. I have a separate test script for use
>> with CCL and it also completes succesfully with one expected
>> failure. I am able to start slime without removing any ".elc" files in
>> slime/contrib, which I could not do before.
> OK great, this is the same behaviour I observe.
>> However I still get the emacs debug window that I have to abort out
>> of.
> This I don't see. I need a recipe for reproducing this, so please
> provide start emacs and slime with this recipe and then list all the
> steps that bring you to that "debug window"
>    cd path/to/where/you/cloned/slime
>    emacs -Q -L . -l slime-autoloads.el                            \
>               --eval "(setq inferior-lisp-program \"sbcl\")"      \
>               --eval "(add-to-list 'slime-contribs 'slime-fancy)"
>    < any extra setup >
>    M-x toggle-debug-on-error ; this is useful
>    M-x slime
>    < any extra steps >
I tried this from a Konsole window and it took me 4 tries before the 
debug window showed up. I didn't use any extra steps before or after,
M-x toggle-debug-on-error
M-x slime

Contents of *sldb nil/1* window
Interrupt thread failed: thread #<THREAD "Swank 44076" FINISHED values: 
NIL {10033EB6A3}> has exited.

  0: [ABORT] Abort thread (#<THREAD "Swank Sentinel" RUNNING {10033EB2C3}>)

#<SB-BSD-SOCKETS:INET-SOCKET fd: -1 {100331FBD3}>))
#<SB-THREAD:MUTEX "thread result lock" owner: #<SB-THREAD:THR..
"Swank Sentinel" RUNNING {10033EB2C3}> #S(SB-THREAD:SEMAPHORE :NAME 
"Thread setup semaphore" :%COUNT 0 :WAITCOUNT 0 :MUTEX #<SB-THREAD..
   8: ("foreign function: call_into_lisp")
   9: ("foreign function: new_thread_trampoline")

> Also post the exact versions of sbcl and emacs you are using
>    emacs --version
GNU Emacs 24.3.1
Installed from the link you provided,


I removed all of the emacs packages that were previously installed from 
the repositories before installing emacs 24.3.1.
> and
>    sbcl --version
SBCL 1.1.18
I built this from source using the packaged binary of the same version, 
but the build completed without errors and it passed all of the tests 
that I could find to put it through.
I prefer to use sbcl directly from the maintainer because it seems 
generally more current than what is offered in the system repositories 
and I can do the update fairly easily.

I'm running the above software on a Linux Mint 14 64-bit platform that 
uses KDE 4.9.5. The system has been continually kept up to date by 
installing all of the updates that have shown up.
> should give you that. Finally post (I think you already did though)
> relevant message in any *sldb* or *Backtrace* bufers you get.
>> After that I have a slime REPL and I'll do some work to see how it
>> goes. It will probably take me a little time to become accustomed to
>> the ways of emacs 24 though.
> Out of curiosity, what's so different from 23 to 24 for you?
After working with it for a couple of days, I think my original 
perceptions were a bit hasty. I couldn't initially find the proper mouse 
or key combinations to make things happen as I was accustomed, but that 
turns out to be easily overcome with a little learning. I tend not to 
want to do that when I'm in the middle of something, but I have more 
time now and I need to stay current rather than hanging onto old ways.
>>> By the way do you just want the files compiled or do you really need to
>>> know the results of the test suite? Because the results posted by the CI
>>> system might be interesting and they are at
>>> https://travis-ci.org/slime/slime.
>> I looked at the site and it seems a much more elaborate system is used
>> than I have, so I would like to continue with my simple install/test
>> scripts, which I can manage without a lot of effort. I usually only
>> run the slime test suite once upon downloading slime from github.
> The site is just a service for continuious integration that SLIME
> uses. It's just there as a measure of the current git trunk's stability,
> for users to inspect.
I looked at the output of the tests, which looked similar to what I was 
supposed to get.
I just like running my own tests so I can see how things are working on 
my system.
That way when things go awry in my programming attempts (fairly common), 
I don't have to wonder if there is a problem in one of the tools I 
happen to be using.
> You're not really supposed to "use it" in your workflow unless perhaps
> you are developing new features/new tests in your own fork of SLIME.

More information about the slime-devel mailing list