[Ecls-list] ECL HEAD + Slime HEAD

[Tobias C. Rittweiler]

Andy Hefner <ahefner at gmail.com> writes:

Hi Andy!

Thanks for giving it a whirl!


> 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

This is because you compiled ECL without unicode. I haven't got a clue
where that error comes from in case ECL was built without unicode,
though. Giving it a short, courteous look didn't reveal anything
obvious.


> 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 typing? That sounds like due to autodoc performing async. requests
in the background while typing. The Lisp-side autodoc code makes some
use of CLOS and MOP -- which I can imagine is easily not thread-safe
given the lazy nature of CLOS implementations.

Juan: Can you comment on thread-safety of ECL's CLOS?


> 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
> ;;;

Try with unicode, or at least make sure that you do not try to use ECL
with :coding-system utf-8-unix, and also check your
slime-net-coding-system. (This made C-c C-c work for me, but still not
C-c C-k.)


> 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.

Many stuff defined in ECL's swank backend is not properly written, and
only works half the time. Unfortunately if these functions blow up, it
has pretty disastrous consequences to ECL itself (because of recursive
errors.)

Juan and me agreed that we have to sit down for a weekend, and improve
ECL's swank backend at some not-too-distant point in future.


Another data point is that I'm on a relatively old (i.e. slow)
uni-processor machine, and may hence not be bitten by multi-threading
bugs as easily as people on faster SMP machines.

  -T.