/ download

Download and Install E stl-0.8.9k

Jump to

Highlights this Version
Variants and Subsets of E
Dependencies
Download by Platforms & Versions

Are you sure you want the stl-0.8.9k version?

First, the anti-highlights

E stl-0.8.9k is an interim non-distributed release, but supporting a more modern version of the E language spec. It's primary motivation is to support work on compiling E, but it may also be preferred by those using E for non-distributed programming.

The E installer is much improved for MSWindows, but these improvements have not yet been ported to other platforms, so this release is an MSWindows-only release. This is a very temporary situation -- the vast majority of E is fully platform independent.

As of this version E only support Java >= 2 (ie, a JDK/JRE >= 1.2).

Highlights of this Version

The following is a list of the names of the major changes, but without yet any explanations. As each change is explained in the upcoming release notes, the item below will be linked to that explanation. Most of these notes will be messages to the e-lang list, so the link should also serve as the root of a discussion about each change.

• This is the first version of E supporting locally untrusted code
• Closer conformance to the Kernel E spec
• Closer conformance to Marc Stiegler's draft book E in a Walnut
• Experimental bundling of the Waterken Hydro 2.0 capability-oriented collection library
• New Minimal-XML DOM tree and QuasiParser
• Concurrency improvements
  • Extended when-catch syntax
  • Extensible Promise architecture, enabling CapTP to be rewritten in unprivileged E code
  • The Dead Man Switch
• Improvements to the "e" driver program
• Installation improvements (MSWindows only for now)
• Syntax changes, including
  • a lighter-weight syntax for anonymous closures.
  • "typedef" for describing object protocols
• And, as always, various terminology changes

Variants and Subsets of E

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.

This release is space-time-local, meaning it is non-distributed and non-persistent, and so is prefixed with "stl-". Being non-distributed, this release is much less useful than the 0.8.9 release. This version is being released mainly to support work on compiling E, since its interpreter conforms more closely to the definition of Kernel-E. If this is not a concern, you should probably stick with the 0.8.9 release.

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 bundling a subset of the Cryptix library. In a space-local system, no distributed insecurity can arise, so such a system would be an sl-E rather than an sl-daffE. This release is non-distributed and so is an E rather than a 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 the first version of E to support this feature, including confinement, and so is the first that doesn't need to be prefixed with "otc-".

Dependencies

Versions & Types of Java

In referring 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.

Starting with this version, E requires a jre >= 1.2.x. E no longer supports Java < 1.2. To build E from sources, a corresponding jdk is required. We recommend one >= 1.3.x. In particular, we recommend against 1.2.2. (Sun's Swing implementation in 1.2.2 does not, ahem, live up to Sun's usual quality standards.)

E makes heavier use of Java reflection than most Java vendors have encountered. Some implementations of Java (like IBM's VisualAge 1.1.7) have failed to run E because of bugs in their implementation of reflection. As you encounter information to add to the table below, please let me know.

Some places to get some a jre or jdk:

Versions of Cryptix

This release of E bundles in a subset of the Cryptix 3.1.1 strong cryptography library. However, since this E is not distributed, it doesn't depend on it, so the version issues (Cryptix vs JDK1.3) don't matter for this release.

Versions of Swing

Now that we have dropped support for Java < 1.2.x, the Swing package path issue should no longer matter. E depends on Swing as it appears in Java >= 1.2.x.

Build-Only Dependencies

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.

BYacc/J (Berkeley Yacc for Java)

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. If you are on a Unix system other than glibc Linux, you need to download your own version of byaccj and overwrite the one in src/bin/linux-386-glibc that our Makefile is using.

Zip Files

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.

Download by Platforms & Versions

Earlier versions of E have been tested and run on MSWindows (95, 98 FE, NT, 2000), and Linux. It should run with minor porting effort on other UNIX platforms. Pervious versions have also experienced problems on Windows 98 SE that we're not sure if we've diagnosed, but we hope those are fixed as of this release. It should also run without problems on MSWin 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.

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.

javadoc.tar.gz contains the javadoc-umentation of the ELib Java API, obtained by Javadocing the E source tree.

In the very near future, we will once again have the Linux row filled in. If later future releases, we hope to fill in the rows of the table for FreeBSD and Macintosh OS X. Much thanks to Charlie Evans for donating a Mac G4 to the E project to make this possible.