search

joaotavora / sly

Sylvester the Cat's Common Lisp IDE
1.23k stars 139 forks source link

SLY doesn't notice when SBCL fails into ldb #578

Open rpgoldman opened 1 year ago

rpgoldman commented 1 year ago

The MREPL buffer does not get updated to reflect the fact that SBCL has crashed into the ldb. The MREPL buffer isn't updated, possibly because the inferior lisp process is still running.

This isn't meant to be a complaint and request for fix: I'm just recording this, so that someone who is interested (possibly future me) might take it up and provide a fix.

AkashaP commented 1 year ago

Echoing this. One possible effect of this is if SBCL runs out of heap space. Perhaps it's explicitly that through a CFFI Malloc or something, but in my instance i did not receive a db buffer like i normally would.

joaotavora commented 1 year ago

In your opinions, how could SLY notice? Is there a condition signalled? If so, from what thread? Can we even do that after (or rather -- shortly before -- a drop to ldb? SLY relies on Slynk, and Slynk is written in 100% (maybe that's 99.9%) portable CL To interface with non-portable things, Slynk relies on slynk-backend.lisp. So the way to "fix" this, IMO, is for someone to design an interface SLYNK-BACKEND:MORIBUND or something like that that gives SLY a change to notice it. Else it just thinks that the inferior process is alive and well and the network connection is taking a long time to reply back. But according to Emacs's OS process-checking primitives, both things are alive and well and there's nothing to be worried about.

joaotavora commented 1 year ago

someone to design an interface SLYNK-BACKEND:MORIBUND or something like that that gives SLY a change to notice it.

Sorry, I didn't expand on this idea. That interface existing, someone has to provide at least one implementation for it, in this case SBCL's