Continuum - ES6 virtual machine built in ES3
Le 11/12/2012 21:46, Brandon Benvie a écrit :
benvie/continuum - project benvie.github.com/continuum - debugger npm module 'continuum'
Continuum is a virtual machine for executing ES6 code (the spec is rapidly iterating so many things need updating). It's written in ES3 and targets a baseline of IE8 (debugger included). With a small amount of additional work it could run reliably in engines as old as IE6, but this hasn't been a priority.
Almost all ES6 features are supported to some degree: modules, Proxy/Reflect, Map/Set/WeakMap, generators, destructuring/spread/rest/default params, proto, classes, Symbols, Typed Arrays/DataView (all features work in any host engine that can run Continuum).
Awesome :-)
The only remaining features which are unimplemented are tail call optimization (incomplete and disabled pending some changes), array comprehensions, generator expressions, and new parts of the binary data API (structs, etc.). Some features are incomplete and potentially buggy, especially ones which are completely new and have a lot of surface area not covered by test262 (proxies
I've started a test suite at DavidBruant/ProxyTests It was just for me at first, so I started with QUnit (I'll probably change that eventually). My end goal is to write test for the internals of built-in algorithms; proxies exposes them, I'd like to be sure that there is some minimum test suite that shows spec deviations for these (and why not see if proxies make engines crash when applying built-in algorithms) There is only one branch and I'm in the middle of a refactoring :-s I think you can start with this commit DavidBruant/ProxyTests/commit/ea53adb659230219a29435a06254dcda2228d80f until I'm done with the refactoring (then, I'll use different branches and be more clean in my commits and history) Tests are aligned with the current direct proxies strawman. (not sure I'm 100% up-to-date when it comes to the enumerate trap signature, I'll have to check)
generators especially). I intend to start creating test cases for these features as soon as I finish fixing out the remaining test262 tests that Continuum fails.
I'd like to point out that I've sent feedback [1][2][3] after my work on the test suite. I'm more and more convinced that writing test suites is an excellent opportunity to see corners that weren't seen before. I'd say that this exercise is complementary to the spec editing work based on which Allen and wiki.ecmascript editors regularly sends feedback to the list too. I've posted (and Andreas before me) about built-in algorithms being frozen as soon as proxies are released. I take writing tests for that as an opportunity to carefully review these algorithms and maybe suggest changes if applicable. I don't think anyone really want to spend time reading algorithms and imagining how proxies would interact with them. Writing tests is a good excuse to do this exercise. And... there will be a test suite as outcome, but the way I see it, the process of writing the test suite is actually more important than the outcome itself.
So, yes, if you do want to write tests for any feature, I strongly encourage you to do so. I strongly encourage anyone reading this message to do so.
David
[1] esdiscuss/2012-September/024808 [2] esdiscuss/2012-October/025555 [3] esdiscuss/2012-September/025032
Agree with all you said. And practically speaking, if I intend to support these things in a piece of software I've written then somewhere, somehow, there needs to be a way to tell that they work. Right now there's a lot of things that ostensibly are supported by Continuum but for which the way to see if it works is to attempt to run code that uses the feature and see if it breaks or not.
benvie/continuum - project benvie.github.com/continuum - debugger npm module 'continuum'
Continuum is a virtual machine for executing ES6 code (the spec is rapidly iterating so many things need updating). It's written in ES3 and targets a baseline of IE8 (debugger included). With a small amount of additional work it could run reliably in engines as old as IE6, but this hasn't been a priority.
Almost all ES6 features are supported to some degree: modules, Proxy/Reflect, Map/Set/WeakMap, generators, destructuring/spread/rest/default params, proto, classes, Symbols, Typed Arrays/DataView (all features work in any host engine that can run Continuum). The only remaining features which are unimplemented are tail call optimization (incomplete and disabled pending some changes), array comprehensions, generator expressions, and new parts of the binary data API (structs, etc.). Some features are incomplete and potentially buggy, especially ones which are completely new and have a lot of surface area not covered by test262 (proxies, generators especially). I intend to start creating test cases for these features as soon as I finish fixing out the remaining test262 tests that Continuum fails.
The engine is currently completely unoptimized so performance is abysmal. I intend to persue optimizations following a strategy similar to how PyPy works, in tracing the interpreter and runtime and creating a JIT "compiler" that compiles with the host engine as the target and asm.js type code as the generated output. This is a parallel to PyPy's usage of RPython -> C.
In the process of filling out spec features, I have also been working on a number of special APIs for using information from the runtime for debugging purposes, mocking, and integration with the host environment. I'm also working on the foundation for a development environment built with Continuum as its core. These things may be found in the experimental folder of the repo.