Build Problems Resolved
Marc Stiegler
marcs@skyhunter.com
Mon, 30 Aug 1999 18:36:18 -0700
This is a multi-part message in MIME format.
------=_NextPart_000_011B_01BEF316.8C4DEDA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
'Tis for markm to consider; goodness knows, markm's psychological =
profile makes him inclined to do total rewrites as often as possible, at =
the earliest possible moment :-)
However, the following points are true:
--the OROMatcher is not part of the problem with IBM VA jvm or the =
other jvms or JITS. These problems occur in implementations of E that =
don't have a regular expression system of any kind; reg exps are not =
fundamental to the design of E, oromatcher is an add-on.
--markm has a design for byte code compilation compatible with the =
existing system=20
--there is work ongoing to build a persistence system within the current =
design (at least I think it is ongoing :-).
Many of us are interested in E on Eros, the holdup there is getting a =
jvm on Eros.
--marcs
-----Original Message-----
From: Paul Snively <psnively@earthlink.net>
To: Marc Stiegler <marcs@skyhunter.com>; e-lang@eros-os.org =
<e-lang@eros-os.org>
Date: Monday, August 30, 1999 5:00 PM
Subject: Re: Build Problems Resolved
=20
=20
Folks,
=20
I have to ask this; please forgive me.
=20
Is it time to rewrite E?
=20
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:
=20
1) Reintroducing persistence--of particular significance, perhaps, =
now that ColdStore is in beta.
=20
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.
=20
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:
=20
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.
=20
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.
=20
Any thoughts on all of this?
=20
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_011B_01BEF316.8C4DEDA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
'Tis for markm to consider; goodness =
knows,=20
markm's psychological profile makes him inclined to do total rewrites as =
often=20
as possible, at the earliest possible moment :-)
However, the following points are true:
--the OROMatcher is not part of the problem =
with IBM VA=20
jvm or the other jvms or JITS. These problems occur in implementations =
of E that=20
don't have a regular expression system of any kind; reg exps are not =
fundamental=20
to the design of E, oromatcher is an add-on.
--markm has a design for byte code compilation =
compatible with=20
the existing system
--there is work ongoing to build a persistence =
system within=20
the current design (at least I think it is ongoing :-).
Many of us are interested in E on Eros, the holdup =
there is=20
getting a jvm on Eros.
--marcs
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=20
already been expressed on this list that might best be addressed by =
a=20
top-to-bottom rewrite of E, incorporating support (as best we can at =
this=20
point) for all of the desiderata:
1) Reintroducing persistence--of particular =
significance,=20
perhaps, now that ColdStore is in beta.
2) Replacing the non-open-source OROMatcher =
(which,=20
frankly, I suspect to be at the root of at least the Visual Age =
problem if=20
not also the JIT 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=20
us directly to:
4) Bytecode-compiling E rather than =
interpreting. Apart=20
from leveraging ANTLR for this, we might also want to look at the=20
open-source GNU Java bytecode-generation library written by Per =
Bothner at=20
Cygnus as part of his 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=20
with E yet (right, markm? Or does the Symantec JIT work?). =
Neither the=20
IBM 1.1.6 jvm nor the Microsoft 1.1.6 jvm works with E either. =
No 1.1.5=20
jvm from anywhere ever worked with it. Though we haven't tried =
HotSpot=20
or BulletTrain yet, and I have big hopes for the 1.1.8 jvm from =
IBM,=20
which rumor suggests will be a crackerjack =
implementation.
--marcs
Gentlemen,
My apologies--I had =
suspected that I=20
had to be overlooking something obvious, as I =
was.
First of all, Mark, I =
did notice=20
that it was necessary to change the jsrc/Makefile to refer =
to=20
JCOMPILE, but thanks for the reminder!
The bigger issue, =
though, is that=20
the Makefiles all have CRLF line endings, per their having =
been=20
created on Windows. Using GNU EMACS on Linux was making this =
from me=20
by reconciling line-endings transparently. Using M-x =
hexl-find-file=20
to open the file in hex mode revealed the problem, and then =
using=20
M-x find-file-literally brought the file in without =
line-ending=20
conversions... causing all of those ^M's to show up and be =
amenable=20
to M-x replace-string ^Q^M <RET><RET>. After =
that, the=20
remainder of getting E built consisted of some mostly =
trivial edits=20
to the Makefiles (generally dealing with CLASSPATH issues) =
and=20
replacing occurrances of com.sun.java.swing with javax.swing =
in the=20
sources, since I refuse to roll back to Swing 1.0.3 and =
already had=20
Swing 1.1.1 installed for other reasons.
Incidentally, I don't =
know why, but=20
E 0.8.4 also breaks the TYA JIT for the Blackdown JDK. If I =
disable=20
the JIT, everything works fine. With TYA 1.4 enabled, both E =
and=20
Elmer just hang sometime during initialization. =
*sigh*
Thanks for the =
help!
Paul =
Snively
<mailto:psnively@earthlink.net>