Notice: slime-v2.28 is not compatible and causes slimv to appear to hang after trying to print a string

[Jach]

This issue is primarily a heads up for other users who may also accidentally encounter the same problem, I haven't fully dug into things to determine a cause or better workaround other than downgrading / making sure slime v2.26 or v2.27 is loaded instead.

For a while I've had a quickload of clouseau (graphical inspector) in my .sbclrc file, this had a side effect of loading many other systems before slimv's version of slime (2.26) that also made it load 2.27 first. This seemed to be ok, but after a QL dist upgrade to 2023-02-15, it now pulls in slime v2.28, and this leads to broken behavior with slimv.

This can be fixed by either downgrading QL to the last dist before slime's v2.28 release (january 2023), which was November 2022: (ql-dist:install-dist "http://beta.quicklisp.org/dist/quicklisp/2022-11-07/distinfo.txt" :replace t) Or just make sure slimv's version of slime is loaded first by not having something in the .sbclrc file that would bring in QL's newer version first.

What's weird is that the issue only seems to happen if something tries to print character output. So if you evaluate (+ 3 3) it will correctly return 6 and start a new prompt, but if you try (format t "~a~%" (+ 3 3)) then slimv's REPL buffer appears to hang. The output from swank.log in the working case is:

(:emacs-rex (swank-repl:listener-eval "(+ 3 3)
") "COMMON-LISP-USER" :repl-thread 6)

[-Received-] 427176.741738144
(:write-string "6
" :repl-result)
[-Received-] 427176.741845435
(:return (:ok nil) 6)
[Actionlist] 427176.741914724
6: finished :listener-eval 
params: nil

The output in the broken case is:

(:emacs-rex (swank-repl:listener-eval "(format t \"~a~%\" (+ 3 3))
") "COMMON-LISP-USER" :repl-thread 11)

[-Received-] 427466.623676079
(:write-string "6
" nil 1)

For comparison, the output in the second case after going back to an older slime is:

(:emacs-rex (swank-repl:listener-eval "(format t \"~a~%\" (+ 3 3))
") "COMMON-LISP-USER" :repl-thread 12)

[-Received-] 6758790.450554193
(:write-string "6
")
[-Received-] 6758790.450903848
(:write-string "NIL
" :repl-result)
[-Received-] 6758790.451177118
(:return (:ok nil) 12)
[Actionlist] 6758790.451413256
12: finished :listener-eval 
params: nil

(This also happens when trying to e.g. quickload something, which is where I first encountered the problem, because of its text output.) I'm speculating that slime might have changed how they send :write-string results, but again haven't yet looked to see what's going on.

[kovisoft]

Thank you for your detailed bug report. I narrowed down the issue to this change in slime: slime/slime@78ad57b
It seems that they modified the :write-string logic in slime so that it now requires a :write-done message after each (?) :write-string.
I'll check how can I update slimv accordingly.

[kovisoft]

I made a fix in commit 55d1355
Please check it.

Later on I'm going to refresh the swank embedded in slimv to version 2.28.

[Jach]

Thanks for such a fast resolution, I can confirm that it no longer hangs. There are now noticeable delays in output (presumably from having to do the message sends?) so that I'll keep my older slime loaded first for now, but that's better than breaking. (In particular there's a delay before the final NIL in a format, but also before the package return from quickload. There's also a significant delay if quicklisp has to download something first, as there's quite a bit of output and its "progress bar" of equal signs becomes choppy.)

[kovisoft]

Yeah, I have also noticed this delay. And there seems to be another issue, at least on my system. If I evaluate this s-expression, then it prints much more numbers than expected:

(dotimes (g 10)
  (print g)
  (sleep 1.0))

I'm a little bit clueless, because in emacs it works as intended: sending a :write-string for each number after getting the :write-done (0 1 2 3 4 ...). However in vim it keeps sending the partial list of numbers from 0 to N upon getting the :write-done (0 0 1 0 1 2 0 1 2 3 0 1 2 3 4 ...).

Could you please check it on your system with the newest swank version (if you still have it)?

[Jach]

Here's what I'm seeing (changing the print to prin1): 000101012012012301230123401234012345012345012345601234560123456701234567012345678012345678012345678901234567890123456789
Additionally I'm able to trigger different output if I go back to insert mode before it's done printing and do something like pressing space to show the arguments for a function or tab-completing a symbol.

[kovisoft]

I tested the code snippet with swank versions 2.28, 2.29, 2.29.1, 2.30, 2.31, and it seems that the randomly duplicated output issue was a problem in swank, and it is solved since v2.30.