Hi!
Has anyone else problems with SLIME when using Lispworks on Windows (XP) and its FLI? I've run into a (reproducable but complicated) situation where SLIME simply hung while there were no problems from the LW IDE or from the command line. I'm sitting at my Linux laptop now but I can try to create a simple test case - I just wanted to check if this is a known problem.
Cheers, Edi.
On Sat, 04 Sep 2004 02:18:10 +0200, Edi Weitz edi@agharta.de wrote:
Has anyone else problems with SLIME when using Lispworks on Windows (XP) and its FLI? I've run into a (reproducable but complicated) situation where SLIME simply hung while there were no problems from the LW IDE or from the command line. I'm sitting at my Linux laptop now but I can try to create a simple test case - I just wanted to check if this is a known problem.
OK, it took me a while but here it is... :)
SLIME: From CVS, updated today. OS: Windows XP SP 2. Lisp: Xanalys LispWorks 4.3.7. Emacs: FSF 21.3
Take a /very/ simple C program like this one:
int __declspec(dllexport) foo (int x) { return 2 * x; }
Compile it with VS
cl /LD /Gd /TC test.c /link /OUT:test.dll
or download the DLL from
http://zappa.agharta.de/test.dll.
Now, in the LW IDE:
CL-USER 1 > (fli:define-foreign-function foo ((x :int)) :result-type :int :module "c:/home/test.dll") FOO
CL-USER 2 > (foo 21) 42
No problem, obviously.
If I do the same in SLIME, however, SLIME hangs indefinitely after (FOO 21) and doesn't show the result. The funny thing is that LW is still there. If I now change to the inferior-lisp buffer and evaluate some arbitrary form there then the SLIME REPL buffer suddenly shows the 42 and is alive and well again. Unfortunately, I have /no/ idea what's the cause for this is but it's fully reproducible for me and currently a real show-stopper.
Thanks in advance for your help, Edi.
On Thu, 16 Dec 2004 21:18:05 +0100, Edi Weitz edi@agharta.de wrote:
If I do the same in SLIME, however, SLIME hangs indefinitely after (FOO 21) and doesn't show the result. The funny thing is that LW is still there. If I now change to the inferior-lisp buffer and evaluate some arbitrary form there then the SLIME REPL buffer suddenly shows the 42 and is alive and well again.
I forgot to mention: This happens only once per session. At this point I can now evaluate (FOO 21) from the REPL without problems.
So, nobody has an idea how this can fixed? I'd be willing to work on it but I could need a hint at where to start.
Cheers, Edi.
Edi Weitz edi@agharta.de writes:
So, nobody has an idea how this can fixed? I'd be willing to work on it but I could need a hint at where to start.
Try to set swank:*communication-style* to nil. This style doesn't use threads. Interrupting will not work on Windows, but if the simple ffi call works without threads then we know at least that the bug has something to do with multi-threading.
Helmut.
On 22 Dec 2004 22:01:43 +0100, Helmut Eller e9626484@stud3.tuwien.ac.at wrote:
Try to set swank:*communication-style* to nil. This style doesn't use threads. Interrupting will not work on Windows, but if the simple ffi call works without threads then we know at least that the bug has something to do with multi-threading.
Nope, same behaviour with this style. SLIME hangs after (FOO 21) and responds after I've pressed the RETURN key in the *inferior-lisp* buffer.
Hmmm...
Edi.
I tried to debug this a bit more last night but there's still not much progress. I have some more data points, though:
1. If I start the LispWorks IDE separately, start SWANK from there and then connect to it via slime-connect everything works fine.
2. Instead of using the FLI you can just, from a fresh SLIME session, call (capi:display-message "foo") to hang SLIME. Can be "fixed" by entering a form into the inferior-lisp buffer as well.
3. Contrary to Alain Picard I can't reproduce the same problem on Linux. (Currently my Linux LW is 4.3.7 pro while on Windows I have 4.4.0 pro but I don't believe that makes a difference.)
My current guess is that this is somehow related to comint on Windows and the inferior-lisp buffer which is no-no land to me. I can live with the solution sketched in #1 but I'd still be happy to know what's going wrong.
Cheers, Edi.
On Mon, 21 Mar 2005 17:40:20 +0100, Edi Weitz edi@agharta.de said:
Edi> I tried to debug this a bit more last night but there's still not much Edi> progress. I have some more data points, though:
Edi> 1. If I start the LispWorks IDE separately, start SWANK from there and Edi> then connect to it via slime-connect everything works fine.
Edi> 2. Instead of using the FLI you can just, from a fresh SLIME session, Edi> call (capi:display-message "foo") to hang SLIME. Can be "fixed" by Edi> entering a form into the inferior-lisp buffer as well.
Edi> 3. Contrary to Alain Picard I can't reproduce the same problem on Edi> Linux. (Currently my Linux LW is 4.3.7 pro while on Windows I have Edi> 4.4.0 pro but I don't believe that makes a difference.)
Edi> My current guess is that this is somehow related to comint on Windows Edi> and the inferior-lisp buffer which is no-no land to me. I can live Edi> with the solution sketched in #1 but I'd still be happy to know what's Edi> going wrong.
Not sure if anyone mentioned this, but the problem happens in plain NTEmacs shell buffer too, when LW is running with multiprocessing.
As noted before, it only hangs the first time you call an FLI-defined function. This is because it hangs inside the DLL's initialization code, which only runs when the DLL is loaded for the first time.
The problem is related to the issues when running non-console apps in the shell and happens when the VC++ runtime initialization code calls GetFileType() on the stdin handle. This hangs for some reason when stdin in the pipe created by NTEmacs.
__Martin
Edi Weitz edi@agharta.de writes:
My current guess is that this is somehow related to comint on Windows and the inferior-lisp buffer which is no-no land to me. I can live with the solution sketched in #1 but I'd still be happy to know what's going wrong.
On Unix, Emacs can use a pty or a pipe for communication with subprocesses. The default is pty, but it can be overridden with process-connection-type. Is there a difference if you use the following patch? And out of curiosity, does the problem also occur with XEmacs (for Windows)?
diff -u -F^(.* -r1.473 slime.el --- slime.el 18 Mar 2005 19:27:31 -0000 1.473 +++ slime.el 27 Mar 2005 18:53:51 -0000 @@ -1352,7 +1352,8 @@ (defun slime-inferior-lisp (command buff (let ((args (split-string command))) ; XXX consider: cmucl -eval '(+ 1 2)' (with-current-buffer (get-buffer-create buffername) (comint-mode) - (comint-exec (current-buffer) "inferior-lisp" (car args) nil (cdr args)) + (let ((process-connection-type nil)) + (apply #'start-process "inferior-lisp" (current-buffer) args)) (lisp-mode-variables t) (get-buffer-process (current-buffer)))))
On Sun, 27 Mar 2005 21:02:45 +0200, Helmut Eller e9626484@stud3.tuwien.ac.at wrote:
On Unix, Emacs can use a pty or a pipe for communication with subprocesses. The default is pty, but it can be overridden with process-connection-type. Is there a difference if you use the following patch?
No, unfortunately not.
And out of curiosity, does the problem also occur with XEmacs (for Windows)?
Haven't tried yet. Will do if I find some time.
Cheers, Edi.
On Sun, 27 Mar 2005 22:29:05 +0200, Edi Weitz edi@agharta.de said:
Edi> On Sun, 27 Mar 2005 21:02:45 +0200, Helmut Eller e9626484@stud3.tuwien.ac.at wrote:
On Unix, Emacs can use a pty or a pipe for communication with subprocesses. The default is pty, but it can be overridden with process-connection-type. Is there a difference if you use the following patch?
Edi> No, unfortunately not.
That makes sense, because Windows doesn't have ptys.
__Martin
Edi Weitz writes:
On Sat, 04 Sep 2004 02:18:10 +0200, Edi Weitz edi@agharta.de wrote:
Has anyone else problems with SLIME when using Lispworks on Windows (XP) and its FLI?
There is even such a problem on Linux. At least, our system passes all tests from within the command line, but when we run it from within slime, the lisp hangs up during a FFI operation.
I've not been able to track down what happens. It's 100% reproducible. It certainly means it's unsafe for me to include the SWANK packages in our final product (for easier live debugging).
-
Alain.Picard＠memetrics.com -
Edi Weitz -
Helmut Eller -
Martin Simmons