Earlier versions of E have been tested and run on MSWindows (95, 98 FE, 98 SE, NT, 2K), Linux, Solaris, FreeBSD, and now Mac OS X (which is really a FreeBSD platform with its own GUI toolkit and JDK). It should run on other UNIX platforms as well, given an adequate version of Java and bash (see below). It should also run without problems on MSWindows ME, but as far as we are aware, no one has tried this. If you experience any problems, or have any other informative experiences, please let me know, or report a bug.
The Installing links below describe how to install, and run various forms of the binary distribution. The Building links describe how to build E from the source release. The Download links will download each corresponding form of the release to your machine.
Prior to this release, Updoc ran (mostly) sequentially, doing only one test script at a time. What we've had in mind from the beginning is being able to run test scripts in parallel. The erights.org website already contains many updoc scripts, which have caught several bugs. Before doing a release, we'd like to rerun all our regression tests, using all our available idle machines. This release introduces a new service -- the evalServerPool -- that stands between Updoc and a set of evalServers. The evalServerPool honors requests for evalServers, allocates them to clients (like Updoc), and reallocates them to later clients when the earlier clients are done.
This release closes bugs
Updoc currently makes only limited use of the potential parallelism, still running only one test script at a time. Multi-vat test scripts (like the Introducing Remote Objects page) do make use of all the parallelism the evalServerPool has to offer.
The evalServerPool and its clients (currently only Updoc) are designed to recover from the loss of an evalServer, and reschedule the test script to be done using the remaining resources. This hasn't yet been tested.
The evalServerPool does not yet correctly recover from the loss of a client -- those evalServers allocated to that client are not yet released back to the pool if the client disconnects. Under such circumstances, you must restart the evalServerPool.
Elmer's and eBrowser's "run" buttons should also be clients of the evalServerPool, but this hasn't happened yet. Likewise, the interactive command line interpreter invoked by the shell command "e --interact" (or just "e") should likewise be implemented as clients of the evalServerPool.
The Updoc pages will be updated to explain how to use the new Updoc and evalServerPool.
This work is primarily by Terry Stanley, thanks!
A complete E system is persistent, distributed, and capability-secure both within and between processes. Incomplete variants of E are tagged by which of these features are left out.
A non-persistent E is called time-local since an object only exist as long as its hosting process does. A non-distributed E is called space-local if an object and all references to it only exist within its hosting process.
E by definition provides distributed capability-security -- the ability for objects in mutually suspicious processes to safely cooperate. If it looks like E and it quacks like E, it might be a duck; but if it doesn't provide distributed capability security, it's not E. A system that's otherwise equivalent to E, but doesn't provide distributed capability security, is called daffE. A distributed E can only be implemented by means of strong crypto, of course, for which we are using code derived from the Cryptix library (in accord with the terms of their open-source license). In a space-local system, no distributed insecurity can arise, so such a system would be an sl-E rather than an sl-daffE.
E is designed to provide local capabillity-security -- the ability for mutually suspicious objects hosted by the same process to safely cooperate, and the use of capability discipline to determine which of its hosting process's authorities it may exercise. Such objects could be executing untrusted code -- code that the hosting process (or its owner) doesn't need to fully trust.
This is a "complete" release of E. "complete" is in quotes, because both the persistence and the distribution leave much to be desired, as explained here. However, these are close enough that this release that doesn't need qualifiers in its name.
Versions & Types of Java
In refering to various versions of Java, we follow Sun's terminology and numbering. A Java Runtime, or jre, is adequate to run standard Java binary programs (class files & resources). A Java Development Kit, or jdk, is adequate both to build a program from sources and to run it. A jdk is a superset of the corresponding jre, and their version numbers are always in synch. Each successive version of the jdk/jre from Sun effectively defines a new version of the Java & JVM standards, except that Sun has introduced a numbering inconsistency: The Java/JVM 2.x standard corresponds to Sun's jdk/jre 1.2.x. We ignore this inconsistency and refer to both as 1.2.x.
This version of E requires a jre >= 1.3.1. E no longer supports Java < 1.3.1. To build E from sources, a corresponding jdk is required.
Note: E does not install correctly when using JDK1.4beta on Windows2000 -- it fails to exec the "winfo.exe" executable, used during install time to gather info about your Windows system. It seems to be a more general problem in execing executables. If you experience this problem, we suggest you install using a JDK1.3.* or a JDK >= JDK1.4.0-rc. ("rc" means "release candidate" and is post-beta.) Once installed, E should work fine with any JDK >= 1.3.1, except for the inability to exec other programs if you're using the 1.4 beta.
Some places to get a jre or jdk:
To build E requires a bash available as "/bin/bash". If bash is unavailable for your platform, it seems to work better than it should to make a symbolic link from "/bin/bash" to "/bin/sh". If you try this and run into problems, please report these problems.
To run the E driver script "e" requires a bash >= 2.01 available on your PATH, and the env program available as /usr/bin/env. The E driver script is required (and must also be on your PATH) in order to be able to run E scripts (*.e files) directly as executables. To check your bash version, type
$ echo $BASH_VERSION
On Windows, both bash and env are available as part of the Cygwin distribution, as explained below.
If you are only installing E from a binary distribution, or only rebuilding the Java portion for your own use, you can ignore this section. However, if you wish to build an E distribution from sources, then you will need the equivalent of the following tools as well.
The Cygwin Distribution
The E building process relies on a number of UNIX tools. These are available for Windows from Cygnus Support as the Cygwin package. If you wish to build E on Windows, you should download and install a version >= 1.0.
The E source distribution contains the executable binary program byaccj.exe for Windows, and byaccj for Linux/386/glibc. These are actually BYacc/Java from Bob Jamison and others. BYacc/Java is the Berkeley Yacc program extended with a "-j" flag and others for producing Java output. BYacc/Java is covered by the Berkeley License. The sources to byaccj are bundled with the E sources, and byaccj is optionally made as part of making E.
BYacc/Java is only needed if you wish to remake the parsers as part of making E. Usually, this is only necessary of you wish to edit the *.y files in the source tree (term.y and e.y). Since BYacc/Java is a C program, it was causing porting headaches, and most people interested in rebuilding E won't need to rebuild the parsers anyway. So we've added a switch: If you set the environment variable "MAKE_PARSERS" to "true" before running "make", then make will try to build BYacc/Java on your system, and then use it to rebuild the parsers. Otherwise, it will just use the parsers included in the source tree.
Our build process packs up the *.zip files in the distribution by using Info-Zip's highy portable, and highly ported, zip program. Info-Zip's zipping tools are open-sourced with a license that seems to resemble the X11 license, but before redistributing it, you should read it for yourself. The E distributions do not bundle in these tools.
The following are the main environment variables controlling building, and normally the only ones you will need to be aware of if something goes wrong. Others variables are documented in the various makefiles, especially makerules.mk.
Unless stated otherwise, all text on this page which is either unattributed or by Mark S. Miller is hereby placed in the public domain.