Let’s make this short and sweet:

The somewhat long-standing precompilation related bug in MoarVM has been fixed. This brings us quite a bit closer to Rakudo * on MoarVM.

A few memory leaks inside MoarVM have been fixed. MoarVM doesn’t rely exclusively on its own garbage-collected heap. It also uses malloc and free for things like C strings and it also has reference counting semantics for frames. These were a little bit buggy. During the core setting compilation, about 100 megabytes of ram are saved by this.

MoarVM got some improvements to its unicode database and now offers operations to query it directly. In combination with a few spec changes to the Unicode Synopsis and the corresponding tests, MoarVM is now the leading implementation in number of passing spectests.

jnthn has just implemented nqp::queuepoll on MoarVM and except for a bit of design work left for the scheduler, there’s not much keeping the moar-conc branches – containing concurrency support for MoarVM – from being merged.

Mouq has continued pushing more fixes and improvements to Pod6 parsing and rendering to rakudo and Pod::To::HTML.

Coke has recently started porting Mojolicious to Perl 6. So far it’s only the Mojo::Util package, but it’s surely something to keep an eye on for perl5 users.

What’s cooking?

pmurias has resurfaced and is currently preparing nqp-js for a merge into the main NQP repository.

rurban has started working on parrot performance. Just today he got NQP to compile on a parrot that uses -O2 (not gcc’s -O flag. This one is about the parrot imcc). He’ll probably be improving parrot’s performance for Rakudo and NQP in the near future. He has also said before that parrot’s concurrency model is vastly superior to MoarVM’s. The MoarVM developers don’t agree on that, but I’d love to be surprised.

jnthn said he’ll focus on unblocking Rakudo * on MoarVM and the JVM after the next bits of concurrency work, so that we will hopefully have a triple-backend Rakudo * release this month. This includes NativeCall for MoarVM, which will thankfully be a lot simpler than it was for the JVM. MoarVM and parrot rely on the same library to do this, so there may be a lot of copypesto to be had.

I finally got the tip I needed for how to properly implement cascading block inlining for the NQP optimizer, so I’ll try to get that up and running this week. It ought to improve performance and memory usage on all of our backends.

Low hanging fruit

If you’d like to help out, here’s a little nugget to get you started:

Our evalbot on the IRC server currently outputs the versions of the backends used whenever someone asks it to eval some code. Since we’ve got three backends at the moment, these lines can become quite long:

moritz | r: 1 +camelia | rakudo-parrot 1aeb7c, rakudo-jvm 1aeb7c, rakudo-moar 1aeb7c: ( no output )

It would be nice to have it output

rakudo-{parrot,jvm,moar} 1aeb7c:

instead. Camelia is written in perl5 and the source code can be found on github. I’ve started a naive implementation of this in Perl 6, but only perl5 code will be accepted into the evalbot at this point. I’m sure there’s an algorithmically nicer implementation that can be done, though.

Something else that could be done soon-ish even if you don’t have a lot of experience yet is implementing the “locallifetime” op on MoarVM to allow temporary locals to be released by the register allocator earlier.

Something that’s always appreciated is helping out with ecosystem modules. You can try one or two out, report and perhaps golf bugs, weigh in on design decisions, … Or you can port your favourite perl5 (or even python/ruby/…) module over.

If any of those tasks seem interesting to you, feel free to visit us on the IRC. We are on the freenode network in #perl6. I hope you’ll have a wonderful week, my esteemed readers 🙂