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