17:33 <vms14> can someone tell me why sometimes slime fails to give me the slime-repl and gets stuck with the inferior lisp repl?

17:33 <vms14> it's like is expecting a response from sbcl but does never receive it

17:33 <vms14> I remember something like pipelined something swank eval

17:34 <vms14> this happens only in NetBSD or sometimes fails in linux or alike?

17:35 <vms14> when it fails I just use swank with sbcl, type slime-connect in emacs and it works fine

17:37 <vms14> it happens sometimes, but I don't know the cause

17:37 <vms14> GNU Emacs 26.2

17:39 <vms14> SLIME 2.24

17:40 <vms14> (setq inferior-lisp-program "/usr/pkg/bin/sbcl")

17:40 <vms14> (require 'slime-autoloads)

17:40 <vms14> (setq slime-contribs '(slime-fancy))

21:41 <vms14> https://i.ibb.co/fD7051p/f35a801fef2f.png

21:41 <vms14> this is what I get

21:42 <vms14> isn't able to give me the slime repl, only the inferior one

21:43 <vms14> why is happening?

21:48 <luis> vms14: did you (setq slime-contribs '(slime-fancy))?

21:48 <vms14> luis yes

21:48 <vms14> I have running it sometimes

21:49 <vms14> sometimes I just type M-x slime and works

21:49 <vms14> but others fail so I need to start sbcl and load swank, then type slime-connect

21:51 <vms14> I'm curious about why it happens, and it seems to be an unknown bug for users, so idk if it's related with NetBSD, a bug that only happens here for some reason, or other users had this problem

21:51 <vms14> note in netbsd sbcl has no thread support

21:51 <vms14> so could be the reason it fails

21:51 <vms14> but sometimes work, so idk

21:54 <luis> vms14: at the beginning of the *inferior-lisp* buffer, you can see the commands that should have triggered the connection to Emacs/SLIME

21:54 <luis> vms14: perhaps if you sprinkle some print debugging it'll yield some sort of clue

21:55 <vms14> I'll try to invest

21:55 <vms14> it fails at random, now I try to reproduce the bug by typing M-x slime and worked

21:57 <luis> vms14: the non-sb-threads paths are most likely poorly tested :(

21:58 <vms14> I'd like to have thread support in sbcl with netbsd

22:02 <luis> vms14: out of curiosity, you could try to add (setq swank:*communication-style* nil) to your ~/.swank.lisp

22:02 <vms14> luis what will do?

22:04 <vms14> I've put it in the .emacs.el, I see no difference, slime started normally

22:05 <luis> vms14: it doesn't do anything in .emacs.el since it's common lisp code.

22:05 <vms14> oh lo

22:05 <vms14> lol

22:05 <vms14> xD

22:06 <vms14> it compiled something

22:06 <luis> vms14: it enables a simpler communication style which won't let you evaluate SLIME requests while another event is being processed and things like that, but if it launches reliably it might be an indication that SLIME's fd-handler code is at fault or your SBCL's fd-handler support is at fault.

22:07 <luis> After you add that to ~/.swank.lisp, you need to start SLIME again.

22:07 <vms14> luis I did

22:07 <vms14> I added that in the emacs.d/elpa/slime-2.24/swank.lisp

22:08 <vms14> started emacs and slime and saw some compilation stuff I've never seen before, so it did something

22:08 <luis> ~/.swank.lisp would have been better.

22:08 <vms14> /home/vms/.slime/fasl/2.24/sbcl-1.4.3-no-threads-unix-x86-64/contrib/swank-hyperdoc.fasl written

22:08 <vms14> and so on

22:09 <vms14> so this will prevent the bug?

22:09 <luis> No, it just might give us a clue whether the bug is specific to the :fd-handler communication-style

22:10 <luis> Well, it might prevent the bug, I don't know. :-)

22:11 <luis> I'm off to bed. Long day. 👋

22:11 <vms14> slime works with this, since it's a bug that happens at random I'll let this on the swank.lisp file

22:11 <vms14> thanks luis gn

22:12 <luis> vms14: like I said, it's best to add that bit to ~/.swank.lisp (/home/vms/.swank.lisp). Next time you update SLIME, that local change you made to slime-2.24/swank.lisp will go away.

22:12 <vms14> thanks for the hint