Issues Connecting to Allegro Images Using SLY

[artforlife]

I have been able to use SLY with Allegro successfully for about a year. However, every now and then, it gets into a state where it does not connect to the image. It will keep polling for a Slynk server without end.

When I run sly-list-connections, I get no entries.

I then proceed to manually create a Slynk server on the running image:

(progn 
    (load "/home/user/asdf.lisp")
    (format t "~% Loaded ASDF")
    (push "/home/user/.emacs.d/elpa/sly-20180708.712/slynk/" asdf:*central-registry*)
    (format t "~% Added SLYNK path to ASDF:*CENTRAL-REGISTRY*")
    (asdf:load-system :slynk)
    (format t "~% Loaded ASDF system")
    (slynk:create-server :port 4007  :dont-close t)
    (format t "~% Created SLYNK server on port 4007")
    (setf slynk:*use-dedicated-output-stream* nil)
    (format t "~% Set *USE-DEDICATED-OUTPUT-STREAM* to NIL")
)

After that, I check for connections again and find that the list is still empty.

I then proceed to manually connect via sly-connect and things work after that. At first glance, there appears to be some issue with SLY's client side when this happens.

[joaotavora]

@artforlife

The most common cause for what you describe is an error loading the Slynk backend. When you are in that "infinite polling" state, you can still buffer switch to the *inferior-lisp* buffer. That buffer probably has clues as to what is happening. So when you get the error, switch to that buffer using C-x b or something like that, and copy the contents of that buffer into this issue. For now, I am marking this irreproducible/question.

PS: I also use SLY with Allegro a lot.

[franzinc]

I haven't been able to get Sly to work at all with Allegro. I'm using 10.1 and the Git (HEAD on master) version. I see the CL-USER> prompt and whatever I type to it, the entire emacs just hangs. I'm using 26.1 on CentoS 7.x. C-g does stop whatever it's doing. I set debug-on-quit to t and this is what I got:

Debugger entered--Lisp error: (quit)
  accept-process-output(#<process sly-pty-1-1>)
  comint-send-input()
  (let ((G139 (marker-position (sly-mrepl--mark))) (inhibit-read-only t)) (comint-send-input) (add-text-properties G139 (sly-mrepl--mark) (append '(read-only t front-sticky (read-only)) (list 'field 'sly-mrepl-input 'keymap (let ((map (make-sparse-keymap))) (define-key map (kbd "RET") 'sly-mrepl-insert-input) (define-key map [return] 'sly-mrepl-insert-input) (define-key map [mouse-2] 'sly-mrepl-insert-input) map)))))
  sly-mrepl--send-input-sexp()
  (cond ((and (not sly-mrepl--read-mode) (sly-mrepl--busy-p)) (sly-message "REPL is busy")) ((and (not sly-mrepl--read-mode) (or (sly-input-complete-p (sly-mrepl--mark) (point-max)) end-of-input)) (sly-mrepl--send-input-sexp) (sly-mrepl--catch-up)) (sly-mrepl--read-mode (if end-of-input nil (goto-char (point-max)) (newline)) (let ((comint-input-filter (function (lambda (_s) nil)))) (comint-send-input 'no-newline))) (t (newline-and-indent) (sly-message "Input not complete")))
  sly-mrepl-return(nil)
  funcall-interactively(sly-mrepl-return nil)
  call-interactively(sly-mrepl-return nil nil)
  command-execute(sly-mrepl-return)

I'm using alisp, but the behavior was the same with mlisp. Here's what's in the *Messages* buffer:

...
[sly] SLIME detected in `lisp-mode-hook', which causes keybinding conflicts.
Remove it for this Emacs session? (y or n) y
...
For information about GNU Emacs and the GNU system, type C-x h C-a.
[sly] Polling "/net/gremlin/home/layer/tmp/sly.14818" .. 1 (Abort with `M-x sly-abort-connection'.)
[sly] Polling "/net/gremlin/home/layer/tmp/sly.14818" .. 2 (Abort with `M-x sly-abort-connection'.)
[sly] Polling "/net/gremlin/home/layer/tmp/sly.14818" .. 3 (Abort with `M-x sly-abort-connection'.)
[sly] Polling "/net/gremlin/home/layer/tmp/sly.14818" .. 4 (Abort with `M-x sly-abort-connection'.)
[sly] Connecting to Slynk on port 33193..
[sly] Connected. Lemonodor-fame is but a hack away!
Quit [6 times]

Btw, SLIME was not loaded into this image, but I had previously done M-x package-install RET slime RET... so maybe that's why I get that lisp-mode-hook warning?

[joaotavora]

Hi @franzinc , and sorry for the very late reply:

I can't reproduce this behaviour. To weed out potential interference from programs other than SLY, Emacs and Allegro try this from a Console:

$ /path/to/emacs-26.1/emacs -Q -L /path/to/sly -l sly-autoloads \
--eval '(setq inferior-lisp-program "path-to-allegro/alisp")' -f sly

Notice the -Q flag passed to Emacs. Here's what I get:

Unfortunately I don't have an mlisp to experiment with ;-), at least not on Linux.

I use a commercial Allegro 10.1 at work, but on Windows.

Btw, SLIME was not loaded into this image, but I had previously done M-x package-install RET slime RET... so maybe that's why I get that lisp-mode-hook warning?

Probably. If SLIME was compiled in that Emacs instance, a lot of it will already exist in memory, if not all of it. If you didn't, I wouldn't be suprised it SLIME autoloads something into lisp-mode-hook.

[dieggsy]

I saw similar behavior and @joaotavora's suggestion of looking at the inferior lisp buffer solved the issue for me - it turns out I didn't have package-local-nicknames or something like that in my Allegro image, running an ./update.sh -u to download and install patches seemed to fix this.