pawelmurias at gmail.com
Tue Sep 24 19:09:47 UTC 2013
A cross compiling nqp-js (running on top of parrot) passes all tests
in nqp/t/nqp with the exception of test 49 (which does an equivalent
of eval, which would be really tricky do in a cross compiler).
It also passes the serialization tests in nqp/t/serialization.
It also passes the same tests as nqp-parrot in nqp/t/qregex.
We use a custom harness for those so to avoid compiling regex at runtime.
A standalone nqp-js (compiled with a cross compiling nqp-js and using
a setting compiled by a cross compiling nqp-js) passes most of the
tests in nqp/t/nqp (it fails 5 of them).
During the program I also extended the nqp test suite, implemented
nqp::shell on nqp-parrot.
Currently for building the nqp-js I'm keeping a nqp-compiler.nqp,
which is basically the most of NQP concatenated into one file. The
real nqp concatenates it's files into 2 gigantic files.
My nqp-compiler.nqp doesn't currently register itself using the
nqp::bindcomp ops correctly so it's failing the roles tests (url and
url) as that's needed for roles.
Some bugs are making test 32 fail on the standalone compiler.
Test 49 needs loading of the compiler and runtime.
And test 55 has some problems with cloning multi methods.
As the standalone compiler had trouble with roles and multi methods I
didn't get to create a bootstraped nqp-js (nqp-js compiled with
Running in the browser is mostly a matter of figuring out how to load
as I haven't got around to figuring that), and figuring out how to
replace our bigint dependency.
don't support anyway.
The short term things I plan to do now once the GSoC program has ended are:
* Instead of keeping a nqp-compiler.nqp in the repo build it (in the
Makefile) the same way as other backends do from the files in the nqp
* Finish bootstraping.
* Code cleanup:
I need to seperate stuff into more files, adopt some sort of
automatically verified coding standard on the js part (I have
experimented with adapting the Google Style Guide before).
I also need to make things stick to a naming convention. That is
decide where do use CamelCase and where to use under_scores.
Translating stuff from the real nqp which is also sometime confused
about that didn't help with that.
Middle term things:
* Write a nqptidy ;)
* Source maps. We need them to use fancy node debuggers I recently
* Optimalisations. Now that I figured out how most stuff works in nqp
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the parrot-dev