[E-Lang] Announcing the Interim Internal E stl-0.8.9p Release
Mark S. Miller
Fri, 09 Feb 2001 06:08:46 -0800
This release was sponsored by openCOLA. THANKS!
Available at http://www.erights.org/download/stl-0-8-9-p/index.html .
The driving purpose of this release is to overhaul the process for
installing and running E, to segregate the platform dependencies, to make it
easier to get going on a new platform, and to move as much of the
installation process into E itself as we can manage.
(Chris, I'm especially interested in your feedback as to how this relates to
the Mac porting effort. And, of course, we need to reconcile. Maybe
sometime the week of the 19th? And btw, I can't believe I forgot to say
this. You got it working on the Mac, Congratulations!)
Previous releases, evolved from the Java 1.1 days, required an unpleasantly
long command line to invoke E. This in turn forced the creation of a
command line driver, e.exe, which forced the creation of an installer,
setup.exe, written in C, to get everything installed so the command line
driver could find everything it needed to work. But only on MSWindows of
course. We had a different procedure for Linux based on some bash scripts.
(With much thanks to several, especially Danfuzz, for help with these scripts.)
Now that we require Java >= 1.2, I turned e.jar into a self-launching jar
and got rid of setup.exe and e.exe. After unpacking, if you just double
click on e.jar, it should figure out that it's not yet properly installed,
and it'll run the E script "setup.e".
setup.e will check what platform it seems to be on, and dispatch to
platform-dependent E installation code. The only such platform currently
supported is MSWindows, which means that shortcuts and file-extension
associations will be created on MSWindows, but not yet elsewhere. (File
extension associations give a file double-click launching and right button
menu behavior based on its extension.) To create these from E on MSWindows,
I broke the old C install code into a bunch of separate executable commands
(see bin/win32/*.exe), and I invoke these commands using java.lang.Process.
Outside of MSWindows currently, you don't have these, but this is no longer
fatal. However, it's not yet pleasant. See the README.txt file in the
binary distributions to find out about the manual procedure currently
required. This will improve rapidly.
Anyone know how to create file extension associations from KDE or Gnome? Is
it per desktop environment, or is there a more widely accepted way to do
this? Can it be done from Java? What do people actually do about the
inevitable name space conflicts in this tiny name space? On MSWindows I
grab the extensions *.e, *.emaker, *.updoc, *.vat, and *.cap. I'd like to
do the same in general.
Thanks to Dean for a conversation about the old installer that helped me
figure out how to structure the new one.