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
 
-----Original = Message-----
From:=20 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=20 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 = 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
-----Original=20 Message-----
From: 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=20 Problems Resolved

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
 
-----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 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>
 
------=_NextPart_000_011B_01BEF316.8C4DEDA0--