Re: I think I need a little help

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