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.

I have started hacking on my GSoC project to create a JavaScript backend for NQP (a Perl 6 dialect), which will be grown into a full one for Rakudo in the future.
Today I have unbitrotted the existing code at https://github.com/pmurias/rakudo-js by handling QAST::Var's with decl set to "static" (variables that don't change at runtime) the same as ones with "var" (normal ones). As such I have completed the first of 15 inchstones ;)

This was my first week of GSoC working on parrot-libgit2. parrot-libgit2 is aimed at providing a low-level PIR binding to libgit2 as well as high-level winxed bindings. The schedule is available here. Duke Leto wrote the initial code a couple of years ago, but since then the code had bitrotted.

Shows how to debug into crazy string encoding problems, when you are not sure if the core implementation, the library, the spec or the tests are wrong. It turned out, that the library and the tests were wrong.

Tomorrow is google's appointed 'firm pencils down' date. That seems like a good time to discuss the results of my work on mod_parrot so far.

mod_parrot is, as I have mentioned before, a two-layered system, with one half interfacing with apache (the module) and the other half with the interpreter and the compilers, the 'loader'. There is also a vital third component, the test system called pudding.

This week I finally got arround to giving a new, fresh structure to the mod_parrot module code. I have complained, perhaps not loudly enough, about the various inadequacies of the old codebase, mostly with regards to extensibility. A cleanup was needed. As such, here is a walkthrough of the new structure, also serving as documentation.

I for one am totally for whimsical blog titles, wouldn't you agree? In other news, after a lull of two weeks (codewise at least) I've finally started to work on mod_parrot again. The big (dis)?advantage from not working on code is that you start to think more of what you could do (and should have done), rather than what you have done.

As it turns out, I handle interpreters in a rather confused manner. My goal for the next two weeks is to fix that. First, let me describe what should be done to correctly run a script on an interpreter using mod_parrot:

I appear to be continuing my weekly blogging every 14 days. Ah, well. My progress has been fairly intermittent as I work out this whole "getting sleep with a newborn around", but I'm starting to make real progress again. Today's blog will discuss what I've done in the last couple weeks and an updated schedule for the next month.

My progress can be split into a few topics: syntax highlighting, style changes, bug fixes, test helpers, and tests themselves.