/ download

Download and Install E 0.8.13e

Jump to

Download by Platforms & Versions
Highlights this Version
Variants and Subsets of E
Dependencies
New environment variable documentation!

Are you sure you want the 0.8.13e version?

Download by Platforms & Versions

Earlier versions of E have been tested and run on MSWindows (95, 98 FE, NT, 2K), Linux, and now Mac OS X (which I think is really a FreeBSD platform). 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.

"class" Partially Deprecated. Long Live "extends"

For various reasons, we now think we made a mistake in advocating use of the "class" keyword for normal object definition. The reasoning was that E's true lambda-nature -- object/functions nested within object/functions in order to multiply instantiate state with behavior -- was alienating to programmers coming from the C/C++/Java/etc syntactic tradition. Experience has shown that "class", by leading one to expect a familiar concept and then failing to deliver it, was a cure worse than the disease. Better to be honest about nested definitions up front, and teach it well.

As we phase out "class" for normal object definitions, we will also be phasing out our use of "new" methods. Eventually, when you see a "new", you'll know you're either talking to a Java constructor, or to an E object that wishes to be polymorphic with one. Likewise, method definitions like "to newFoo(..) ..." will be changed, probably to "to makeFoo(..) ...", which reads as a proper verb-phrase.

To ease the transition, we continue to support the "class" construct, but in later releases it will define a "run" method to be synonymous to the "new" method it now defines, and we will consider this "new" method deprecated, to be turned off by default in a yet later release. (Even in this later release, a "pragma enable(<something>)" will preserve the generation of the deprecated "new" method.)

But what of the "class" construct itself? Should we deprecate it, and eventually have it appear only when enabled by a pragma? The "class" construct was originally introduced only to support inheritance by static delegation, and it still seemed to us to be well motivated for that purpose. But that was only until Dean started thinking about inheritance....

This release has an experimental new syntactic shorthand, the "extends" construct, intended to replace the "class" construct, as suggested by Dean. Since this issue has not yet been discussed on the e-lang list, this new construct is not currently an official part of the language, and must be enabled by saying

pragma enable("sub-object")

in order to enable it on a per module basis. Or you can set the property "e.enable.sub-object" to "true" either in eprops.txt or on the command line. Since this isn't yet an official part of the language, "class" is not yet deprecated for inheritance, but as of now, "class" is deprecated for use in normal object definitions.

Thanks to Steve Jenson and Zooko for insights about the confusion caused by "class".

Thanks to Dean for the "extends" proposal. (Once he starts the discussion on e-lang, I'll link to its root here.)

Licenses now cleaned up.

All code under our control has now been placed under the MIT X license. All other code in the E distribution is covered by a Mozilla compatible open source license. These cases are now enumerated. See the license page for details.

E now runs headless

Use the command line option "--headless".

For placement info on options to the "e" driver (a bash script), say "e --help". For placement info on options when running E from a Java command line, say "java -jar <ehome-directory>/e.jar --help".

The privileged scope created for a headless environment will no longer contain awt__uriGetter, swing__uriGetter, or JPanel__quasiParser, since these are not appropriate in a headless environment. At the moment though, these are still available by explicit importation.

This fixes bugs:

• why does DISPLAY have to be set?
• interactive E won't work over telnet/ssh
• Control of fe vs be vats
• "be" vats shouldn't have awt__uriGetter or swing__uriGetter

Thanks to the webmaster of cypherpunks.to for providing the impetus to make E run headless -- a remote FreeBSD machine with a Java 1.3 installed.

The "e" driver now defaults to "--interact"

If the "e" driver is invoked with no explicit script argument, this argument now defaults to "--interact".

Thanks to Dean Tribble for the idea, and Darius Bacon for the impetus.

Environment variable cleanup and documentation

The main environment variables for building E have now been documented below, and their use has been fixed so that one can now typically build without setting JAVA_HOME.

This fixes the bug compilation dependency problem.

Thanks to Zooko and Jonathan Rees.

E object definitions now have fully qualified names

For example, if the adderCreator example from the Ode were defined in the file foo/bar/adderExample.emaker, then the inner adder function will have the fully qualified name "foo.bar.adderExample$adderCreator__C$adder__C". This reflects the expected fully qualified class names that these will be translated to once we're translating to JVM bytecodes.

Besides compilation, these fully qualified names are expected to be used for a number of purposes:

• For generating javadoc-like documentation from E sources as well as Java sources.
• As a serialization type-tag, to support upgrade by unserializing.
• As a key for tracking vtables (the behavior part of an object-as-state-and-behavior), in order to support live upgrade for prototyping (like Smalltalk).
• As a tag for accumulating performance statistics, as explained below.

But what of anonymous object definitions -- those defined with "_" in the place of the name? Again tracking Java's algorithm for generating fully qualified names, these become sequentially-assigned numbers rather than names. (This is what Java does for anonymous inner classes.) Unlike Java, we don't consider such classes serializable or upgradable, since there's no reasonable correspondence between their fully qualified name and any names the programmer is aware of.

Eventually, if two object definitions in the same top-level expression would be assigned the same fully qualified name, this will be a static error that will prevent that expression from being evaluated (and therefore prevent that module from loading). However, since we're only now checking for this, E programs that are otherwise correct can easily fail this new requirement. So, for now, we instead issue a warning on stderr. For example, when capDesk.e starts up, it now also prints:

*** conflicting definitions of <main>.paster__C$done__C
*** conflicting definitions of <main>.paster__C$done__C
*** conflicting definitions of <main>.paster__C$done__C$done2__C
*** conflicting definitions of <main>.paster__C$done__C

These "done" objects are defined by the right-hand side of various when expressions. One need only rename these from "done" to something distinct.

Thanks to Dean for advice on these issues.

New "e.interp.print-timing" property

If you set this property to "true", either in the eprops.txt file or on the command line, then, when E finishes execution, it will print how much time it took after initialization, and it will print an invocation count for all E-invoked methods and matchers that are in the top 1 percentile of E invocation counts.

In other words, everything called through the E invocation mechanism maintains a count of how many times it was E-invoked. This includes all methods and matchers defined in the E language, and all Java methods as invoked either from the E language or by the E.call(...) or E.send(...) mechanisms. Actually, each maintains two counts -- one for those that exit normally, and one for non-local exits (throws and escapes). These counters can also be reset, and so can be used for crude coverage as well as performance analysis.

If the "e.interp.print-timing" is "true", then at the end of the run, every count that is at least one percent of the total count is printed out. This is useful now, while we're interpreted, as this is an aggregation not available from Java-based performance analyzers like OptimizeIt. Once we have a compiler, we will probably phase this out, since the stock tools will do.

Thanks to Dean for yet more advice.

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:

Bash

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 as "/bin/bash". The E driver script is required in order to be able to run E scripts (*.e files) directly as executables. To check your bash version, type

$ echo $BASH_VERSION

to your bash shell. A bash (2.05 as of this writing) for Mac OS X is available for download from Savage Transcendental Studios.

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/Java (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. 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 as of this release we 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.

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.

Environment Variables

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.

• OSTYPE - To determine whether we are compiling on the Cygwin platform, we check whether this is set to either "cygwin" or "cygwin32" (both have been encountered). If so, we set CYGWINOS to "1". All other conditionals test CYGWINOS.

• CYGWINOS - See above. If you actually are on a Cygwin environment, but OSTYPE has yet a different value, you probably shouldn't change it for fear of screwing something else up. So just set CYGWINOS to "1" yourself.

• JAVA_HOME - If set, it should be set to the directory where the JDK is installed. This is used to find certain executables and jar files that come with the JDK distribution.

  If not set, then the needed executables (eg, "java") are assumed to be on the PATH, and the jar files directly known to the makefiles are assumed to be adequate for building. This is known to work when compiling with javac, and known not to work when compiling with jikes 1.15. See below.

• JAVAC - If set, should be set to executable for the Java compiler. The Java compiler is assumed to be command line compatible with javac or jikes. If the executable is on the PATH, then simple names (like "javac") can be used rather than full pathnames. This can also include some initial compiler options to appear before the others. I normally build with JAVAC set to "jikes +E +F". I'm using Jikes 1.15, and at least that version needs to be provided with the JDK's rt.jar file as an explicit component of the -classpath argument. The makefiles do this automatically if JAVA_HOME is set to the JDK's install directory.

  If not set, this defaults to either "javac" or "$(JAVA_HOME)/bin/javac", depending on whether JAVA_HOME is set.

• JAVACMD - If set, should be set to an executable for running Java that's command-line compatible with the JDK's "java" executable.

  If not set, this defaults to either "java" or "$(JAVA_HOME)/jre/bin/java" depending on whether JAVA_HOME is set.

• JAVADOC - If set, should be set to an executable for generating Javadoc documentation that's command-line compatible with the JDK's "javadoc" executable.

  If not set, this defaults to either "javadoc" or "$(JAVA_HOME)/bin/javadoc" depending on whether JAVA_HOME is set.

• MAKE_PARSERS - E contains a small number (two as of this writing) of *.y files, which are compiled into parsers written in Java using BYacc/Java (see above). The generated parsers are included in the source distribution as sources, even though technically they are not, because most people interested in rebuilding E will not care to rebuild these parsers.

  Those that do wish to rebuild these parsers should set MAKE_PARSERS to "true". This will cause the BYacc/Java executable, byaccj, to be rebuilt from sources, and will cause these parsers to be rebuild from their *.y files using byaccj. The BYacc/Java sources seem to have problems compiling on some platforms. If you encounter such problems, and especially if you figure out how to fix it, please let us know.

  If not set, this defaults to not rebuilding byaccj or the parsers, but just using the generated parsers included in the source distribution as sources.