Polish Perl Workshop status update

Exactly two months remain until Polish Perl Workshop this year. In case you didn’t know, I’m shamelessly reposting the status update from our ACT website.

We’ve got the first sponsor offers, and about 15 talk submissions so far. Awesome! However, as we are well aware that most of you will wait to submit talks until there’s less than 2 days until the deadline (or later :)) I’m hereby announcing: The talk submission deadline for Polish Perl Workshop 2013 is 14 of April. That’s about two weeks to finally make up your mind and submit something. Please do! There’ll be only one chance to talk at the First Polish Perl Workshop: there’ll be no other :)

Of course, if you’d prefer to organize more of a hands-on event, we have the entire sunday dedicated to hackathon, BoFs, classes etc. If you want to submit something more lenghty, that’s the right way to do it.

In other interesting news, we started looking at conference t-shirts (yes, they’re free for all attendees). We have something on our mind that never happened before on a Perl conference (or at least I’ve never seen or heard of something like this). We’ll keep you informed.

Threads for Rakudo Perl 6

So it has come to this. Threads.pm is up and running, bringing the ever-wanted threaded execution to the most popular Perl 6 implementation.

You’re looking for TL;DR, aren’t you? Here’s what it’s capable of:

use Threads;
use Semaphore;

my @elements;
my $free-slots = Semaphore.new(value => 10);
my $full-slots = Semaphore.new(value => 0);

sub produce($id) {
    my $i = 0;
    loop {
        $free-slots.wait;
        @elements.push: $i;
        $i++;
        $full-slots.post;
    }
}

sub consume($id) {
    loop {
        $full-slots.wait;
        my $a = @elements.shift;
        $free-slots.post;
    }
}

for 1..5 -> $i {
    async sub { produce($i)  }
}

for 5..10 -> $i {
    async sub { consume($i) }
}

Doesn’t look that awesome. I mean, it’s just a producer-consumer problem, what’s the big deal? Let me repeat:

OMG, RAKUDO HAS WORKING THREADS.

So, once we’re done celebrating and dancing macarena all around, there’ll always be someone to ask “hold on, there’s gotta be a caveat. Something surely is missing, explain yourself!”

I’ll be delighted to say “nope, everything’s there!”, but that’d make me a liar. Yeah, there are missing pieces. First, those aren’t really native threads – just green threads. Native OS threads are already implemented in Parrot VM, but NQP (the language that Rakudo is based on) still doesn’t support them, so before some volunteer comes along to fix them, you’ll still have to build parrot --without-threads (which means: use green threads, not OS threads) for Threads.pm to work. But fear not! The API is exactly the same, so once native threads are there, both Threads.pm and the code you write with it should work without any changes.

But green threads are fine too! Except for one minor detail: whenever any of them blocks on IO, the entire Parrot comes to a halt. The plan is for Parrot threads scheduler to handle it nicely, but it’s not there yet, so if you expected nice and easy async IO, sorry, but you’re stuck on MuEvent :)

Yep, we’re not really there yet. But I claim it’s closer than ever. We have working threads implementation. You can write code with that, and it’s not a PITA. Go for it! There’s a lot of room to improve it. I didn’t try really hard for Threads.pm to follow the concurrency synopsis (in my defense, I think niecza doesn’t follow it either :)), and I think that once we unleash a wolfpack of developers which can work towards something that we’ll all love to use.

Back from Oslo

And so the hackathon is over. I haven’t experienced anything this awesome since I discovered how well bacon tastes with maasdamer.

I seem to be much more productive during hackathons if I have no talk to prepare. I’ve had lots of plans about it (see previous post), and while I haven’t started even half of them I think, I’m really satisfied with what was achieved.

On friday I looked a little bit into how Rakudo loads precompiled modules and why doesn’t it always work as expected. The easiest one to notice was Test.pm, which for some unknown reason was installed only as a source file, not a precompiled module. A simple fix in the Makefile, and suddenly every test file you ever run runs about 3.5 seconds faster. Suddenly it makes module development a lot less painful.

The other thing about module loading was that a lib/ directory was always at the very beginning of the @*INC array – that means that precompiling your modules (which usually puts them in blib/) before running your tests gave you… right. Absolutely nothing. How significant is that? Well, tests of Panda take just under 7 seconds when you have the modules precompiled, and almost 23 seconds when they aren’t. So that’s about 3 times faster test runs for your modules. How cool is that?

That solved pretty much all the issues and wtf’s I’ve experienced with module precompilation. It took me another commit on saturday to teach panda to precompile modules again. Then my mind wandered again around the idea of emmentaler, a service for automatic smoke testing of Perl 6 modules. A quick and dirty 100-lines long script is now able to download all the modules, test them and present the results in a bit silly, but definetely useful way. There’s still lots of things to be done about it, but the fact that you can test all the modules in about 20 minutes is something that wasn’t quite possible before. Huge success; I hope I can turn it into something that the whole community will benefit.

Saturday also brought a couple of fixes to Pod handling and the –doc command line switch. After a quick discussion with Damian Conway, sort of a “what does the spec really expect me to do”, I taught –doc to Do The Right Thing whatever argument you pass to it. So –doc=HTML will use Pod::To::HTML for Pod formatting, and whatever module you write is available to be used this way without changes neither in Rakudo nor in the module code itself. A small thing, but something that waited much too long to be done after GSoC. It should now be possible to extract documentation from modules in a simple, automatic way, possibly for inclusion on modules.perl6.org or somewhere? We’ll see about that.

The same day Marcus Ramberg worked on Pod::To::Text, in particular the .WHY handling part. He also contributed some patches to Rakudo itself, and thanks to him what –doc prints for documented subs and methods is actually Something Useful and not Something That’s Good That It Exists. Much appreciated!

Sunday brought some new fixes to Bailador::Test, which now does almost everything that Dancer::Test does, so some brave soul could actually start porting tests from Dancer to Bailador to see what blows up. I’ve also spent plenty of time (mostly compilation time) chasing small things like a few-months-old panda bug, which actually turned out to be a Rakudobug, making perl6 –doc behave a bit more like perldoc, and less like “what the hell does this beast do”, and some other small things.

Besides hacking there was also plenty of opportunities to walk around Oslo, try some delicious food and beer and meet people mostly known from IRC before. Social aspect of the Hackathon was probably the best part of it, even given the fact that the coding aspect was probably the best one I’ve ever experienced. This wouldn’t have been possible without the work that the organizers have put into the event. It was absolutely perfect. Thank you, Oslo.pm! And thank you, sjn for giving me the opportunity to be there. It was a great hackathon and a time well spent. I hope to see you guys sooner than later. And if later than sooner, let it be the next hackathon in Oslo, for there’s no way that I’ll let this one happen without me.

Plans for the Perl 6 Hackathon in Oslo

The Perl 6 Patterns hackthon in Oslo is happening next week, gathering most of the Rakudo developers. Awesome!

I’m still looking for the thing I’d like to work on during the event. The first obvious thought is Bailador, the Perl 6 port of Dancer web framework. It’s getting more and more in shape, and I’ve recently started looking through the code of Dancer 2 to see how it all should be done. I really don’t want Bailador to share a fate of neutro (ie reaching a state of being a horrible, unmaintainable mess), and I feel that it’s time for it to be refactored a bit. It came to life as a 10-line module written on a piece of paper during my Spanish classes, and simply adding more and more features to it is not going to end well.

Moritz Lenz is planning to hack on database stuff, which combined with a useful and usable web framework could create a nice platform for web development in Perl 6. I’ve already heard people saying “well, I could write Perl 6 apps if it had a web framework and some database access”, so I guess it’s time to show off something suitable for web development, even simple, but usable and covering most usage scenarios.

While we’re at the Web-y stuff, one thing that we really miss is a good (or at least good-enough) templating engine. Bailador has been using Ratel for some time, yet for one it stopped working on Rakudo recently (it was probably relying on some buggy or incorrect behaviour), and it suffers the problem of having no maintainer (no one really claims ownership of it). Hitomi was to be a templating engine for the new age, so maybe it’s about time to bring it back to life in all its glory? One could definitely find something to hack on.

From the new things, but still related to web development, zby has proposed porting WebNano to Perl 6 as one of the hackathon projects. It’s not something very big, and it should be totally possible to rewrite it in Perl 6 to run on Rakudo.

Or maybe there is something you particulary want to see in Perl 6? I’m sure we’ll not lack people with tuits; what is there that could possibly make Perl 6 a useful tool for you, something that you were missing when you last looked at it?