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