Hi!
This is with the current CVS SLIME (update a couple of minutes ago), GNU Emacs 21.3.50 from CVS (about a month ago), CMUCL 18e, and the current (0.7.7) CL-PPCRE on Linux x86. I can reproduce the problem like this:
1. Remove all FASL file (*.x86f) related to CL-PPCRE.
2. From a fresh Emacs start SLIME and then load the system CL-PPCRE.
3. CL-PPCRE is compiled but the REPL prompt never comes back. Instead, Emacs starts to use 99% of the CPU and is completely unresponsive, I have to kill it with xkill.
I can compile CL-PPCRE from the command line without problems. Furthermore, this doesn't happen if CL-PPCRE is already compiled and has just to be loaded.
I suspect this happens while SLIME tries to interpret CMUCL's compiler notes but I currently have no idea how to debug this.
Cheers, Edi.
Edi Weitz edi@agharta.de writes:
I suspect this happens while SLIME tries to interpret CMUCL's compiler notes but I currently have no idea how to debug this.
That or during pretty printing the event in the event log buffer. Can you try to disable slime-log-events? When I compile CL-PPCRE, with logging disabled, I get 396 notes; annotating and listing compiler notes requires about 10 seconds.
On Fri, 21 May 2004 22:14:22 +0200, Helmut Eller e9626484@stud3.tuwien.ac.at wrote:
That or during pretty printing the event in the event log buffer. Can you try to disable slime-log-events?
Yes, with slime-log-events set to nil I don't see the problem. So, is this a bug or do I just have to wait longer?
Thanks, Edi.
Edi Weitz edi@agharta.de writes:
Yes, with slime-log-events set to nil I don't see the problem. So, is this a bug or do I just have to wait longer?
Should be fixed in CVS. I just set print-length and print-level to avoid overly long log entries.
Helmut.
On Sat, 22 May 2004 10:13:38 +0200, Helmut Eller e9626484@stud3.tuwien.ac.at wrote:
Should be fixed in CVS. I just set print-length and print-level to avoid overly long log entries.
Yep, it's gone now.
As always, thanks for the quick fix!
Cheers, Edi.
-
Edi Weitz -
Helmut Eller