[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.
[Condition of type SB-THREAD:INTERRUPT-THREAD-ERROR]
Restarts:
0: [ABORT] Abort thread (#<THREAD "Swank Sentinel" RUNNING {10033EB2C3}>)
Backtrace:
0: (SB-THREAD:INTERRUPT-THREAD #<SB-THREAD:THREAD "Swank 44076"
FINISHED values: NIL {10033EB6A3}> #<FUNCTION (LAMBDA NIL :IN
SB-THREAD:TERMINATE-THREAD) {1001C9062B}>)
1: (SWANK::SENTINEL-SERVE (:STOP-SERVER :SOCKET
#<SB-BSD-SOCKETS:INET-SOCKET fd: -1 {100331FBD3}>))
2: (SWANK::SENTINEL)
3: ((FLET #:WITHOUT-INTERRUPTS-BODY-1226 :IN
SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE))
4: ((FLET SB-THREAD::WITH-MUTEX-THUNK :IN
SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE))
5: ((FLET #:WITHOUT-INTERRUPTS-BODY-660 :IN SB-THREAD::CALL-WITH-MUTEX))
6: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET
SB-THREAD::WITH-MUTEX-THUNK :IN
SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE) {7FFFF675EC2B}>
#<SB-THREAD:MUTEX "thread result lock" owner: #<SB-THREAD:THR..
7: (SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE #<SB-THREAD:THREAD
"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,
https://travis-ci.org/slime/slime
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