Re-added imcc optimizations


-O1 and -O2 were previously disabled with some more imcc options. I enabled and fixed all of them. Even -O2 is now stable.

app-parrot-create weekly report

At this week I was working for update tests and documentation on my project.
On the other hand I'm working on opened issues from dukeleto. Such as

I've done all task that we planed with dukeleto.
The future plans are going to work with issues that remain and deploy for enterprise work.

Final GSoC report

What's done?

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 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).

app-parrot-create weekly report

At this day I have done my work. The last task which I provided it's a build with perl 5 language.

This is a final week at GSoC, so I will plan to write more tests and update documentation.

The last version of my project you can test on

Future plans:
- update API, realization a garbage collector(automatical remove old content) on my app
- realization an automatical deploy system on WebServer

GSoc progress report

Got the nqp/t/qregex tests to pass.
It would be a good idead for me to document how the rules engines of the MoarVM, Parrot, JVM and JavaScript backends work.
They are pretty similiar as it's basically the translation of the same code.
Unfortunately some things get cargo culted.
Like parrot registers names ending up in MoarVM code.

This means the rules engines implementation is resonably sane.
Incorrect test description caused a lot of confusion.

app-parrot-create weekly report

At that day my project have almost done. In previous few week I worked over different type of tests. It are Rosella(Winxed), Rosella(NQP) and Perl 5 tests for HLL and library templates. - rosella(winxed) tests on library template - rosella(nqp) tests on library template - perl 5 tests on library template

app-parrot-create weekly report

At this week I've updated a build system for HLL with winxed language. This is shown on that commit

I started work on library template file. This template is almost the same as the hll template file. So it wouldn't be hard to provide all features from hll template file.

At that day the main blocker is a rosella test system. It's not work on my PC for all parrot project, which I've built(parrot-libgit2,parrot-lapack,parrot-plumage).

GSoc progress report

All tests in nqp/t/nqp with the exception of test 49 are passing.

Test 49 among other things requires compiling regexes at runtime.

my $regex := "a+";
"aaaaa" ~~ /<$regex>/;

This is easy to do after bootstraping (when we have the whole compiler avaliable at runtime) or a bunch of crafty hacks.
After attempting to quick hack a workaround (which would involve starting up a new parrot process to cross compile a regex) it turned out our current cross compiling solution won't work. I decided to avoid waisting time on that and leave it to after the boostrap.

t/nqp directory in the nqp repository contains all the tests for the NQP language features.
There are also tests in t/qregex which are really a whole bunch of regex and their expected results on a suplied string.
(in a tab separated format + a harness).
And 3 tests in t/serialization which would involve a boring translation of serialization code from a different backend.

What seems to be a good direction is to get all the tests qast tests (which were written by Jonathan while porting nqp to the jvm) under JavaScript. They test the backend without requiring a parser. Doing that has uncovered a number of bugs in nqp-js. Major things like multi methods seem to work correctly but I have encoutered many small bugs. Which seems to imply that the nqp test suit needs to be more exaustive.
A few examples of those and their fixes:

nqp::null() was tested for truthfullness is some places, we are currently doing that using a .Bool method so I had instead of using a native javascript null switch to using a custom singleton for that.

Objects being false by default caused if $slurp {...emit some code for slurp...} not to work

\n not being implemented in regexes caused subst(/\n/,"\\n",:global) to loop infinitly:

Currently in nqp-js I'm using JavaScript arrays as nqp arrays (with a bunch of methods monkey patched on top of them).
That caused a problem as JavaScript alread has a push and unshift methods (hinting that it was somewhat inspired by Perl 5).
The tests thus far where using the nqp::push op for adding elements to arrays.
However QAST::Compiler::JavaScript uses the .push method
Example: nqp::push(@foo,$value) vs @foo.push($value).

My current calling convention is that $"named"),1) is translated to $,{"a":"named"},1).

Which ended up in strange things being added into arrays (Which resulted in some fun debugging).

app-parrot-create weekly report

A few last weeks, I'm working to support build system with different languages. Such as PIR, NQP, Winxed and Perl5. At this day a build system supported PIR, NQP and Winxed languages with pmc, ops and doc optioms each other. shows a changes which need to support a build system with nqp language. shows a changes which need to support a build system with winxed language.

app-parrot-create weekly report

At this week I'm working with different deploy systems.
Such dotCloud, gnu Compile Farm. I'm changing my project for that deploy systems.
As a result of this work is

So I can continue my work for providing a different build and test system on my project.
I'm going to continue my work on support a winxed build and test system on my hll template file.

Syndicate content