Re: Ecru REPL bugs

Allen Short <washort-TyWPi3/[email protected]> wrote:

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

I'm surprised the GC is kicking in that quickly.  Is it generational?

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

Would it make sense to reuse CPython's storage model?  i.e. Its object
headers, reference counting, and cycle collecting GC.  It may not be
the fastest language implementation in the world, but it would give
you precise GC very quickly, and bridging to Python would be trivial.

Is there anything in E's data model that would make that awkward?  As
I understand it, promises can "become" the object they resolve to,
which would not work with Python's "is" operator.  E's EQ would have
to follow promises' resolution chains before doing the comparison.


> >Here is a patch to add a GNOME-style autogen.sh script:
> <snip>
> 
> Are these needed anymore? I thought 'autoreconf' filled that role now.

Maybe it does.  I have noticed though that JHBuild's default is to
invoke autogen.sh.  Some of the autogen.sh scripts in GNOME seem
relatively complex (more than a few lines).  Some of them invoke tools
like "gtkdocize", which autoreconf isn't going to invoke for you
AFAIK.  So it seems GNOME's policy is to use autogen.sh (though I
don't think I've seen that documented anywhere).  It seems like a good
policy that everything should build the same way with JHBuild, but I
realise that different people use autotools in different ways.  It's
not always easy to tell why autotools is the way it is. :-)

Mark