Sorry for the long silence here.  My autumn was a mess, and my winter was buried in snow.  In all that time I have kept working with Perl 6, and things actually keep on getting better and better, which is quite exciting.

One really exciting thing for me is rakudobrew.  tadzik’s lovely little script makes it easy to build and rebuild multiple different versions of rakudo and switch between them.  In the past, keeping up-to-date with Rakudo was a matter of typing and executing four commands, the second of which was very fiddly to remember and type.  Now it’s just
rakudobrew build moar and everything moar-related is updated, including all your installed modules.  That may sound like a small change, but it works and it’s terrifically handy.

So, last night I tried to move the module smoke tester to using rakudobrew.  This allowed me to delete nearly half the lines in my smoke_test script, and added the potential to test all three of rakudo’s backends instead of just Parrot.  However, I ran into problems on all three backends, none of which are rakudobrew’s fault.

First and most vividly, rakudo under parrot is completely broken at the moment.  benabik++ tracked down the breaking patch two days ago.  It’s been broken since May 1st.  It really says something about the current state of rakudo use on parrot that almost nobody seems to have even noticed this.  (Hint: I’ve been using rakudo on moar for pretty much everything for a month or two now.)

rakudobrew does a beautiful job building and installing rakudo on moar.  However, the module smoke test (which tries to install every module) fails because installing File::Find breaks the module system, possibly because File::Find is used in that installation process.

==> Successfully installed File::Find
Invalid opcode executed (corrupt bytecode stream?) opcode 4352

This one has been the case for a while now.  Last night I was hoping I could get around it by just having emmentaler (the smoker) specifically skip testing File::Find, but it turns out a number of other modules depend on it.

rakudobrew built the JVM version of rakudo with no issues.  But the smoke test ran very slowly and died after making it through a few modules.  I haven’t really had time to look into this one, just wanted to mention it.

One other issue I’ve been bumping into, again not rakudobrew’s fault but making it less than perfectly awesome on OS X.  When you build rakudo on moar on the Mac, the makefile dies with the message make: write error after it has finished building and installing rakudo.  Attempts turn on make’s debugging tools cause a seg fault.  This is pretty innocuous when you’re building by hand, but rakudobrew actually (implicitly?) checks the results of the make, and stops before going on to rebuild the modules.  As nearly as I could tell, this seems to be an actual bug in GNU make on OS X, but I have no idea how to make further progress fixing it.

This may sound like a lot of complaints, so let me close by pointing out how amazingly awesome the progress has been in the last year.  I don’t know that anyone but jnthn believed in early May last year that we’d have rakudo fully working on JVM and yet another backend by this time.  Rakudo on moar has become clearly the best Perl 6 we have.  For ages I’ve needed to keep Niecza around to handle a few things that rakudo couldn’t do, but rakudo on moar is rapidly overtaking it.  And development continues at a furious pace.  This is really a great time to be a Perl 6 user.

One Response to “rakudobrew”

  1. 2014.18: More supply ops, loop labels, more async I/O on jvm | Weekly changes in and around Perl 6 Says:

    […] wrote a bit on tadzik’s rakudobrew on his […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: