Ecru REPL bugs

On Sun, 20 Jul 2008 20:21:16 +0100 (BST), Mark Seaborn <mrs-ChQETwBkFSdCgCasaBwmdgC/[email protected]> wrote:
>Allen Short <washort-TyWPi3/[email protected]> wrote:
>
>> I plan to use Ecru alongside Python until it's complete enough to
>> write applications with on its own. I've written a Python bridge
>> module that can run code in the Ecru VM and exchange objects with
>> it. I've also written a parser for E and an expander to Kernel-E in
>> Python and a primitive REPL based on them.  (Eventually, I hope to
>> rewrite these in E as well, and reuse as much of the existing code
>> for 'rune' as possible.)
>
>Looks interesting.
>
>I tried it on Debian lenny i386.  Some simple expressions in the REPL
>sometimes work but other times produce warnings or segfaults:
<snip>

Thanks for the bug report -- I've put it in the bug tracker here: https://bugs.launchpad.net/ecru/+bug/250320

How embarrassing that "1+1" could fail like that :) I believe this is a problem with the Python bridge code; I have had several occasions where Python objects have held references to E objects that the GC has freed. I thought I had caught all the cases where that was happening, but evidently not. 

For a simple workaround, you can compile it with 'make CFLAGS="-DNO_GC"'. (My belief that this is a problem with interactions between Python memory management and Boehm GC is supported by the fact that valgrind doesn't reveal any memory errors when it's compiled without GC.)

I plan to switch to precise GC at some point which should make this problem a lot easier to deal with. In the meantime I'll take a look at reworking how these references are stored for access by Python.

>Here is a patch to add a GNOME-style autogen.sh script:
<snip>

Are these needed anymore? I thought 'autoreconf' filled that role now.