Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. Parrot is not about parrots, though we are rather fond of them for obvious reasons.

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

parrot-libgit2 report: References, Trees, Remotes

This was a fairly productive week, with many new features.

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

Parrot-libgit2 report: Using parrot-libgit2

Now that a minimal api is ready, its time that I document how to use it:

Its possible to use the library to deal with repositories, the repository index, low-level object access, commits, revision walking, blobs, git configs and more. Major things that are still not done are dealing with references and trees, which are only waiting on a few issues(mentioned below).

These are rough examples of how to use the major classes.

Opening repositories:

using Git2.Repository;
var repo = new Git2.Repository("/path/to/repository");

Dealing with the index:

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

Parrot-libgit2 report

This report comes rather late, so let me give an overview of what's been happening.
The last report talked about an unified buildsystem. Since then the project has made a little progress. There were bugs in the unified buildsystem which meant that that the pir file which was generated from the nci file was stale at best, representing older versions of libgit2. This made a lot of work go down the drain, as a lot of my debugging was aimed at sending the correct datastructures. However this was a good step in finding my mistakes and moving ahead.

Syndicate content