Happy Tenth Birthday, E

[Allen Short]

According to the license info on some of the E-on-Java source files, E's original open source release was on 20 July, 1998.  I want to say how much I appreciate the work done by Mark Miller and the many others who have contributed to E's development since then.  As per the quote on http://erights.org/, thank you for helping keep options open for better-designed software systems. As security concerns grow larger in the public and the need for concurrent and distributed systems becomes more apparent, E is becoming more relevant than ever.

That's why I'm announcing Ecru, a C runtime for E. I've extended Darius Bacon's previous ELib work in C and added a VM based on the Smallcaps instruction set. The bytecode compiler is implemented in E and so far I've implemented enough of the language to run it.

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

Ecru's project page on Launchpad is http://launchpad.net/ecru/ . A tarball is available here: http://code.launchpad.net/ecru/+download . I've only tested it on x86 Linux so far, but plan to support other platforms.

Hopefully Ecru will provide the raw material for making E attractive for more projects, especially ones that dynamic languages like Python and Ruby are currently being used for. I look forward to your feedback!
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Allen Short]

On Sun, 20 Jul 2008 00:52:53 -0700 (PDT), Darius Bacon <darius@...> wrote:
>Hi, Allen. What a cool birthday present!
>
>The README mentions a file DEPENDENCIES that doesn't seem to
>exist. ./configure complains about a missing dependency called
>'check'; after 'yum install check', it still complains -- maybe I need
>to tell pkg-config about it somehow? Too lazy to look further now.

Whoops, I thought I might have left something out. :) I've added the
DEPENDENCIES and CREDITS files to the tarball, and uploaded a new release.

>My code was a direct descendant -- a translation and extension, minus
>a few bits that weren't yet needed -- of MarkM's C++, which ought to
>be credited. If I didn't, it was because of the super-preliminary
>state of things.

I remembered that there was some relation - I've mentioned it in CREDITS now.

>Hope you're having fun with this. Is this the first time you've
>bootstrapped a language?

I'm certainly having fun with it. As far as I remember, yes; it's certainly
the first time I've done so in C.

Thanks for checking it out!
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Seaborn-2]

Allen Short <washort@...> 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:

$ sudo apt-get install automake autoconf check libgc-dev libgmp3-dev python2.5-dev
$ ./autogen.sh --prefix=$(pwd)/prefix
$ PATH=prefix/bin PYTHONPATH=prefix/lib/python2.5/site-packages/ LD_LIBRARY_PATH=prefix/lib/ monte
? "foo"+"bar"

(process:25014): GLib-GIO-CRITICAL **: g_output_stream_write_all: assertion `G_IS_OUTPUT_STREAM (stream)' failed

(process:25014): GLib-GIO-CRITICAL **: g_memory_output_stream_get_data: assertion `G_IS_MEMORY_OUTPUT_STREAM (ostream)' failed

(process:25014): GLib-GIO-CRITICAL **: g_seekable_tell: assertion `G_IS_SEEKABLE (seekable)' failed

? "foo"
foo

? "foo"+"bar"
foobar

? 1+1
2

$ PATH=prefix/bin PYTHONPATH=prefix/lib/python2.5/site-packages/ LD_LIBRARY_PATH=prefix/lib/ monte
? 1+1

(process:25022): GLib-GIO-CRITICAL **: g_output_stream_write_all: assertion `G_IS_OUTPUT_STREAM (stream)' failed
Segmentation fault (core dumped)


Here is a backtrace I got from gdb:

? 1+1

(process:23019): GLib-GIO-CRITICAL **: g_output_stream_write_all: assertion `G_IS_OUTPUT_STREAM (stream)' failed

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf7e3c8c0 (LWP 23019)]
0xf7be3081 in g_string_new () from /usr/lib/libglib-2.0.so
(gdb) bt
#0  0xf7be3081 in g_string_new () from /usr/lib/libglib-2.0.so
#1  0xf7a90f14 in e_make_problem (complaint=0x32 <Address 0x32 out of bounds>,
    irritant=
        {script = 0xf7aa8ac4, data = {fixnum = 0, bignum = 0x0, chr = 0, gstring = 0x0, float64 = 0x0, refs = 0x0, other = 0x0}}) at src/elib.h:302
#2  0xf7a89bda in e_throw_pair (complaint=0x32 <Address 0x32 out of bounds>,
    irritant=
        {script = 0x32, data = {fixnum = 0, bignum = 0x0, chr = 0, gstring = 0x0, float64 = 0x0, refs = 0x0, other = 0x0}}) at src/invoke.c:39
#3  0xf7a90878 in writer_print (self=
        {script = 0xf7aa8a9c, data = {fixnum = 138881408, bignum = 0x8472980, chr = 10624, gstring = 0x8472980, float64 = 0x8472980, refs = 0x8472980, other = 0x8472980}}, args=0xffbd7394) at src/prim.c:1198
#4  0xf7a898e6 in e_call (receiver=
        {script = 0xf7aa8a9c, data = {fixnum = 138881408, bignum = 0x8472980, chr = 10624, gstring = 0x8472980, float64 = 0x8472980, refs = 0x8472980, other = 0x8472980}}, selector=0xf7aa8ad4, args=0xffbd7394) at src/invoke.c:128
#5  0xf7a92312 in fixnum_printOn (self=
        {script = 0xf7aa8ac4, data = {fixnum = 2, bignum = 0x2, chr = 2, gstring = 0x2, float64 = 0x2, refs = 0x2, other = 0x2}}, args=0xffbd7430)
    at src/elib.h:204
#6  0xf7a898e6 in e_call (receiver=
        {script = 0xf7aa8ac4, data = {fixnum = 2, bignum = 0x2, chr = 2, gstring = 0x2, float64 = 0x2, refs = 0x2, other = 0x2}}, selector=0xf7aa8aec,
    args=0xffbd7430) at src/invoke.c:128
#7  0xf7a90837 in writer_print (self=
        {script = 0xf7aa8a9c, data = {fixnum = 138881408, bignum = 0x8472980, chr = 10624, gstring = 0x8472980, float64 = 0x8472980, refs = 0x8472980, other = 0x8472980}}, args=0xf7dee9e0) at src/elib.h:204
#8  0xf7a92600 in writer_println (self=
        {script = 0xf7aa8a9c, data = {fixnum = 138881408, bignum = 0x8472980, chr = 10624, gstring = 0x8472980, float64 = 0x8472980, refs = 0x8472980, other = 0x8472980}}, args=0xf7dee9e0) at src/prim.c:1210
#9  0xf7a898e6 in e_call (receiver=
        {script = 0xf7aa8a9c, data = {fixnum = 138881408, bignum = 0x8472980, chr = 10624, gstring = 0x8472980, float64 = 0x8472980, refs = 0x8472980, other = 0x8472980}}, selector=0xf7dee0e0, args=0xf7dee9e0) at src/invoke.c:128
#10 0xf7db5e47 in ffi_call_SYSV ()
   from /usr/lib/python2.5/lib-dynload/_ctypes.so
#11 0xf7db5cce in ffi_call () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#12 0xf7db07f4 in _CallProc () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#13 0xf7da9f2a in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#14 0xf7a89840 in ?? () from prefix/lib/libecru.so
#15 0xf7dd5284 in ?? ()
#16 0x00001005 in ?? ()
#17 0xf7ddb374 in ?? ()
#18 0x081ec49c in ?? ()
#19 0x00000000 in ?? ()


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

=== added file 'autogen.sh'
--- autogen.sh  1970-01-01 00:00:00 +0000
+++ autogen.sh  2008-07-20 19:07:10 +0000
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+srcdir=`dirname $0`
+test -z "$srcdir" && srcdir=.
+cd $srcdir
+
+autoheader
+automake
+autoconf
+
+exec $srcdir/configure "$@"

Regards,
Mark
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Allen Short]

On Sun, 20 Jul 2008 20:21:16 +0100 (BST), Mark Seaborn <mrs@...> wrote:

>Allen Short <washort@...> 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.
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Seaborn-2]

Allen Short <washort@...> 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
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

On Jul 20, 2008, at 18:37, Mark Seaborn wrote:

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

This is not a lone problem: E requires that available comparison  
operations also equate different instances of Selfless objects, so  
promises are not the only thing prohibiting exposure of pointer-
comparison.


I'm pleased to hear that another E implementation is up and running.  
How's the performance? Can it run my half-baked benchmark script yet?

<svn://www.slimy.com/cl-e/e-benchmark/trunk>

BTW, MarkM and I have been doing a lot of E design discussion that  
hasn't been written down anywhere. (What little has been is on the  
wiki; see particularly <http://wiki.erights.org/wiki/Category:Unresolved_design_issues 
 > and <http://wiki.erights.org/wiki/Category:ELib_specification>.)  
Feel free to contact me on IRC or otherwise if you're looking for any  
sort of info on E design.

--
Kevin Reid                            <http://homepage.mac.com/kpreid/>


_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller-2]

On Sat, Jul 19, 2008 at 11:32 PM, Allen Short <washort@...> wrote:

According to the license info on some of the E-on-Java source files, E's original open source release was on 20 July, 1998.

Wow. I can't quite say it seems like almost yesterday. But 10 years is quite a shock!
 

I want to say how much I appreciate the work done by Mark Miller and the many others who have contributed to E's development since then.  As per the quote on http://erights.org/, thank you for helping keep options open for better-designed software systems. As security concerns grow larger in the public and the need for concurrent and distributed systems becomes more apparent, E is becoming more relevant than ever.

Thanks!
 

That's why I'm announcing Ecru, a C runtime for E. I've extended Darius Bacon's previous ELib work in C and added a VM based on the Smallcaps instruction set. The bytecode compiler is implemented in E and so far I've implemented enough of the language to run it.

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.

It will be wonderful having a Python bridge. So far, all we've had is a Java bridge. I wonder if it is worth checking whether the semantics of the E->Python bridge matches the semantics of the composed E->Java->Jython bridge. Unfortunately, I know almost nothing about either Python or Jython yet.
 

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

Good. E. Dean Tribble had made valiant start on a Packrat-style parser generator in E for E. I'm not sure what its current state is. But the existing Antlr grammar should be able to generate a C or C++ -based parser. The E-on-Java system does have an E-based REPL -- start with runeAuthor.emaker.
 

Ecru's project page on Launchpad is http://launchpad.net/ecru/ . A tarball is available here: http://code.launchpad.net/ecru/+download . I've only tested it on x86 Linux so far, but plan to support other platforms.

Hopefully Ecru will provide the raw material for making E attractive for more projects, especially ones that dynamic languages like Python and Ruby are currently being used for. I look forward to your feedback!

Especially with a Python bridge in place.

This is really wonderful news. Thanks so much for doing this!

--
Text by me above is hereby placed in the public domain

Cheers,
--MarkM

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Sandro Magi-3]

Allen Short wrote:
> 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.

There's libGarbageCllector [1] if you're in a hurry to do this. It's a
bit wasteful of space, and not as incremental as it purports to be, but
it's the only GC available as a portable C library that I'm aware of
(other than the conservative libgc that is).

Sandro

[1] http://www.dekorte.com/projects/opensource/libgarbagecollector/
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Allen Short]

On Mon, 21 Jul 2008 07:48:01 -0400, Sandro Magi <naasking@...> wrote:

>There's libGarbageCllector [1] if you're in a hurry to do this. It's a
>bit wasteful of space, and not as incremental as it purports to be, but
>it's the only GC available as a portable C library that I'm aware of
>(other than the conservative libgc that is).

Interesting -- I'll have a look. In the short run, it looks like the main problem is use of Python's 'ctypes' FFI: it can keep pointers to objects that the GC can't see. If I rewrite more of the bridge code in C, these pointers will stay on the C stack and thus be found during GC.
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[zooko]

Dear Allen:

Way to go!

It's encouraging to see a third serious E implementation project.  
Using C as the implementation language for E offers great potential,  
and the fact that you already have a working bridge to Python is very  
exciting.

I will definitely be experimenting with Ecru in the near future.

Yay!

Regards,

Zooko, excited
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang