cl-opengl under SLIME on MacOS crashing SBCL… bug?

8
votes

I'd like to do some OpenGL programming in Common Lisp, under Emacs and SLIME. I'm not set on it, but I'm currently trying to use SBCL. If I open up emacs from the start, create a new file with just this one line:

(ql:quickload :cl-opengl)

And then I do M-x slime (and wait for it to load), followed by C-c C-c to compile and run that line, SBCL crashes immediately, every time, prompting a dialog box that says sbcl quit unexpectedly:

error dialog: sbcl quit unexpectedly

I've saved the output that's accessible by clicking the "Report..." button; if that's useful, I can add that here (or put it on pastebin or something)... the short version is it's getting a SIGTRAP.

This happens every time I try to run this under SLIME... but, interestingly, it doesn't happen if I run SBCL from the command-line.

So, the question: Is this a bug in SBCL? In cl-opengl? Something I have mis-configured? Other? Any insights would be greatly appreciated.

Note:

I've done some google searching, and I found a page which provides a workaround of putting the following in ~/.swank.lisp:

(setf swank:*communication-style* :fd-handler)

Indeed, that gets me past the immediate crash, and gets me able to do some work. If that's simply the answer, someone please post it as an answer with an explanation of why that's the thing to do, so that others may find it. Otherwise, I'm imagining this to be a bug, though, that could be fixed, rather than worked around... and/or at least something that I could be helped to better understand; I still don't have a responsive REPL with my current code (basically on brian's brain, as a test case) running (via run), which may or may not be a separate question? Did changing the swank config change that situation for me?

Platform details:

OS: MacOS 10.6.8

SBCL: [email protected]_0+fancy from MacPorts; launch header This is SBCL 1.1.10, an implementation of ANSI Common Lisp.

Emacs: macports-installed Emacs Version 24.3 (9.0) (per the GUI about window, or GNU Emacs 24.3.1 (x86_64-apple-darwin10.8.0, NS apple-appkit-1038.36) of 2013-04-07 per M-x version, or the [email protected]_1 port)

Slime: slime@20130630 from MacPorts

2
openglcommon-lispsbclslime
Good question, well written. Typically it might be best to use the SBCL mailing list or the CL-OPENGL mailing list for it. An alternative might be to try Clozure CL. – Rainer Joswig
Thank you, @Rainer. If I don't get an answer here, I'll try that... and if I do get an answer elsewhere, I'll share the meat of it here. – lindes

2 Answers

0
votes

It sounds like a thread support issue with SWANK

The :fd-handler option changes the way SWANK communicates from the default, which is to use separate threads for communication, to using a loop approach (http://www.common-lisp.net/projects/slime/doc/html/Communication-style.html).

There used to be quite a few complaints about using SBCL with threading on Mac OS, these were largely fixed from the look of it; maybe SWANK is having similar issues?

I'm not 100% sure this is the sole cause of your problems, but it's the best explanation I could find.

0
votes

I have been looking through my setup to see what was different

OS X 10.9
SBCL 1.1.8.0-19cda10
slime-20131003

But the most likely offender is still slime/swank. I really recommend using quicklisp to manage your slime setup rather than macports, this will keep both slime and swank in sync and up to date. I've been using slime this way for a year or two and have had no issues so far.

From the quicklisp page:

To install and configure SLIME, use:

(ql:quickload "quicklisp-slime-helper")

Then follow the directions it displays. quicklisp-slime-helper will create a file you can load in Emacs that configures the right load-path for loading Quicklisp's installation of SLIME

I also made a small video showing how to install emacs+sbcl+quicklisp+slime under windows. The slime part is still relevant on all platforms.

Hope it helps.