Announcing E 0.8.8: A Working Windows Installer Mark S. Miller (markm@caplet.com)
Wed, 09 Feb 2000 21:11:56 -0800

E 0.8.8 is now released. This release features:

  1. A Windows Installer

The Windows binary distribution now has an open-source installer that should work at least on

      Win95
      Win98 single user
      Win98 multi-user
      WinNT & Win2000 Administrator
      WinNT & Win2000Beta regular user

Thanks at least to
      Marc Stiegler,
      Henry Boreen,
      Mark Shepard, and
      Lucky Green

for their testing, advice, and pointers leading up to this release. To anyone I forgot to mention, my apologies, and thanks as well! It has been great to be able to pose problems on the e-lang list and get such quality feedback and solutions.

My hope is that this install works well enough across the Windows platforms that I can leave it alone between now and FC'00. To others with Windows platforms, please give it a try as soon as you can. I'm leaving for FC'00 on 2/18. If you hit any problems, please let me know.

(In the meantime, Bob Schumaker has been making great progress getting E to
build and install on Linux!!! I hope to have his changes integrated in and released as 0.8.9 in time for FC'00 as well.)

                                        2) The "e" Driver

Although one can still run E by manually providing a Java command line, given the unpleasantly long additional classpath info that needs to be provided (because Cryptix 3.1.1 doesn't allow us to repack the *.class files into e.jar), and given that neither *.bat files nor any other shell language can be assumed to work adequately across all versions of Windows, this release provides a driver, "e.exe", that allows E to be invoked directly, as documented in http://www.erights.org/elang/intro/starting-e.html and http://www.erights.org/elang/intro/standalone.html . Once you've installed E, type "e --help" for details on its command line. (Of course, e's command line will be documented more fully on the web site, but it isn't currently.)

(0.8.9 will build and install a corresponding "e" executable on Linux made
from the same sources.)

                                   3) Marc Stiegler's eBrowser !!

Marc Stiegler continues to create useful, clever, and simple programs in E. This release bundles in a version of his echat program, found at <E Install Dir>/scripts/echat.e. His latest creation is the eBrowser, found at <E Install Dir>/scripts/eBrowser.e. (Though in both cases, the official versions are those found at MarcS's web site http://www.skyhunter.com/marc.html .)

Like Scheme & ML, E is a lexical-scoped lambda language. For some reason, probably the lambda-based object definition, E programs tend to make much heavier use of lexical nesting than typical programs in these other languages. If the only tool you have is a text editor, this deep lexical nesting quickly becomes a liability. With eBrowser, it's an asset. On Windows (and eventually hopefully in KDE and elsewhere) if you right-click on a *.e or *.emaker file, you'll see "eBrowse" in your right button menu. If you select it, it'll open up that E program in eBrowser. Try looking at eBrowser.e this way. As soon as the eBrowser window opens up, hit the Refresh button and wait until the left pane fills in.

Sorry to steal your thunder MarcS, but your stuff is just too cool for me not to announce. ;)

                               4) The JPanel Quasi-Parser

It's a shame that so much GUI code seems to require mind-numbing tedium in its expression, to a degree I've never encountered in any other domain. For reasons I don't understand, but have experienced, the Tk toolkit seems to suffer from this problem less badly than others. If there's a general lesson to be learned from it, I don't know what it is. In the meantime, one can steal individual good ideas.

The JPanel Quasi-Parser is a shameless imitation of a feature of Tk, as found at least in Tcl/Tk, and as explained to me by Ping. The only GUI Layout in the Java UI library that's worth a damn, IMHO, is the GridBagLayout. Unfortunately, it's too hard to use, even though the idea is simple: Lay out a rectangular grid of cells. Each contained UI element then covers a rectangular subset of these cells, where these subsets are disjoint (non-overlapping). The height of each row and the width of each column are then determined by what has been placed in these rectangles, and by the layout constraints associated with them.

Well, the spirit of quasi-literals
http://www.erights.org/elang/grammar/quasi-overview.html is that mostly literal things should be expressed in a mostly literal manner. The JPanel quasi-parser was easily written in E (found in the binary distribution inside e.jar as
org/erights/ex/swing/JPanel__quasiParser.emaker, and in the source distribution at src/esrc/org/erights/ex/swing/JPanel__quasiParser.emaker). With it, the expression:

JPanel`$a $b >

              V  $c $d
              $e >  V`

evaluates to an instance of javax.swing.JPanel containing 5 components, the values of the "a" through "e" expressions in the lexically enclosing environment, where the components are laid out on a three by three grid. "c" takes the center cell, and all the others take two cells cycling around c. It's the simplest layout that can't be built by composing horizontal towers and vertical towers. Try it!

Each line of text defines a row. The position of an embedded expression, like "$a", defines which grid element is occupied by the upper left corner of a component. ">" means "extend to the right", or more explicitly, "This grid cell should be occupied by the same component as the grid cell to my left." Similarly, "V" means "extend downward". (Tk has a similar layout and a similar syntax for specifying its use.)

Using the JPanel quasi-parser, 15 mind-numbing lines of the eBrowser
(written using a simpler layout) were replaced with 4 readable lines. The
original 15 have been commented out for illustration.

                          5) He Who Does Not Remember History...

...is destined to retype commands. Elmer adequately provides the equivalent of the conventional shell history of prior expressions (though it's both better and worse). However, there's the interesting matter of the value returned (or thrown) by prior expressions. Only during interactive use, E now accepts quasi-literal E programs. The embedded $-expressions can only be $0 through $9, and for ease of typing (and yacc nostalgia) $$, which is equivalent to $0. (More precisely, for interactive use, E is accepts a ValueMaker template string, as would appear in the expansion of a quasi-literal expression.)

Using normal quasi-literal replacement, each "$n" turns into "interp getResult(n)". The interactive interpreter remembers the values of the last 10 top-level expressions evaluated, and makes them available via getResult(n) in inverse chronological order. Practically, this means that if you just issued a command, and then you realize you wish you'd preceded it with "define x := ", you can recover by saying "define x := $$". An illustrative interaction:

     ? interp.expand := true
     # value: true
     
     ? def x := $$
     # expansion: 
     #   define x := interp getResult(0)
     
     # value: true

The "expand" property of interp causes the expansion of expressions to be shown as well as the value they evaluate to. This enables us to see the magic behind $$. The subsequent use of $$ enables us to capture the value of the previous expression.

                        6) Highlights of Bugs & Annoyances Fixed


6.1) Much improved exception reporting. The default diagnostic for a thrown exception that escapes to the top shows an E stack trace, which is typically much more informative to the E programmer than the much lengthier Java stack trace. The Java stack trace is still available by turning on interp.verbose. Exceptions which make it to the top of the run loop but are to be ignored, as in

3 <- floorDivide(0); null

are traced by default. Traced exceptions show both Java & E stack traces, and also show the Java stack trace of the eventual send that caused the run-loop event in which the exception happened. This is a partial resurrection of the old EC causality tracing, but making clever enough use of caching that it can be left on in production code.

6.2) Fully Sun Java 1.2 compatible, while still being >= 1.1.7 compatible. This was a matter of upgrading the versions of Cryptix & OROMatcher that we're using, and serializing the parser tables output by BYacc/Java. Unfortunately, we currently have an undiagnosed problem that prevents inter-Vat communication from working on Sun's Java 1.3Beta. The problem could be ours, Sun's, or Cryptix's.

6.3) The text files in the *.zip files continue to use Windows newlines conventions, but in the *.tar.gz files, these text files now use Unix newline convention. The download pages now document the *.zip files as being for Windows and the *.tar.gz files as being for Unix/Linux. (In the scripts directory you'll find newlines.e, which is how I do this conversion.) The Windows newlines had been particularly troublesome for those trying to get our Makefiles to work on Unix/Linux. (They don't work there anyway, but Bob is repairing that as we speak.)

6.4) We no longer have our own Properties mechanism, instead just using the existing java.util.Properties & java.lang.System.getProperties(). The remaining special mechanism is that "Setup.exe" (the installer) writes, in a format compatible with Java's Properties.save() and .load(), the install-time configuration parameters to <E Install Dir>/eprops.txt .

"e.exe" (the command line driver) obtains from the Registry *only* the location of the E installation directory. It then reads this file to determine what Java command to invoke (e.g., "C:\Windows\jre.exe"). It includes, on the command line it generates, the option "-De.InstallDir=<E Install Dir>". When the E interpreter (org.erights.e.interp.Interp) starts up, it looks up that system property in order to find and load eprops.txt into the system properties, thereby extending them. That's how, for example, the tracing system finds out what directory tracing data should be stored in, when was decided by the user interacting with Setup.exe.

I need to document all the properties defined or used by E.

6.5) The E URL syntax was notoriously error prone. Since both "," and ")" are legal URL characters, it's tricky to determine when a URL is over. Even though I wrote the bloody thing, I found my rule, "always terminate a URL with a space" rather hard to remember. Someone on the list suggested that URLs should be surrounded by angle brackets. Whoever you are (please speak up), thank you! I was surprised to find that this change to E's grammar did not introduce an ambiguity. As of 0.8.8 I accept both syntaxes (what is the plural of "syntax"?), but the bare URL syntax is now deprecated. In will no longer be supported as of 0.8.9.

6.6) Many deprecates have been made to disappear. These were almost all uses of the deprecated java.io.PrintStream rather than java.io.PrintWriter. Similarly for uses of java.io.InputStream for reading text rather than some variety of java.io.Reader. In both cases, the deprecated alternative is not Unicode tolerant. These have all been fixed. A mystery: In the standard Java API, System(.out, .err, .in) are of the deprecated sort, and there's no non-deprecated alternative. So I created one: PrintStreamWriter. Yuck.

Brian, the remaining deprecateds are all in your Trace package. You're using Date in ways that Javasoft would have you to use Calendar instead.

6.7) Speaking of the Trace package, I replaced all occurrences of "protected" in the Trace package with "/*package*/" and everything still seemed to work. Therefore, until I hear otherwise, I'll assume that none of these methods needed the more liberal scope.

6.8) The security bug documented in
http://www.eros-os.org/~majordomo/e-lang/1297.html has been fixed in the way that message describes.

                              7) The Proxy Comm System

I made many improvements to the Proxy-Comm System, the module implementing Object-Pluribus. Unfortunately, in so doing, I apparently broke it as well. In 0.8.5 on, including 0.8.8, we have a monstrous performance bug where actions that used to take seconds are instead taking hours, and soaking up CPU time while they do so. It may very well be something trivial -- I haven't had time to look until installation was straightened out, and I now may not be able to fix this before FC'00. At least it seems to *only* be a performance bug. No incorrect data or computation have been observed.

I've started documenting the reformed Object-Pluribus protocol at http://www.erights.org/elib/object-pluribus/index.html . Please do try the special effect at
http://www.erights.org/elib/object-pluribus/OP_DELIVER_ONLY.html and let me know what you think.

Until this bug is fixed, 0.8.4 will continue to be available.

Towards Jurisdiction-Free Commerce!

         Cheers,
         --MarkM