Archive for May, 2014

JVM weirdness

May 8, 2014
Compiling lib/ABC/BrokenRhythm.pm to jar
===SORRY!===
Function 'ABC::Note' needs parens to avoid taking the block
at lib/ABC/BrokenRhythm.pm:36
------>             }⏏<EOL>
Missing block (apparently taken by 'ABC::Note')
at lib/ABC/BrokenRhythm.pm:37
------>             ⏏when ABC::Stem { ABC::Stem.new($note.not

The code in question (from BrokenRhythm.pm) is

when ABC::Note { 
    ABC::Note.new($note.accidental,
                  $note.basenote,
                  $note.octave,
                  ABC::Duration.new(:$ticks), 
                  $note.is-tie); 
}

I believe it’s the first ABC::Note there that is causing the problem.

This appears to be legal to me, and works fine under Parrot and Moar.

Tune Reminder

May 5, 2014

We’re going to Newfoundland later this year, and as a result I have a list of tunes I’d really like to learn before I get there, and I need to brush up on the ones I already know. (The sad truth is there isn’t a lot of chance in Michigan to practice many of these tunes with other musicians.)

Years ago I wrote a Perl 6 script to help me track what I needed to practice. I meant to make it use spaced repetition, but the truth is I got so caught up using Niecza and GTK# to implement a simple GUI interface for the program I never got around to actually adding the spaced repetition part. I used it for a bit, and then it fell into disrepair.

Well, I’ve dusted off the repo it was in and added a new script which attempts to do an approximation of actual spaced repitition. And it was beautifully simple to write, barring a small bug in the Mix class that lizmat++ fixed before I could even break out the rakudo source.

The first slightly tricky bit is initializing the record of how you’re doing on each team. I wanted it to be able to handle the case where you’re running the code for the first time and have no records yet, and the case where there have been new tunes added. Each tune gets a level between 0 and 5.

my @status;
if $status-database.IO.e {
    my $file = from-json($status-database.IO.slurp);
    @status = @$file, 0 xx ($tunes.GetNumberTunes - @$file);
} else {
    @status = 0 xx $tunes.GetNumberTunes;
}

I used the JSON::Tiny module to handle I/O of the records, and initialize tunes not seen before with 0.

The main loop of the code is very straightforward:

loop {
    my $mix = @status.kv.map(-> $tune, $status { $tune => 1 / 2 ** $status }).Mix;
    my $tune = $mix.roll;
    say $tunes.GetTuneName($tune);
    given prompt "Know / Don't Know / Quit: " {
        when "q" | "Q" { last; }
        when "k" | "K" { @status[$tune] = (@status[$tune] + 1) min 5 }
        when "d" | "D" { @status[$tune] = (@status[$tune] - 1) max 0 }
    }
    say "";
}

First I create a Mix based on the each tune’s status. The idea is that the higher the status level for the tune, the less likely you are to be prodded about it. Mix.roll is used to choose a random tunes with those weights taken into account. Then we print the name of the tune and use a simple combination of given and prompt to record how you did. (Note that this version doesn’t have any error checking here!)

Once you’ve hit “q” to exit the loop, the final line just records changes to the tune status file:

spurt($status-database, to-json($@status));

All-in-all, quite easy to code, and I’m already using it to help direct my practice!

rakudobrew

May 5, 2014

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.


Follow

Get every new post delivered to your Inbox.