opengl under SLIME on MacOS crashing SBCL... bug?
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 Mx slime (and wait for it to load), followed by Cc Cc to compile and run that line, SBCL crashes immediately, every time, prompting a dialog box that says 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: sbcl@1.1.10_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 Mx version, or the emacs-app@24.3_1 port)
Slime: slime@20130630 from MacPorts
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.
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.
链接地址: http://www.djcxy.com/p/67614.html上一篇: JS设置失败连接拒绝等