Paweł Murias

After fixing some strangling bugs and implementing some unimportant but fickly to implement
features rakudo.js now passes our targeted test subset. Some of the fickly features where
things like basic support storing fetching and ++'ing int64/uint64 variables etc. (rakudo.js is 32bit because that's what fits into basic JavaScript numbers).

Focus has now moved to running the roast tests in the browser itself.
For this I'm first precompiling the test files (which has it's own share of problems that I'm working around as rakudo doesn't yet fully support precompling scripts only modules).
For example all the compile time deps are recorded with a custom CompUnit::Repository
Then I'm bundling them together with parcel into a single .js file.
I'm running it with a Karma runner and Headless Chrome.
When running under karma the nqp runtime intercepts the TAP on STDOUT and reports the results to the karma harness.

While the underlying JavaScript VM is the same, there are some still some browser idiosyncrasies to solve.
As an example I'm currently I'm working on making &is_run work. A lot of tests use it to start up a new rakudo process, possibly passing some arguments and data on standard input and intercept it's output. Obviously in the browser we can't start a new rakudo and it needs to be faked.

In other news 6pad now supports basic DOM access (https://perl6.github.io/6pad/#4ee170f8043efe4802c8e6fb55d6a187), I'm planning some exciting stuff for 6pad but that's for the next update.