User:ThomasLeonard
From Erights
(Difference between revisions)
Line 10: | Line 10: | ||
Other patches/branches: | Other patches/branches: | ||
- | * Make CapTP shutdown when its vat is shutdown (on next) | + | * [http://www.eros-os.org/pipermail/e-lang/2010-October/013647.html Make CapTP shutdown when its vat is shutdown] (on next). |
- | * | + | * [http://www.eros-os.org/pipermail/e-lang/2010-September/013620.html Split Scope] into Scope (internal data structure for the E interpreter, including local variables, etc) and EEnv (simpler structure exposed to E code, replacing safeScope, etc). This avoids the need to tame access to these objects and hopefully makes the code easier to read. |
- | + | * Various possible optimisations are on the '''compiler''' branch (these mostly have only a small benefit or don't work fully; otherwise I push them to next). These optimisations work for both the current E interpreter and for a possible future E compiler. There is also a very old wip-compiler branch that actually does compile E to JVM bytecode. However, it turned out that the major performance problems were elsewhere. |
Revision as of 11:57, 9 November 2010
I'm using E for two separate projects:
- At IT Innovation, for some of our experimental work on service oriented architectures.
- At 0install.net, as a demonstrator showing how to use 0install to run sandboxed applications with distributed dependency handling.
Branches
I publish my patches to my E Git repository. The next branch generally contains things I consider ready for merging into the E svn repository.
Other patches/branches:
- Make CapTP shutdown when its vat is shutdown (on next).
- Split Scope into Scope (internal data structure for the E interpreter, including local variables, etc) and EEnv (simpler structure exposed to E code, replacing safeScope, etc). This avoids the need to tame access to these objects and hopefully makes the code easier to read.
- Various possible optimisations are on the compiler branch (these mostly have only a small benefit or don't work fully; otherwise I push them to next). These optimisations work for both the current E interpreter and for a possible future E compiler. There is also a very old wip-compiler branch that actually does compile E to JVM bytecode. However, it turned out that the major performance problems were elsewhere.