I'm currently using SLIME & SBCL (SBCL 1.0.50.24.mswinmt.876-cad5ed2 -- Kovalenko's Windows port). When I hit C-c C-c to interrupt, my Lisp dies and I have to kill Slime and restart. Am I doing something wrong, or is interrupt just not supported on SBCL?
Thanks in advance for any help!
-- Scott Turner
Scott Turner srt19170@gmail.com writes:
I'm currently using SLIME & SBCL (SBCL 1.0.50.24.mswinmt.876-cad5ed2 -- Kovalenko's Windows port). When I hit C-c C-c to interrupt, my Lisp dies and I have to kill Slime and restart. Am I doing something wrong, or is interrupt just not supported on SBCL?
Ensure you use the :spawn communication style -- e.g. by loading swank and setting swank:*communication-style* to :spawn in your .sbclrc. (The real culprit is (slime-use-sigint-for-interrupt) in SLIME).
Interrupts in general are supported; when swank is using multiple threads (with :spawn style), C-c C-c from Emacs will be handled by the control thread, which will interrupt the REPL thread.
Control-C handler for raw REPL is not installed: though it's possible, I have some semantic difficulties about what it should do. There was once a discussion here -- you may look it up if interested.
As of what stands for "SIGINT" in Emacs for Windows, I didn't look into it, but it's either a GenerateConsoleCtrlEvent (thing like raw Control-C), or maybe even something more harsh like TerminateProcess. Thus you really need a :SPAWN style for swank to make interrupts work.
I'm just using reasonably recent SLIME and SBCL. Ctrl+c doesn't work. I can only use SBCL for limited trying out things, not for most of my development. Is there no way to get this just to be the default in the regular version of SBCL, and with default SLIME settings? Any news on that front?
----- Original message ----- From: "Anton Kovalenko" anton@sw4me.com To: slime-devel@common-lisp.net Date: Mon, 22 Aug 2011 21:06:00 +0400 Subject: Re: [slime-devel] Question about Slime & SBCL on Windows
Scott Turner srt19170@gmail.com writes:
I'm currently using SLIME & SBCL (SBCL 1.0.50.24.mswinmt.876-cad5ed2 -- Kovalenko's Windows port). When I hit C-c C-c to interrupt, my Lisp dies and I have to kill Slime and restart. Am I doing something wrong, or is interrupt just not supported on SBCL?
Ensure you use the :spawn communication style -- e.g. by loading swank and setting swank:*communication-style* to :spawn in your .sbclrc. (The real culprit is (slime-use-sigint-for-interrupt) in SLIME).
Interrupts in general are supported; when swank is using multiple threads (with :spawn style), C-c C-c from Emacs will be handled by the control thread, which will interrupt the REPL thread.
Control-C handler for raw REPL is not installed: though it's possible, I have some semantic difficulties about what it should do. There was once a discussion here -- you may look it up if interested.
As of what stands for "SIGINT" in Emacs for Windows, I didn't look into it, but it's either a GenerateConsoleCtrlEvent (thing like raw Control-C), or maybe even something more harsh like TerminateProcess. Thus you really need a :SPAWN style for swank to make interrupts work.
"Mark H. David" mhd@yv.org writes:
I'm just using reasonably recent SLIME and SBCL. Ctrl+c doesn't work. I can only use SBCL for limited trying out things, not for most of my development. Is there no way to get this just to be the default in the regular version of SBCL, and with default SLIME settings? Any news on that front?
For now, C-c C-c for SLIME+SBCL is supposed to work in all configurations where it can work at all. It means any threaded SBCL, and non-threaded SBCL on Unix-like systems.
Regular (i.e. nonpatched, mainline) SBCL *on Windows* doesn't support C-c C-c, because it has neither threads nor interrupts (mine has both, making it possible to use C-c in raw REPL, and in SLIME for non-:spawn communication mode when SBCL is started from emacs, as opposed to slime-connect'ing to an independent SBCL process).
It would be useful to know your OS, platform and SBCL version in order to give some relevant answer at first attempt. I've concentrated on Windows in my answer because it's hard to believe that such a failure is possible with current SBCL+Slime on Linux, and other platforms' users don't forget to name their OS when reporting a problem.
Thanks, I'm on Windows (both W7 and WinXP), and SBCL 1.0.51, and not sure what version of SLIME. Pretty recent, I think. Let me know if it matters, and give a simple way to tell. Emacs 23.3.1.
I guess I'd like "your" SBCL to go into the unpatched, mainline SBCL. That's a start. What's the holdup?
Feel free to resend the donation URL? :)
Thanks, Mark
----- Original message ----- From: "Anton Kovalenko" anton@sw4me.com To: slime-devel@common-lisp.net Date: Tue, 29 Nov 2011 01:38:16 +0400 Subject: Re: [slime-devel] Question about Slime & SBCL on Windows
"Mark H. David" mhd@yv.org writes:
I'm just using reasonably recent SLIME and SBCL. Ctrl+c doesn't work. I can only use SBCL for limited trying out things, not for most of my development. Is there no way to get this just to be the default in the regular version of SBCL, and with default SLIME settings? Any news on that front?
For now, C-c C-c for SLIME+SBCL is supposed to work in all configurations where it can work at all. It means any threaded SBCL, and non-threaded SBCL on Unix-like systems.
Regular (i.e. nonpatched, mainline) SBCL *on Windows* doesn't support C-c C-c, because it has neither threads nor interrupts (mine has both, making it possible to use C-c in raw REPL, and in SLIME for non-:spawn communication mode when SBCL is started from emacs, as opposed to slime-connect'ing to an independent SBCL process).
It would be useful to know your OS, platform and SBCL version in order to give some relevant answer at first attempt. I've concentrated on Windows in my answer because it's hard to believe that such a failure is possible with current SBCL+Slime on Linux, and other platforms' users don't forget to name their OS when reporting a problem.
"Mark H. David" mhd@yv.org writes:
Thanks, I'm on Windows (both W7 and WinXP), and SBCL 1.0.51, and not sure what version of SLIME. Pretty recent, I think. Let me know if it matters, and give a simple way to tell. Emacs 23.3.1.
Last update of SLIME that affected C-c C-c in threaded SBCL for Windows happened on 1 Sep 2011; :SPAWN communication style was made the default for any threaded SBCL with no exception for #+win32. That is, any SLIME which deserves the name of pretty recent should already have it.
I guess I'd like "your" SBCL to go into the unpatched, mainline SBCL. That's a start. What's the holdup?
Well, there's just a lot of complicated stuff, which seems like a natural thing to expect after more than a year of development. David Lichteblau is working now on integration of the largest piece of code that can't be committed in pieces without breaking things (that includes thread support, but I'm not sure of interrupts). Some of my patches that don't depend on threading were already integrated by him before SBCL 1.0.52.
Feel free to resend the donation URL? :)
While we are at it, a Very Important donation page at http://www.siftsoft.com/support-sbcl-windows.html now includes a "big picture" of project history, from which you can see that threading and interrupts are only a part of the story. On Windows, SBCL still has a long road ahead, and I don't feel like I'd go much faster with integration if I were in SBCL team and my patch were some other hacker's code.
Also, as long as I merge upstream changes and test them continuously and discuss problems in #sbcl, anything that breaks Windows build in the mainline has a big chance to get noticed and reported at the same day it's committed (last time it was a RUN-PROGRAM issue, when it was refactored in the mainline to distinguish exec() failure from fork()'s).
BTW, Anton if you run a Kickstarter campaign or something to raise money to support your work on the Windows port, I'll be happy to contribute.
-- Scott Turner
Scott Turner srt19170@gmail.com writes:
BTW, Anton if you run a Kickstarter campaign or something to raise money to support your work on the Windows port, I'll be happy to contribute.
Yeah, I know that people have reasons to expect something more than a couple of not-too-frieldly methods for making a donation. Lispers outside of Russia just don't get how it's far from trivial to set up even what I have now.
As an example: until recently, paypal disallowed incoming payments to accounts openened from here; some days ago, literally, it became possible but the only destination for withdrawal of funds is an U.S. bank account (what's ridiculous about it is that it's kind of illegal to have U.S. bank account here if you're both citizen and not a U.S. resident). Receiving a simple wire transfer requires a good amount of paperwork *per each transfer* when it's at all possible. I could go on and on, really, but I'd better not to. WinAPI is a bliss compared to "human interface" of both banking and legal system here.
Specifically, as I can see from http://www.kickstarter.com/help/faq/creating%20a%20project#AmIEligToStarAKickProj, Kickstarter is a nonstarter for me, and the same applies to many other wonderful services. I'm ready to make it all more convenient as soon as I see how it can be done, but the key issue here is probably not my awareness of how fundraising is normally done (well, I know I suck at that, too, it's just our local conditions don't let me show that suckinness freely, yet).
-
Anton Kovalenko -
Mark H. David -
Scott Turner