Build Problems Resolved

Paul Snively psnively@earthlink.net
Mon, 30 Aug 1999 16:57:16 -0700


This is a multi-part message in MIME format.

------=_NextPart_000_000D_01BEF308.B6B118A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Folks,

I have to ask this; please forgive me.

Is it time to rewrite E?

It seems to me that there are several goals that have already been =
expressed on this list that might best be addressed by a top-to-bottom =
rewrite of E, incorporating support (as best we can at this point) for =
all of the desiderata:

1) Reintroducing persistence--of particular significance, perhaps, now =
that ColdStore is in beta.

2) Replacing the non-open-source OROMatcher (which, frankly, I suspect =
to be at the root of at least the Visual Age problem if not also the JIT =
problem) with the GNU Java regex package.

3) Replacing the rather byzantine byaccj process with a grammar etc. =
built around ANTLR. Using the tree support in ANTLR might lead us =
directly to:

4) Bytecode-compiling E rather than interpreting. Apart from leveraging =
ANTLR for this, we might also want to look at the open-source GNU Java =
bytecode-generation library written by Per Bothner at Cygnus as part of =
his Kawa implementation of Scheme in Java.

5) While we're compiling E, let's add support for multiple targets: Java =
bytecode + ELib being the first, of course, and some sort of runtime =
(ColdStore etc.?) atop EROS being the second.

Any thoughts on all of this?

Paul
    -----Original Message-----
    From: Marc Stiegler <marcs@skyhunter.com>
    To: Paul Snively <psnively@earthlink.net>; e-lang@eros-os.org =
<e-lang@eros-os.org>
    Date: Monday, August 30, 1999 10:15 AM
    Subject: Re: Build Problems Resolved
   =20
   =20
    E seems to be a very, very intensive exerciser for jvms and JITs. We =
haven't found  any JIT that works with E yet (right, markm? Or does the =
Symantec JIT work?). Neither the IBM 1.1.6 jvm nor the Microsoft 1.1.6 =
jvm works with E either. No 1.1.5 jvm from anywhere ever worked with it. =
Though we haven't tried HotSpot or BulletTrain yet, and I have big hopes =
for the 1.1.8 jvm from IBM, which rumor suggests will be a crackerjack =
implementation.
    =20
    --marcs
    =20
        -----Original Message-----
        From: Paul Snively <psnively@earthlink.net>
        To: e-lang@eros-os.org <e-lang@eros-os.org>
        Date: Sunday, August 29, 1999 10:26 PM
        Subject: Build Problems Resolved
       =20
       =20
        Gentlemen,
        =20
        My apologies--I had suspected that I had to be overlooking =
something obvious, as I was.
        =20
        First of all, Mark, I did notice that it was necessary to change =
the jsrc/Makefile to refer to JCOMPILE, but thanks for the reminder!
        =20
        The bigger issue, though, is that the Makefiles all have CRLF =
line endings, per their having been created on Windows. Using GNU EMACS =
on Linux was making this from me by reconciling line-endings =
transparently. Using M-x hexl-find-file to open the file in hex mode =
revealed the problem, and then using M-x find-file-literally brought the =
file in without line-ending conversions... causing all of those ^M's to =
show up and be amenable to M-x replace-string ^Q^M <RET><RET>. After =
that, the remainder of getting E built consisted of some mostly trivial =
edits to the Makefiles (generally dealing with CLASSPATH issues) and =
replacing occurrances of com.sun.java.swing with javax.swing in the =
sources, since I refuse to roll back to Swing 1.0.3 and already had =
Swing 1.1.1 installed for other reasons.
        =20
        Incidentally, I don't know why, but E 0.8.4 also breaks the TYA =
JIT for the Blackdown JDK. If I disable the JIT, everything works fine. =
With TYA 1.4 enabled, both E and Elmer just hang sometime during =
initialization. *sigh*
        =20
        Thanks for the help!
        Paul Snively
        <mailto:psnively@earthlink.net>
        =20

------=_NextPart_000_000D_01BEF308.B6B118A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">






Folks,
 
I have to ask this; please forgive me.
 
Is it time to rewrite E?
 
It seems to me that there are several goals that = have already=20 been expressed on this list that might best be addressed by a = top-to-bottom=20 rewrite of E, incorporating support (as best we can at this point) for = all of=20 the desiderata:
 
1) Reintroducing persistence--of particular = significance,=20 perhaps, now that ColdStore is in beta.
 
2) Replacing the non-open-source OROMatcher (which, = frankly, I=20 suspect to be at the root of at least the Visual Age problem if not also = the JIT=20 problem) with the GNU Java regex package.
 
3) Replacing the rather byzantine byaccj process = with a=20 grammar etc. built around ANTLR. Using the tree support in ANTLR might = lead us=20 directly to:
 
4) Bytecode-compiling E rather than interpreting. = Apart from=20 leveraging ANTLR for this, we might also want to look at the open-source = GNU=20 Java bytecode-generation library written by Per Bothner at Cygnus as = part of his=20 Kawa implementation of Scheme in Java.
 
5) While we're compiling E, let's add support for = multiple=20 targets: Java bytecode + ELib being the first, of course, and some sort = of=20 runtime (ColdStore etc.?) atop EROS being the second.
 
Any thoughts on all of this?
 
Paul
-----Original = Message-----
From:=20 Marc Stiegler <marcs@skyhunter.com>
To:= =20 Paul Snively <psnively@earthlink.net>; = e-lang@eros-os.org <e-lang@eros-os.org>
Date:= =20 Monday, August 30, 1999 10:15 AM
Subject: Re: Build = Problems=20 Resolved

E seems to be a very, very = intensive=20 exerciser for jvms and JITs. We haven't found  any JIT that = works with=20 E yet (right, markm? Or does the Symantec JIT work?). Neither the = IBM 1.1.6=20 jvm nor the Microsoft 1.1.6 jvm works with E either. No 1.1.5 jvm = from=20 anywhere ever worked with it. Though we haven't tried HotSpot or = BulletTrain=20 yet, and I have big hopes for the 1.1.8 jvm from IBM, which rumor = suggests=20 will be a crackerjack implementation.
 
--marcs
 
-----Original=20 Message-----
From: Paul Snively <psnively@earthlink.net>
= To:=20 e-lang@eros-os.org = <e-lang@eros-os.org>
Date:= =20 Sunday, August 29, 1999 10:26 PM
Subject: Build = Problems=20 Resolved

Gentlemen,
 
My apologies--I had = suspected that I had=20 to be overlooking something obvious, as I was.
 
First of all, Mark, I did = notice that it=20 was necessary to change the jsrc/Makefile to refer to JCOMPILE, = but=20 thanks for the reminder!
 
The bigger issue, though, is = that the=20 Makefiles all have CRLF line endings, per their having been = created on=20 Windows. Using GNU EMACS on Linux was making this from me by = reconciling=20 line-endings transparently. Using M-x hexl-find-file to open the = file in=20 hex mode revealed the problem, and then using M-x = find-file-literally=20 brought the file in without line-ending conversions... causing = all of=20 those ^M's to show up and be amenable to M-x replace-string ^Q^M = <RET><RET>. After that, the remainder of getting E = built=20 consisted of some mostly trivial edits to the Makefiles = (generally=20 dealing with CLASSPATH issues) and replacing occurrances of=20 com.sun.java.swing with javax.swing in the sources, since I = refuse to=20 roll back to Swing 1.0.3 and already had Swing 1.1.1 installed = for other=20 reasons.
 
Incidentally, I don't know = why, but E=20 0.8.4 also breaks the TYA JIT for the Blackdown JDK. If I = disable the=20 JIT, everything works fine. With TYA 1.4 enabled, both E and = Elmer just=20 hang sometime during initialization. *sigh*
 
Thanks for the = help!
Paul Snively
<mailto:psnively@earthlink.net>
 
------=_NextPart_000_000D_01BEF308.B6B118A0--