[Ecls-list] ECL HEAD + Slime HEAD
Andy Hefner
ahefner at gmail.com
Wed Feb 17 01:39:16 UTC 2010
On Tue, Feb 16, 2010 at 6:14 PM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
>
> I'd like people to test current Slime HEAD with ECL HEAD.
I've taken Slime HEAD and ECL HEAD for a spin. After a few run/crash
cycles, here are my observations:
Note I'm running swank:create-server in its own thread from an
executable compiled with ECL, connecting Slime to that while the app
grinds away at 100% CPU use in the background. This might exacerbate
threading-related instability. Platform is Linux/x86, ECL is built
with threads, without unicode, and using gcc-4.3.2. Communication
style is, I think, :spawn.
First, C-c C-k is still broken: Unknown or unsupported external
format: ISO-8859-1
It's definitely not stable, although ECL will sometimes soldier on for
surprisingly long before falling over.
I've seen memory fault errors pop up in sldb while typing. Dismissing
them, the system continues to run.
While compiling definitions, sometimes I see the following, and the
compilation fails, but the system keeps running. This occurs
unpredictably.
;;;
;;; Stack overflow.
;;; Jumping to the outermost toplevel prompt
;;;
While compiling a definition (slime-compile-defun), after several
previous successful uses, ECL abruptly died with the following error.
Note that I was compiling a regular DEFUN at the time, not a method:
Internal or unrecoverable error in:
search_method_hash
[2: No such file or directory]
Aborted
My last ECL/Slime session died with a segmentation fault and no other
error. Typically sessions only survive for a few minutes or roughly
dozen Slime interactions. Curious of whether it would work better
without my app running in the background, I started ECL from Slime and
loaded a subset of my code in. I still observed the stack overflow
errors, and after several attempts at compiling the same defun, ECL
segfaulted and died.
I don't think ECL is stable with multiple threads running. I
frequently compile ECL with threading enabled, but never use more than
one thread.
More information about the ecl-devel
mailing list