- slime-devel - mailman3.common-lisp.net

Patch
by Douglas Katzman 21 Apr '17

21 Apr '17

Please apply this forward-and-backward-compatible change for SBCL

2 1

SLIME _may_ cause emacs to resize frame involuntarily
by Peter Keller 16 Apr '17

16 Apr '17

Hello, I discovered some odd behavior related to SLIME that I can't figure out. Hopefully, someone here can help me out. In short, starting SLIME with M-x slime or switching to a buffer containing the SLIME repl causes a resize of the emacs frame containing that buffer. The details are at this link (which is also a test config file that you can start emacs with that will hopefully demonstrate the problem): http://paste.lisp.org/display/344012 I'm using stock emacs 25.1, xubuntu 16.04 LTS, SBCL 1.3.12, and SLIME installed from Quicklisp and current as of 2017-04-10. If you store the linked data as a file like /tmp/init-resize.el you can run it as: emacs -q -l /tmp/init-resize.el (provided you have that font it is requesting, which is "DejaVu Sans Mono 9"). Then resize the window manually to 80x24, then M-x slime. If the bug presents itself, the frame will resize after slime is loaded to something other size. I think the resize is erroneous behavior. I provided what would have been the means that I thought would stop the involuntary resize in the init file, but it doesn't seem to work. Thank you! -pete

2 1

Slime inspector customization
by Gitsis Christos 14 Jan '17

14 Jan '17

Hello, Here follows Common Lisp code, using a datastore library named bknr.datastore (ql:quickload :bknr.datastore) (defclass userdata (bknr.datastore:store-object) ((email :initarg :email :index-type bknr.indices:unique-index :index-values all-users) (name :initarg :name)) (:metaclass bknr.datastore:persistent-class)) (let ((object-subsystem (make-instance 'bknr.datastore:store-object-subsystem))) (make-instance 'bknr.datastore:store :directory *default-pathname-defaults* :subsystems (list object-subsystem))) (make-instance 'userdata :email "m(a)b.com" :name "Maria") (make-instance 'userdata :email "k(a)g.com" :name "Katerina") (setf (slot-value (first (all-users)) 'name) "Elena") ; Attempt to modify persistent slot NAME of #<USERDATA ID: 0> outside of a transaction ; [Condition of type BKNR.DATASTORE::PERSISTENT-SLOT-MODIFIED-OUTSIDE-OF-TRANSACTION] (bknr.datastore:with-transaction () (setf (slot-value (first (all-users)) 'name) "Elena")) ; runs successfully, the above wrap in with-transaction () is necessary I use the Slime inspector to view the datastore, so in the minibuffer after C-c C-I Inspect value (evaluated): I input (all-users) I can see the data but not edit it in the slime inspector, because the same condition is thrown as above. Can the slime inspector be customized in a way that it wraps calls to setf inside transactions? PS: if you run the above code, a directory named "current" will be created in your lisp's working directory. It saves the datastore on disk. Thank you, Christos Gitsis

2 1

loading libraries in abcl causes java stack-overflow
by Mirko Vukovic 09 Jan '17

09 Jan '17

Hello, This is on Windows 10 and ABCL 1.4.0. I use the library Vecto as an example. When I start ABCL in a command window, I can load Vecto using asdf or ql. If I do the same from Slime (2.18), I get a java stack overflow: Stack overflow. [Condition of type STORAGE-CONDITION] Restarts: 0: [*ABORT] Return to SLIME's top level. 1: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {3C85E}> #<STORAGE-CONDITION {1B526DF}> #<FUNCTION {3C85E}>) 1: (APPLY #<FUNCTION {3C85E}> (#<STORAGE-CONDITION {1B526DF}> #<FUNCTION {3C85E}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {1B526DF}> #<FUNCTION {3C85E}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {1B526DF}>) 4: org.armedbear.lisp.Lisp.stackError(Lisp.java:388) 5: org.armedbear.lisp.swank_513.execute(swank.lisp:1677) 6: org.armedbear.lisp.LispThread.execute(LispThread.java:851) 7: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2800) 8: (SWANK:EVAL-FOR-EMACS (SWANK-REPL:LISTENER-EVAL "(asdf:load-system :vecto) ") "COMMON-LISP-USER" 35) 9: (APPLY #<EVAL-FOR-EMACS {1EBB63}> ((SWANK-REPL:LISTENER-EVAL "(asdf:load-system :vecto) ") "COMMON-LISP-USER" 35)) 10: (SWANK::PROCESS-REQUESTS NIL) 11: (#<FUNCTION {B14FE}>) 12: (#<FUNCTION {1BEFA9A}>) 13: (FUNCALL #<FUNCTION {1BEFA9A}>) 14: ((FLET SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK) #<SWANK-DEBUGGER-HOOK {1BBCB67}> #<FUNCTION {1BEFA9A}>) 15: (APPLY #<(FLET CALL-WITH-DEBUGGER-HOOK) {136C698}> #<SWANK-DEBUGGER-HOOK {1BBCB67}> #<FUNCTION {1BEFA9A}> NIL) 16: (SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK #<SWANK-DEBUGGER-HOOK {1BBCB67}> #<FUNCTION {1BEFA9A}>) 17: (#<FUNCTION {128469A}>) 18: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-INPUT* . #S(SLIME-INPUT-STREAM)) (*STANDARD-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*TRACE-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*ERROR-OUTPUT* . #S(SLIME-OUTPUT-STREA.. 19: (SWANK::HANDLE-REQUESTS #S(SWANK::MULTITHREADED-CONNECTION :SOCKET #<java.net.ServerSocket ServerSocket[addr=0.0.0.0/0.0.0..... {694679}> :SOCKET-IO #<TWO-WAY-STREAM {191E155}> :DEDICATED-OUTPUT NIL :.. 20: (SWANK-REPL::REPL-LOOP #S(SWANK::MULTITHREADED-CONNECTION :SOCKET #<java.net.ServerSocket ServerSocket[addr=0.0.0.0/0.0.0..... {694679}> :SOCKET-IO #<TWO-WAY-STREAM {191E155}> :DEDICATED-OUTPUT NIL :U.. 21: (#<FUNCTION {138F959}>) 22: (SWANK::CALL-WITH-BINDINGS NIL #<FUNCTION {138F959}>) 23: (#<FUNCTION {17A5212}>) 24: (FUNCALL #<FUNCTION {17A5212}>) 25: (#<FUNCTION (LAMBDA ()) {1A24795}>) 26: (THREADS::THREAD-FUNCTION-WRAPPER #<FUNCTION (LAMBDA ()) {1A24795}>) I have several other issues with ABCL (running from command-line) such as uiop's run-program, loading cffi. I have reported them on the asdf and abcl lists. I am not sure if there is a common thread in all. Mirko

1 0

ABCL startup script gives exec error in slime, but not on command line
by Mirko Vukovic 09 Sep '16

09 Sep '16

Hello, I am trying to get ABCL running under Slime on Linux (RHEL6). I already have it running on Windows 10. I wrote the following script (abcl.sh) to launch it: java \ -cp /usr/local/share/java/abcl.jar \ org.armedbear.lisp.Main The script resides in /usr/local/bin, and it successfully launches ABCL from the command line of system-administrator (who installs the software) and other users. However, in Emacs/slime (latest), I get emacs: /usr/local/bin/abcl.sh: Exec format error Process inferior-lisp exited abnormally with code 126 The definition of abcl resides in local-lisp-implementations: ((abcl ("/usr/local/bin/abcl.sh")) (sbcl ("/usr/local/bin/sbcl"))) Actually there is a symbolic link involved: abcl.sh resides in sys-admins directory, and /usr/local/bin/abcl.sh is a symbolic link to it. I did try pointing to the script itself, both from command line of users and from Emacs. The behavior was the same. To summarize: - a script launches ABCL from command line - Emacs gives an Exec format error - I did test for symbolic link effects and found none Thoughts? Thanks, Mirko

1 1

What port range do I need to open for Swank
by Mirko Vukovic 18 Aug '16

18 Aug '16

Hello, I need to ask my IT department to open ports needed to communicate with SWANK. What is the port range that SWANK uses? Or is it possible to specify a port during slime startup? Thanks, Mirko

3 3

slime-edit-definition doesn't lookup the definition at point
by Chaitanya Gupta 26 Jun '16

26 Jun '16

In my Lisp buffer, when the point is over a symbol and I press M-. (slime-edit-definition), I get the following error: cl-assoc: Symbol's function definition is void: equalp If the point is over some whitespace, then things work as expected: M-. gives me the "Edit Definition of" prompt in the minibuffer and looks up the correct definition. I guess I can define equalp in my .emacs to fix this, but I would prefer if it worked out of the box. I am using GNU Emacs 24.5.1 and SLIME 20160624.851 (installed from melpa). Chaitanya

1 1

Slime: arithmetic error COMMON-LISP:FLOATING-POINT-INVALID-OPERATION signalled
by David Hodge 22 Jun '16

22 Jun '16

Slime Version: 2.18 SBCL Version: 1.3.3 Having recently upgraded SBCL I pulled the latest quicklisp version of slime as well. I now get this error message popping up at random, but frequent intervals. It usually happens as I am typing at the REPL. I wonder if anyone might comment on what is happening - I can accept its my environment, but am at a loss as to how to track it down. Cheers The back trace is provided below: 0: ("bogus stack frame") 1: ("foreign function: maybe_now_maybe_later") 2: ("foreign function: _sigtramp") 3: ("foreign function: #x100B4A3F13") 4: (COMMON-LISP:FIND-SYMBOL "OR" #<COMMON-LISP:PACKAGE "SWANK-IO-PACKAGE">) 5: (SB-IMPL::OUTPUT-SYMBOL COMMON-LISP:OR #<SB-IMPL::STRING-OUTPUT-STREAM {100B4A6943}>) 6: ((COMMON-LISP:LABELS SB-IMPL::HANDLE-IT :IN SB-KERNEL:OUTPUT-OBJECT) #<SB-IMPL::STRING-OUTPUT-STREAM {100B4A6943}>) 7: (SB-IMPL::OUTPUT-LIST (COMMON-LISP:OR (:EMACS-REX . SWANK::_) (:EMACS-CHANNEL-SEND . SWANK::_)) #<SB-IMPL::STRING-OUTPUT-STREAM {100B4A6943}>) 8: ((COMMON-LISP:LABELS SB-IMPL::HANDLE-IT :IN SB-KERNEL:OUTPUT-OBJECT) #<SB-IMPL::STRING-OUTPUT-STREAM {100B4A6943}>) 9: (COMMON-LISP:PRIN1 (COMMON-LISP:OR (:EMACS-REX . SWANK::_) (:EMACS-CHANNEL-SEND . SWANK::_)) #<SB-IMPL::STRING-OUTPUT-STREAM {100B4A6943}>) 10: (SB-FORMAT::S-FORMAT-DIRECTIVE-INTERPRETER #<SB-IMPL::STRING-OUTPUT-STREAM {100B4A6943}> #<~s> (" " #<~s> #<~%>) #<unavailable argument> #<unavailable argument>) 11: (SB-FORMAT::INTERPRET-DIRECTIVE-LIST #<SB-IMPL::STRING-OUTPUT-STREAM {100B4A6943}> (#<~s> " " #<~s> #<~%>) ((COMMON-LISP:OR # #) T) ((COMMON-LISP:OR # #) T)) 12: (SB-FORMAT::%FORMAT #<SB-IMPL::STRING-OUTPUT-STREAM {100B4A6943}> "wait-for-event: ~s ~s~%" ((COMMON-LISP:OR # #) T) ((COMMON-LISP:OR # #) T)) 13: ((COMMON-LISP:LAMBDA NIL :IN SWANK::LOG-EVENT)) 14: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #<CLOSURE (COMMON-LISP:LAMBDA NIL :IN SWANK::LOG-EVENT) {100B4A680B}>) 15: (SWANK/SBCL::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL :IN SWANK::HANDLE-REQUESTS) {100B67322B}>) Locals: CONTINUATION = #<CLOSURE (LAMBDA () :IN SWANK::HANDLE-REQUESTS) {100B67322B}> HOOK = #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> 16: ((FLET SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK :IN "/Users/dbh/quicklisp/dists/quicklisp/software/slime-v2.18/swank/sbcl.lisp") #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL :IN SWANK::HAN.. 17: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-INPUT* . #1=#<SWANK/GRAY::SLIME-INPUT-STREAM {100CFA82E3}>) (*STANDARD-OUTPUT* . #2=#<SWANK/GRAY::SLIME-OUTPUT-STREAM {100D07A0A3}>) (*TRACE-OUTPUT* . #2#) (*ERR.. 18: (SWANK::HANDLE-REQUESTS #<SWANK::SINGLETHREADED-CONNECTION {100C38F373}> T) 19: (SWANK::INVOKE-OR-QUEUE-INTERRUPT #<CLOSURE (LAMBDA NIL :IN SWANK::PROCESS-IO-INTERRUPT) {100B67292B}>) 20: (SWANK::PROCESS-IO-INTERRUPT #<SWANK::SINGLETHREADED-CONNECTION {100C38F373}>) 21: (SWANK/SBCL::SIGIO-HANDLER #<unused argument> #<unused argument> #<unused argument>) 22: ((FLET #:WITHOUT-INTERRUPTS-BODY-44 :IN SB-SYS:INVOKE-INTERRUPTION)) 23: ((FLET SB-THREAD::EXEC :IN SB-SYS:INVOKE-INTERRUPTION)) 24: ((FLET #:WITHOUT-INTERRUPTS-BODY-35 :IN SB-SYS:INVOKE-INTERRUPTION)) 25: (SB-SYS:INVOKE-INTERRUPTION #<CLOSURE (FLET SB-UNIX::INTERRUPTION :IN SB-SYS:ENABLE-INTERRUPT) {A1FEB5B}>) 26: ((FLET SB-UNIX::RUN-HANDLER :IN SB-SYS:ENABLE-INTERRUPT) 23 #.(SB-SYS:INT-SAP #X0A1FF168) #.(SB-SYS:INT-SAP #X0A1FF1D0))

1 0

Playing nice with custom repls?
by Zach Beane 15 Jun '16

15 Jun '16

I like writing specialized little repls sometimes, with syntax optimized for a specific task. When I'm in a repl like that, slime drops many useful features, like M-., arglist display in file buffers, etc. Is there a way to have those features still work even when I'm in my own repl? Thanks, Zach

2 4

Source location improvements for Allegro CL >= 10.0
by Luís Oliveira 12 Jun '16

12 Jun '16

Hello, Allegro CL 10.0 features improved source location information for compiler warnings: whereas previously warnings were associated with the top-level form where they occur, now we can pinpoint the offending subform. I've just pushed some code to the master branch that takes advantage of this enhanced information. (screenshot: http://imgur.com/pe6Bw20) Feedback from Allegro users is welcome! Cheers, Luís

1 0