[STUMP] Swank not working in stumpwm with sbcl 1.0.31 on Arch linux

[Lionel Flandrin]

Hello stumpers,

I'm trying to get swank to work again with stumpwm. It worked fine a
couple of months ago, but now it fails.

If I start a simple SBCL REPL it works:

,----
| This is SBCL 1.0.31, an implementation of ANSI Common Lisp.
| More information about SBCL is available at <http://www.sbcl.org/>.
| 
| SBCL is free software, provided as is, with absolutely no warranty.
| It is mostly in the public domain; some portions are provided under
| BSD-style licenses.  See the CREDITS and COPYING files in the
| distribution for more information.
| * (load "/usr/share/emacs/site-lisp/slime/swank-loader.lisp")
| 
| T
| * (swank-loader:init)
| 
| ; loading 
#P"/home/simias/.slime/fasl/2009-09-18/sbcl-1.0.31-linux-x86-64/swank-backend.fasl"
| ; loading 
#P"/home/simias/.slime/fasl/2009-09-18/sbcl-1.0.31-linux-x86-64/swank-source-path-parser.fasl"
| ; loading 
#P"/home/simias/.slime/fasl/2009-09-18/sbcl-1.0.31-linux-x86-64/swank-source-file-cache.fasl"
| ; loading 
#P"/home/simias/.slime/fasl/2009-09-18/sbcl-1.0.31-linux-x86-64/swank-sbcl.fasl"
| STYLE-WARNING: redefining EMACS-INSPECT (#<BUILT-IN-CLASS T>) in DEFMETHOD
| ; loading 
#P"/home/simias/.slime/fasl/2009-09-18/sbcl-1.0.31-linux-x86-64/swank-gray.fasl"
| STYLE-WARNING:
|    Implicitly creating new generic function STREAM-READ-CHAR-WILL-HANG-P.
| ; loading 
#P"/home/simias/.slime/fasl/2009-09-18/sbcl-1.0.31-linux-x86-64/swank.fasl"
| WARNING: These Swank interfaces are unimplemented:
|  (CALLS-WHO DISASSEMBLE-FRAME SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN
|   WHO-SPECIALIZES)
| NIL
| * (swank:create-server :dont-close t)
| ;; Swank started at port: 4005.
| 
| 4005
| * 
`----

If I do the same thing from within stumpwm (for instance in C-t :) the
(swank-loader:init) fails:

,----
| No restart ABORT is active.0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) 
{100448CCA9}>)[:EXTERNAL]
| 1: (SB-DEBUG:BACKTRACE 100 #<SB-IMPL::STRING-OUTPUT-STREAM {100448CC01}>)
| 2: (BACKTRACE-STRING)
| 3: (ERR "~A")[:EXTERNAL]
| 4: (EVAL-LINE "(swank-loader:init)")
| 5: (CALL-INTERACTIVELY "eval" #S(ARGUMENT-LINE :STRING "eval" :START 5))
| 6: (EVAL-COMMAND "eval" T)
| 7: ((LABELS #:G300) :CODE 45 :STATE 4)
| 8: (HANDLE-EVENT)[:EXTERNAL]
| 9: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK))
| 10: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]291))
| 11: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK
|      #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK) {7FFFF51A2AB9}>
|      #S(SB-THREAD:MUTEX
|         :NAME "CLX Event Lock"
|         :%OWNER #<SB-THREAD:THREAD "initial thread" RUNNING {1003989011}>
|         :STATE 1))
| 12: (XLIB:PROCESS-EVENT #<XLIB:DISPLAY :0 (The X.Org Foundation 
R10701000)>)[:EXTERNAL]
| 13: (STUMPWM-INTERNAL-LOOP)
| 14: (STUMPWM-INTERNAL ":0.0")
| 15: (STUMPWM ":0.0")
| 16: ((LAMBDA ()))
| 17: ((LABELS SB-IMPL::RESTART-LISP))
`----

As Adlai (who as the same problem) pointed out on IRC, it seems
stumpwm should implement an "abort" restart in its main loop. It's not
mandatory, but it's encouraged:

,--[ http://www.lispworks.com/documentation/HyperSpec/Body/r_abort.htm ]
| Implementors are encouraged to make sure that there is always a
| restart named abort around any user code so that user code can call
| abort at any time and expect something reasonable to happen
`----

Anyway, that's a minor issue and it doesn't explain why swank doesn't
start properly in stumpwm. If I start stumpwm with (require 'stumpwm)
(stumpwm:stumpwm) from the swank session in the SBCL REPL it works.

Any clue on how to debug this? I'm running latest stumpwm from git
and sbcl 1.0.31 from the Arch package.

-- 
Lionel Flandrin