On 05/23/2014 03:06 AM, João Távora wrote:
Paul Bowyer pbowyer@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.