Today we held the first Perl 6 mini-hackathon. Ironically, there was another Perl 6 hackathon happening in California. A few problems cropped up but the end result was a positive experience. I’ve never been to or held such an event, so I wasn’t sure what to expect.

First, the location we chose, Borders changed their wifi system. Since Seattle’s Best is owned by Starbucks, they switch to the T-Mobile non-free service. We ended up moving next door to Market Street, the location of our usual Perl 6 Mongers meetings. Unfortunately, this location is much louder than Borders, but we made it work.

Then one of the attendees was unable to connect to the wireless network. We ended up spending about 30 minutes trying to help out but ended up having move on. Next time, I will make sure to bring Rakudo and Parrot on a flash drive.

fRew and I set up a fresh Rakudo build. I ran the spectest and subsequently, it crashed my machine. Yeah, it locked up my machine and I had to reboot it when I got home (remotely logged in to my desktop development system). I couldn’t find anything in my system’s logs and the test suite was run in parallel. It seemed to stop spitting out output while it was working on S05-named-chars.

Eventually, it was just Patrick and I. We came up with a system for labeling RT tickets that should be relatively quick fixes. First, you have to filter out tickets assigned to Jonathan; these are typically more difficult issues to fix. Then we decided that we would tag the tickets “LHF” to mean Low Hanging Fruit. For now, you can find “[LHF]” in the subject but we will eventually have a tag created similar to the tests-needed tag.

All and all it was lots of fun. Next time, I will make sure to have an install CD or two, Rakudo and Parrot on a thumbdrive, and find a quieter location with wifi. Next time, we’ll hopefully be able to spend more time working on the LHF tickets.

The next event will be next month, two weeks after the Dallas.p6m meeting. The next Dallas.p6m meeting is slated for September 9th and the next Mini Hackathon is slated for September 26th. We need to setup our website and a calendar.

I have been postponing this week’s Perl post mostly because our monthly Perl 6 Mongers meeting was yesterday. I brought up and did some initial planning for a monthly Rakudo / Perl 6 mini hackathon. I have an outline of events but I want to discuss the Dallas.p6m meeting briefly first.

fRew was going to give a lightning talk about Perl 6’s object model but had to postpone due to a lack of preparation. We are all getting to know each other well and the conversations covered the spectrum: from Guido’s Simplification Of Choice to Perl 6’s attributes and then finally to processing.org’s Javascript framework.

Lastly, I brought up the idea of having monthly mini-hackathons. I thought it would be a great way to put Patrick’s talk into practice. So the initial idea is to have a 2-hour hackathon two weeks after the Dallas.p6m (second Tuesday every month), which should be the last Saturday in the month. The first get-together will be focused on Patrick’s talk, with others expanding as people find new areas of interest. That means the first mini-hackathon is slated for August 29th and here’s what I have tenatively planned:

1. Introductions
2. Getting and building Rakudo
3. Running Rakudo
4. Mailing Lists / Ecosystem
5. Understanding RT
6. Test Suite access and explanation
7. Setting

We may or may not be able to cover all of that. Patrick seems confident that we will be able to cover these topics so I am fairly happy with the layout. There will be more details forthcoming about the venue and the time/date.

I’ve never been to or held an event like a mini-hackathon, so I’d love to hear suggestions.

I started a Perl 6 project some time ago from a few discussions during a Dallas.p6m (Perl 6 Mongers) meeting. The idea was to create a complete packaging system in Perl 6 for Perl 6 with Perl 6. That sounds confusing, so let me explain the project some more. In retrospect, this is a long post that may bore all but the most ardent reader.

First, you can find the epoxy project on github in my account and the epoxy-resin database in the perl6 account (since pmichaud gives out commit access liberally). Epoxy is the main system with the epoxy-resin project as the package database.

The idea is similar to Gentoo’s ebuild system. Instead of writing clever shell scripts and executing them in crafty ways, I decided to take another route. Perl developers clearly like doing 1 thing: writing perl code. What better way to build and release your perl code than by writing some more perl code? The key is most difficult and common tasks need to be automated and allow for a huge range of flexibility.

I chose to implement the project as a tool that uses ebuild-like files, called resin files, that provide all of the functionality necessary for a user or developer to find, build, install, and repackage a project. The goal was to fully replace Makefiles, Configure.pl scripts, ExtUtils::MakeMaker, Module::Build, Module::Install, and most importantly, CPAN and PAUSE. That sounds like a lofty goal, but it’s working out quite nicely so far.

As a sidenote, I have seen Mark Overmeer’s CPAN6 and PAUSE6. I have seen masak’s proto and dcarrera’s ppm. I have seen the PAR project and Software::Packager. I have written ebuilds and RPM spec files. I have worked with JAR packages and WAR packages. I have created JNLP files. I have worked with (but not necessarily created) packages for basically every mainstream Linux distribution. I decided that none of these solutions are interesting except for a few. I also concluded that CPAN and PAUSE as we know it need to be recycled. They’re old enough and Perl 6 is new enough that it’s time to reinvent the wheel. Rather than creating a crufty 1990’s wheel all over, let’s create a modern wheel capable of handing modern technology (for example, CPAN authors have migrated to github in droves).

A resin file is similar to the ebuild file. Rather than giving it a unique extension or artsy syntax, I decided to make the resin files classes. To provide a resin build and packager for your project, you inherit from the base resin file and override the functionality you need. The idea is you will have to implement the smallest subset of functionality required for epoxy to fetch, build, and package your project. That is, for a “hello world” project, you only need to subclass Epoxy::Resin and provide a BUILD submethod that sets your metadata.

The base class, Epoxy::Resin, provides base functions, known as targets, to do things such as fetch, build, dist (repack), install, test, clean, upgrade, and remove. Each module may either use the basic functionality or provide some custom actions for each target. A resin file declares the module’s metadata by setting public accessor values, such as author, website, and license.

There are several resin files already written, though they have to be constantly maintained as I improve the functionality of the shell and the base class. Those resin files are for masak’s projects right now since his are the most visible. I intend on writing more resin files once the current ones are smaller and some of their functionality resides in the base class.

There’s also a shell that does this work. I used Tene’s sweet dispatcher to handle the commands in the most sensible and shortest manner I could come up with. Currently, it only dispatches the shell commands out directly as targets, but I intend on grouping the targets into meta-commands so that common tasks are easier. Also, only a few targets are currently supported since I have to also write the targets for each of the resin files I currently maintain. This is a time management juggling act, so I decided what I have will suffice for now.

So once you look at it (or try it out for that matter), you’ll realize there is much to do. I won’t lie, it’s very early work. There is no test suite (I haven’t figured out the best way to integrate with rakudo’s Test.pm). There is duplicated code to save time solving a harder problem (such as the shell dispatch handlers and the build targets). Most of the targets are non-functional, such as upgrade, dist, and remove. It doesn’t currently attempt to follow the standard or even remotely care what the standard says on the matter. There is a lack of error handling, such as use-ing modules that don’t exist.

What I’m trying to say is that I understand how it is incomplete. Everything that it lacks is because I have not determined the best way to solve the problem yet. In some cases, I had to even work around known problems or a complete lack of an eco-system. The Epoxy::Fringe and Git modules are proof of that. I have the tuits and development will inch forward.

I haven’t decided on an issue tracker for the project yet. I tried to use Lighthouse but it seems unintuitive. In order to complete a milestone, you have to create tickets and mark them as complete. This is really just good for cyclic or maintenance projects but not for off-the-cuff new development. I’m currently thinking about github’s newly added Issue page, which looks like it will suffice for now.

I asked masak, a prominent member of the Perl 6 community to review my code. He had mostly positive things to say. He pointed out that he didn’t like the name of the module that builds Epoxy itself: Epoxy::Build. He told me about IO.prompt and how BUILD submethods are now supported. He also pointed out my lack of attention to the metadata attributes. These are all things on my TODO list which will be addressed eventually. He was surprised to find that I was replacing almost all of the Makefile, Makefile.in and Configure scripts to his projects.

This all started out as an exercise to learn Perl 6 better. I wanted to know the syntax and to start thinking of how things work. The best way to learn is to act. I am having fun working on this every other day or so. It’s a nice metal exercise that keeps me busy over the summer.

I have grand plans for this. I will take my time and focus on the code. I will not be distracted by a charged discussion without any working code. Concepts and ideals are great, but sometimes, code speaks for itself. I won’t argue about the future of CPAN or which way is the best to package a product. I won’t partake in the arguments because everyone seems to have an opinion but no solution. Those are arguments no one can win. Until you know that, you are useless.

I will however take feedback and constructive critisism. I don’t want to fan any flame wars or discuss what anyone thinks is the best idea for the future of Perl or Perl 6. This is my free time and the last thing I’m interested in is pointless heated discussions. I am always open to feedback, reviews, and assistance.

In my exploration of traits, I stumbled across something that Tene created while working on the Web.pm grant. It basically uses trait_auxiliary to handle unknown sub/method traits. Here’s the actual code itself: LolDispatch.

Here’s the run-down of how this works. Be prepared, I may butcher the proper terminology or explanation since this is something that is new to me and have only started understanding it.

Line 7 defines a method called trait_auxiliary:<is>, which is what perl6 will call when an unknown sub/method trait is encountered. In this case, the trait “is” has the “http-handler” trait added to known traits. Line 8 just stashes some method information to use later.

Line 11 is the real meat of this module. It defines an exported subroutine “dispatch” that loops through the known methods and calls their postfix:() (aka operator()) method. $item<block> stashes the Closure that caused the unknown trait to be processed by trait_auxiliary:<is>.

The sample code starting in line 22 really has to go in a different file to work with Rakudo. While technically the ‘is http-handler’ trait works with methods as well, I encountered problems getting it to work.

I have an interesting use as I’m sure most people do. This basically helps remove unnecessary switch statements and dispatch tables. I simply just define my method and what the “is handler” looks like. This is really impressive, so everyone_involved++.

I wonder if there is a way (useful anyways) to combine this with a grammar.

So today, I ended up starting a very long discussion with several members of the Perl6 community about how functions are declared. Basically, I made several mistakes in trying to call my class functions “sub” when I meant method. Perl6 happily lets me shoot myself in the foot and then complains when I try calling the sub against an object, which doesn’t exist. Here’s a few examples of things to illustrate the clunky OO model:

Snippet 1:

class A {
sub foo {
say "never gonna happen"
}
};
my A $a .= new;
$a.foo;


Snippet 2:

class A {
method foo {
say "nope"
};
method bar {
foo()
}
}


_{note: the code highlighter does not support perl6}

So basically, that first snippet is an error. ’sub’ apparently means something other than what we want it to mean in this case. That snippet will fail with an error about no such method. The second snippet will fail because the ’self’ invocant is not assumed in the bar function. jnth says it’s because they don’t want methods like push being overwritten if I define a push method in my class.

The really sad thing is that I still don’t get it. I can’t make heads or tails of this object model. In some cases, Perl6 chooses to reuse syntax correctly, and in others it fails. There are about a billion ways to define a function. Each function can be a sub, method or submethod. It can have modifiers like multi and my and attributes like does and a huge multitude of parameters. The list of function modifiers just keeps going. How anyone is going to be able to use all of this is beyond me; I doubt I’ll ever be able to make sense of it.

Okay, so my raw opinion is this: they are doing it wrong. The “many paradigms” argument is wrong because the language should do one thing and do it well. It can’t serve all masters and still do a good job. If the object model is to be a real first-class citizen, then it must place the object model above all else.

That being said, I am of the opinion that C++ is the only language to get it right (see this, this, and this). Well almost, it still can’t do runtime template binding (think variant or Boost::Any) and I loathe the ‘friend‘ keyword (breeds bad code). Namespaces and classes are different concepts, so they are treated differently. When I place a function inside of a class definition, it becomes a member function. If I prepend ‘static‘, it becomes a class method (not a Class member like Java) and I can call it without a ‘this’ reference. If I want a function outside any class, just put it at the file scope and external storage. Calling a function defined within the scope (file or member) that has been included (imported) implies the ‘this’ invocant. All parameters are required unless given default values (Perl6 has 3 different syntaxes for this: required “!”, optional “?”, default value “=”). This is simple and direct. Templates were added for an additional level of flexibility, which worked out pretty well. In fact, C++0x will improve on this, assuming it’s ever released this year (otherwise it’ll be C++1x).

In bringing this up in the channel, I was really hoping to make people think about how Perl6 is doing it in hopes that someone who knows better than I would stop and think whether Perl6’s design is ideal. I was wrong and I think I may have agitated some of the developers. The beauty of open source is that I can do things my way if I see fit and likely will once the only usable implementation has support for macros.

So I have been keeping up to date with the Perl6 Spec via the auto-mailer on svn commits. Usually, there are minor changes or feature changes that I don’t yet understand. Yesterday, I saw a commit that raised my eyebrows and I figured I’d share it here:

Modified: docs/Perl6/Spec/S02-bits.pod
===================================================================
— docs/Perl6/Spec/S02-bits.pod 2009-01-26 16:12:14 UTC (rev 25043)
+++ docs/Perl6/Spec/S02-bits.pod 2009-01-26 19:11:42 UTC (rev 25044)
@@ -12,9 +12,9 @@

Maintainer: Larry Wall
Date: 10 Aug 2004
- Last Modified: 8 Jan 2009
+ Last Modified: 26 Jan 2009
Number: 2
- Version: 148
+ Version: 149

This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -1413,7 +1413,12 @@
Like the C module in Perl 5, the C< .perl> method will put
quotes around strings, square brackets around list values, curlies around
hash values, constructors around objects, etc., so that Perl can evaluate
-the result back to the same object.
+the result back to the same object. The C< .perl> method will return
+a representation of the object on the assumption that, if the code is
+reparsed at some point, it will be used to regenerate the object as a
+scalar in item context. If you wish to interpolate the regenerated
+object in a list context, it may be necessary to use C< >>
+to force interpolation.

=item *

In case you didn’t catch that, calling .perl on any Perl6 object and catching the result in a scalar will give you something that can be used to reconstruct the object that it was called against. Here’s a neat scenario that I can imagine:


my Sub $internal = sub func { ... };
$internal.say;

my %complex;
%complex{'a'} = 'g';
%complex{'sub'} = $internal;
%complex.perl.say;

my $cached = %complex.perl;

#other stuff that causes a rollback

%restore = |$cached;


Now those are just silly off-the-top-of-my-head examples that I came up with. If you can write it out, you can read it in and reconstruct the %complex hash just the same. This is very similar to the Tie::Persistant and Storable’s freeze/thaw functionality available to perl5.

Call me crazy, but the possibilities of having a freeze/thaw functionality built into every object strikes me as an amazing power that no other language provides. JBoss has formed a business trying to give that power to Java developers and it will be semi-trivial in Perl6.

A few days ago, I started a 13 day vacation for the hoidays. I haven’t had a real vacation since February 2007 when we went to Seattle (pictures will surely follow). Tons of things have happened in the last few months, so I’ll run through them since I have been very negligent of most things. I’ll make a separate post about Christmas and what I expect out of 2009 soon.

We bought a house in October. We moved in and tried unpacking. Until the day before family was slated to visit, we were only half-way unpacked. We now only have the master bedroom to finish.

I finished my Data/Text Mining For Computational Biology course. The workload was lopsided with October and November having the bulk of the work. I also took the qualifier for this class. There were only 2 people taking this exam, myself included with only 1 person having attempted it before. It lasted 3.5 hours and was most definitely written by committee. I don’t know what my final grade is because the website is closed right now (seriously, who “closes” a website?).

I’ve started the Great Music Archive Project. I intend to have every music CD we own ripped to FLAC by the end of the vacation. So far, I am at least half-way done and have a whole box I have not unpacked and checked their status. Afterwards, I’ll start the Great Music Tagging Project.

Speaking of archiving, I’ve started the Great Photography Archive Project as well. This is nearly complete and will begin the Great Photography Publishing Project shortly thereafter.

I signed up for the 3M Half Marathon finally, since I have been training for it for the last 6 months (2 months off can really do damage). The event is on 25 January 2009. I usually loathe reading other peoples’ race reports, so I will gleefully force mine on the few readers that remain.

I also have a plan to start daily perl6 development without altering my schedule. I will post details once I actually start. It involves a laptop and a morning commute. Sounds dangerous, doesn’t it?

Anyways, I must continue my archival projects now since I plan on accomplishing no real work while on vacation.