On 05/21/2014 10:29 AM, João Távora wrote:

Luís Oliveira luismbo@gmail.com writes:

...

On Wed, May 21, 2014 at 2:10 AM, Paul Bowyer pbowyer@olynet.com wrote:

...

I've recently tried to use Emacs 24.1.1 which is available from the repository of Linux Mint and I cannot get slime to run properly with it.

[...]

...

The message I get in the emacs message when I try ALT-x slime window is: define-slime-contrib: Symbol's value as variable is void: --cl---cl-var--11849--

[...]

...

make compile

I think 24.1 has some issues with lexical binding. João suggests a workaround here: https://github.com/slime/slime/issues/122#issuecomment-36518247.

Specifically Paul, you should attempt to *not* byte-compile slime with "make compile" at all, just byte-compile contrib/slime-presentations.el. Here's what that comment contains:

 OK, I've found the solution. You must byte-compile the
 contrib/slime-presentations.el. So to summarize:

 If you're on Emacs 24.1 or Emacs 24.2 and using slime-fancy or
 slime-presentations you must byte-compile just
 contrib/slime-presentations.el via M-x byte-compile-file

...

Alternatively, you could upgrade your Emacs to 24.3 if that's feasible for you.

This is a much preferred alternative. have a look at http://linuxg.net/how-to-install-emacs-24-3-on-ubuntu-13-10-13-04-12-10-12-0...

On Ubuntu 14.04 Emacs 24.3 is the default in the official repositories, think. I believe there must be a Mint version based on 14.04.

João

Hello João,

Thanks for the link showing me how to get emacs 24,3. I followed the instructions and it installed without problems. I was still having the same problem starting slime in it until I disabled the instructions to run the test suite in my install script. Then slime loaded without a hitch the first time.

On subsequent loads, I sometimes get a window in emacs named *sldb nil/1* with: ---------------------------------------------------------------- Interrupt thread failed: thread #<THREAD "Swank 44066" 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 44066" FINISHED values: NIL {10033EB6A3}> #<FUNCTION (LAMBDA NIL :IN SB-THREAD:TERMINATE-THREAD) {1001C9062B}>) ---------------------------------------------------------------- I can select abort and it closes the debug window and leaves the slime repl running. This debug window doesn't always occur. If I wait for awhile before restarting emacs and slime, it sometimes comes up without the debug window. More often than not, the debug window comes up.

In my install script, I just delete the slime folder and then do:

git clone https://github.com/slime/slime.git cd ~/my-slime-sandbox/slime #change to doc folder and make the docs #change back to slime folder #then run make clean check make check-fancy

That way I get the latest slime with the test suite run to check for errors. It's a small download so it doesn't take much time to do it that way.

It seems that "make clean check" and/or "make check-fancy" byte-compile many/all of the files in the contrib folder which causes slime to fail when I do ALT-x slime in emacs. I can add a line in my install script to remove all ".elc" files in the contrib folder...

In looking at the slime Makefile, I noticed that make check does a compile...

Also, the test suite fails with: ----------------------------------------------- In toplevel form: slime-fancy.el:9:24:Error: Symbol's function definition is void: defun* make[1]: *** [slime-fancy.elc] Error 1 make[1]: Leaving directory `/home/pfb/my-slime-sandbox/slime/contrib' make: *** [check-fancy] Error 2 -----------------------------------------------

So it currently does no good to run it from my install script. It would be nice to be able to do that so I can check for errors...

I hope this info helps a little,

Paul Bowyer

On 05/22/2014 02:32 AM, João Távora wrote:

Paul Bowyer pbowyer@olynet.com writes:

...

Hello João,

Thanks for the link showing me how to get emacs 24,3. I followed the instructions and it installed without problems. I was still having the same problem starting slime in it until I disabled the instructions to run the test suite in my install script. Then slime loaded without a hitch the first time.

On subsequent loads, I sometimes get a window in emacs named *sldb nil/1* with:

---

Interrupt thread failed: thread #<THREAD "Swank 44066" 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 44066" FINISHED values: NIL {10033EB6A3}> #<FUNCTION (LAMBDA NIL :IN SB-THREAD:TERMINATE-THREAD) {1001C9062B}>)

---

I can select abort and it closes the debug window and leaves the slime repl running. This debug window doesn't always occur. If I wait for awhile before restarting emacs and slime, it sometimes comes up without the debug window. More often than not, the debug window comes up.

This seems to be unrealated to the .elc compilation problems you report below, but I'll help you fix them anyway because to analyse it I need a more stable error recipe.

...

In my install script, I just delete the slime folder and then do:

git clone https://github.com/slime/slime.git cd ~/my-slime-sandbox/slime #change to doc folder and make the docs #change back to slime folder #then run make clean check make check-fancy

Unfortunately, I think that due to missing compilation dependencies, you should run "make clean check-fancy" and then "make check". That will compile the files in the correct order.

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. However I still get the emacs debug window that I have to abort out of. 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.

This need for ordering is a indeed a bug, probably introduced by me, specifically

 make clean compile contrib-compile FAILS
 make clean contrib-compile compile PASSES

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.

Thanks again for your help,

Paul Bowyer

If you use the workaround or wait until the bug is fixed your "install script", and a good reproduction recipe, for bugs should be something like

 git pull
 make clean contrib-compile compile
 # make check check-fancy
 emacs -Q -L . -l slime-autoloads.el                            \
            --eval "(setq inferior-lisp-program \"sbcl\")"      \
            --eval "(add-to-list 'slime-contribs 'slime-fancy)"
 M-x slime

works nicely for me!

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.