Build Problems Resolved
Paul Snively
psnively@earthlink.net
Tue, 31 Aug 1999 09:34:32 -0700
This is a multi-part message in MIME format.
------=_NextPart_000_001F_01BEF394.07CAE780
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Marc! By the way, thanks for Earthweb--I greatly enjoyed it, and of =
course I'm using it to answer the question "Why do we need =
capability-based security?" whenever I'm asked!
-----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 6:37 PM
Subject: Re: Build Problems Resolved
=20
=20
>'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 :-)
=20
I guess I tend to side with markm, then, given how much awful code =
that's come into being through accretion I've had to deal with...
=20
>However, the following points are true:
>=20
>--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.
=20
Got it. I'll let my question stand, however, due to OROMatcher not =
being open source.
=20
--markm has a design for byte code compilation compatible with the =
existing system=20
=20
That's also good news, but does it get us closer to accomplishing =
other goals at the same time? My point from my original e-mail on the =
subject was that a rewrite might afford us the opportunity to unify what =
currently would need to be disparate approaches to things, e.g. =
bytecode-generation would be one thing and getting on EROS would be =
another, whereas a rewrite of the interpreter/compiler could get us =
closer to both by accomodating the notion of multiple targets, where =
Java bytecodes were one such target and native Pentium-family code with =
an appropriate native runtime for, e.g. EROS would be another.
=20
>--there is work ongoing to build a persistence system within the =
current >design (at least I think it is ongoing :-).
=20
I'd be most interested in hearing more about this. The last I heard, =
ColdStore was under consideration for integration, but it's hard to see =
how this would happen in Java without JNI and lots of wrappers--apart =
from reimplementing the JVM atop ColdStore, which is what the ColdStore =
folks would seem to prefer anyway. But once again, if your'e going to do =
that, targeting EROS seems no harder.
=20
>Many of us are interested in E on Eros, the holdup there is getting =
a jvm >on Eros.
=20
Once again, I wasn't thinking of running E in Java on EROS; I was =
thinking of a native port with a native runtime.
=20
Does this make any more sense?
=20
>--marcs
=20
Thanks!
=20
Paul=20
-----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_001F_01BEF394.07CAE780
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
Hi Marc! By the way, thanks for =
Earthweb--I=20
greatly enjoyed it, and of course I'm using it to answer the question =
"Why=20
do we need capability-based security?" whenever I'm =
asked!
-----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 6:37 PM
Subject: Re: Build =
Problems=20
Resolved
>'Tis for markm to consider; =
goodness=20
knows, markm's psychological >profile makes him inclined to do =
total=20
rewrites as often as possible, at >the earliest possible moment=20
:-)
I guess I tend to side with =
markm, then,=20
given how much awful code that's come into being through accretion =
I've had=20
to deal with...
>However, the following points are =
true:
>
>--the OROMatcher is not part of the =
problem with=20
IBM VA jvm or the >other jvms or JITS. These problems occur in=20
implementations of E that >don't have a regular expression system =
of any=20
kind; reg exps are not >fundamental to the design of E, =
oromatcher is an=20
add-on.
Got it. I'll let my question =
stand, however,=20
due to OROMatcher not being open source.
--markm has a design for byte code compilation =
compatible=20
with the existing system
That's also good news, but does =
it get us=20
closer to accomplishing other goals at the same time? My point from =
my=20
original e-mail on the subject was that a rewrite might afford us =
the=20
opportunity to unify what currently would need to be disparate =
approaches to=20
things, e.g. bytecode-generation would be one thing and getting on =
EROS=20
would be another, whereas a rewrite of the interpreter/compiler =
could get us=20
closer to both by accomodating the notion of multiple targets, where =
Java=20
bytecodes were one such target and native Pentium-family code with =
an=20
appropriate native runtime for, e.g. EROS would be =
another.
>--there is work ongoing to build a =
persistence system=20
within the current >design (at least I think it is ongoing=20
:-).
I'd be most interested in =
hearing more about=20
this. The last I heard, ColdStore was under consideration for =
integration,=20
but it's hard to see how this would happen in Java without JNI and =
lots of=20
wrappers--apart from reimplementing the JVM atop ColdStore, which is =
what=20
the ColdStore folks would seem to prefer anyway. But once again, if =
your'e=20
going to do that, targeting EROS seems no harder.
>Many of us are interested in E on Eros, the =
holdup=20
there is getting a jvm >on Eros.
Once =
again, I wasn't=20
thinking of running E in Java on EROS; I was thinking of a native =
port with=20
a native runtime.
Does this make any more =
sense?
>--marcs
Thanks!
Paul
-----Original=20
Message-----
From: Paul Snively <psnively@earthlink.net>
=
To:=20
Marc Stiegler <marcs@skyhunter.com>; =
e-lang@eros-os.org <e-lang@eros-os.org>
Date:=
=20
Monday, August 30, 1999 5:00 PM
Subject: Re: Build =
Problems Resolved
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=20
this point) for all of the desiderata:
1) Reintroducing persistence--of particular=20
significance, 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=20
if not also the JIT problem) with the GNU Java regex=20
package.
3) Replacing the rather byzantine byaccj =
process with=20
a grammar etc. built around ANTLR. Using the tree support in =
ANTLR might=20
lead us directly to:
4) Bytecode-compiling E rather than =
interpreting.=20
Apart 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=20
at Cygnus as part of his Kawa implementation of Scheme in=20
Java.
5) While we're compiling E, let's add =
support for=20
multiple targets: Java bytecode + ELib being the first, of =
course, and=20
some sort of runtime (ColdStore etc.?) atop EROS being the=20
second.
Any thoughts on all of this?
Paul
-----Original=20
Message-----
From: Marc Stiegler <marcs@skyhunter.com>
To:=
=20
Paul Snively <psnively@earthlink.net>;=20
e-lang@eros-os.org =
<e-lang@eros-os.org>
Date:=
=20
Monday, August 30, 1999 10:15 AM
Subject: Re: =
Build=20
Problems Resolved
E seems to be a very, =
very intensive=20
exerciser for jvms and JITs. We haven't found any JIT =
that=20
works with E yet (right, markm? Or does the Symantec JIT =
work?).=20
Neither the IBM 1.1.6 jvm nor the Microsoft 1.1.6 jvm works =
with E=20
either. No 1.1.5 jvm from anywhere ever worked with it. =
Though we=20
haven't tried HotSpot or BulletTrain yet, and I have big =
hopes for=20
the 1.1.8 jvm from IBM, which rumor suggests will be a =
crackerjack=20
implementation.
--marcs
-----Original=20
Message-----
From: Paul Snively <psnively@earthlink.net>
=
To:=20
e-lang@eros-os.org=20
<e-lang@eros-os.org>
Date:=
=20
Sunday, August 29, 1999 10:26 PM
Subject: =
Build=20
Problems Resolved
Gentlemen,
My apologies--I had =
suspected=20
that I had to be overlooking something obvious, as I=20
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=20
that the Makefiles all have CRLF line endings, per their =
having=20
been created on Windows. Using GNU EMACS on Linux was =
making=20
this from me by reconciling line-endings transparently. =
Using=20
M-x hexl-find-file to open the file in hex mode revealed =
the=20
problem, and then using M-x find-file-literally brought =
the file=20
in without line-ending conversions... causing all of =
those ^M's=20
to show up and be amenable to M-x replace-string ^Q^M=20
<RET><RET>. After that, the remainder of =
getting E=20
built consisted of some mostly trivial edits to the =
Makefiles=20
(generally dealing with CLASSPATH issues) and replacing=20
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=20
had Swing 1.1.1 installed for other =
reasons.
Incidentally, I =
don't know why,=20
but E 0.8.4 also breaks the TYA JIT for the Blackdown =
JDK. If I=20
disable the JIT, everything works fine. With TYA 1.4 =
enabled,=20
both E and Elmer just hang sometime during =
initialization.=20
*sigh*
Thanks for the=20
help!
Paul =
Snively
<mailto:psnively@earthlink.net>