/ download

Download and Install E 0.8.10beta1

Jump to

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

Are you sure you want the 0.8.10beta1 version?

Download by Platforms & Versions

Earlier versions of E have been tested and run on MSWindows (95, 98 FE, NT, 2K), and Linux. 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 98 SE and on 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.

Highlights of this Version

As each of these issues are discussed in email or in the bug tracking system, we will link the paragraphs below to the relevant roots.

Term / Functor Trees

As of this release, we have finally chosen a universal abstract syntax tree representation that we can live with and use as a flexible basis for quasi-literal-based match-bind-substitute programming. Our choice leverages Antlr, and resembles Prolog term trees.

At first, we tried to be politically correct, and use a standard compatible subset of XML as a basis, as documented here.

Added Syntactic Support for Collection Derivation

*** Move this explanation somewhere else, and link to it from here.

We have long planned to retire FlexMap and FlexList as abstractions for normal programming, instead planning to depend solely on immutable collections, probably based on Hydro. This requires one to make "changes" to a collection by derivation of a new collection from an old one, rather than modifying the collection in place. Whereas with a FlexMap, one might say

def map := #... a FlexMap
...
map[key] := value

Using only ConstMaps, one would instead say

var map := #... a ConstMap
...
map := map with(key, value)

Instead of modifying the collection, we modify the variable to hold a new collection derived from the old by the 'with' message. Unfortunately, for an operation this ubiquitous, the latter notation is a bit too awkward. On the e-lang list, we've had a long discussion about various alternatives, all of which could be said to have been disqualified in one way or another (*** need link). At the end of the day, I had to chose one, so I have. As of this release, one can express the last line of latter example with the following syntax:

map with= (key, value)

In fact, one can append an '=' to any message name to get this effect, by analogy to how

x += 1

is equivalent to

x := x + 1

Many bug fixes

• xx

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.

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.

Dependencies

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 with "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.*. Once installed, E should work fine with either JDK1.3.* or JDK1.4beta.
( Track this issue... )

Some places to get a jre or jdk:

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.

Note: The website at the above link, http://www.lincom-asg.com/~rjamison/byacc/, seems to have disappeared. If you know where it may have gone to, or know how to contact Bob Jamison, please let me know. In the meantime, starting with the 0.8.10beta1 release, the sources to byaccj are bundled with the E sources, and byaccj is made as part of making E.

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.