I’ve often wondered what places someone in an open source community. Is it advocating the software? Openly contributing source code? Are users members of the community? I’m not sure if the definition of membership is clear to me.

You’re probably reading this entry on the Perl Ironman Blogging challenge. I joined the challenge over the summer when I had much more time to devote to active participation (no classes). I have failed to leave Paperman status since the semester started.

I haven’t contributed much. I haven’t been able to clean-up and upload my lingering perl projects to CPAN yet. I haven’t contributed to fixing bugs in CPAN modules or perl5 itself. I have flirted with contributing to Rakudo over the last 18 months but have become consumed with my graduate work as of late. I have been to only 1 YAPC::NA event, which was this summer at YAPC::NA 2009.

I don’t write gobs of professional code using Perl; 95% of my professional code is C++. The last professional Perl project was to recreate Test::Harness and TAP::Formatter to meet my needs, which turned out to vary widely. I’m not a sysadmin, so I don’t get to use Perl as a glue to hold my universe together. I don’t have 14 million repuation points for Perl on StackOverflow.com.

I don’t wax philosophically about the Great Divide between Perl 5 and Perl 6 developers; I am both, so that would be weird to argue with myself. I love Perl, both 5 and 6. I love all the great things people have contributed over the many years.

To put it bluntly, my graduate degree greatly eclipses anything I would like to contribute to the open source community, Perl included. I take a few hours a week to run and that’s about all I get for free time.

I did restart DFW.pm, now referred to as Dallas.p6m. Dallas is blessed to have a few significant community members, so I at least try to bring them together for coffee once a month. I’ve held a few mini-hackathons, though attendance has dropped, likely due to the time of the year.

So where would I fit in this Community Ball of Mud?

Today, only fRew and I ended up meeting for September Dallas.p6m meeting. Turns out several people forgot that today was in fact the Tuesday after Labor Day and not Monday. We mostly just sat and talked about miscellaneous software things. We discussed GPS, my Algorithms course, Parrot, PGE, and styling. Styling is the last thing that we discussed and one that seemed semi-heated.

I discussed my reasoning for my styling quirks, which fRew insisted he would replace in a heartbeat. I’ve mostly been honing my preference for certain things by finding bugs using styles that seem to lead towards common mistakes. For example, I always place if statement parenthesis immediately after the ‘f’ because you cannot have one without the other (well, you can have the boolean expression alone but it rarely makes sense unless it’s a return value). I tried to apply the same reasoning to why I put my braces at the end of the if line with a space between the ‘)’ and the ‘{‘. I do this because the block started by ‘{‘ can exist without if clause. I always keep the ‘{‘ on the same line so attempts to comment out the if clause will fail to compile as I’ve found and fixed too many bugs as a result of true laziness.

Now that may seem kinda wierd, but it’s 1) a mental seperation technique and 2) an attempt to reduce the number of standalone nested blocks (that can do odd things like cause variable scope issues).

Then we started discussing using ampersand, ‘&’, to begin functions. My reasoning is because I more often than not prefer to be as explicit as possible, and the ‘&’ let’s me do that. I failed to recall an example that led me to preferring the use of ampersand, but I eventually found it. Basically, functions should look like function calls and not keywords, macros, or other environment lexicals. &foo($arg1, $arg2); looks a bit hairy and dated (generally a perl4 way of doing things), but it’s clear from the first character what is about to happen. My brain needs only to parse the first character to read the code with the right mindset. I am calling a user defined function (not a built-in), named ‘foo’, and passing 2 arguments. That is clear, readable, and will likely work for the forseeable future; if not, it’s still easy to find and correct.

On the other hand, foo; or foo(); (under strict) is not necessarily clear. The first example is basically a bare-word and could be any number of things. It could be a symbol, a package, a string, or a function call. The arguments passed would be @_, which requires more investigation. The second one looks like a subroutine call but I have to parse 5 characters and then grep around for a sub named foo within the current namespace (was it loaded elsewhere and exported to my namespace?). While both of these are more compact and concise, they also both require more work to figure out exactly what is happening.

Also, foo($arg1, $arg2); is more clear but not until I’ve read the minimum of 4 characters to I start to think it might be a function call. This does not parse and skim nearly as quickly, at least to me.

All of this skimmable code talk (note: I don’t agree with Schwern, end-of-scope comments usually clutter code more than they help) may sound frivolous to those readers who deal with thousands of lines of code. It’s not something you can truely appreciate until you maintain code that weighs in with at least 9 digits (executable code only). I personally manage 250,000 lines and I am responsible for a product that is about 2 million lines (all 30 of our branches are about 2 million lines each).

In the end, I stick by my preference for ampersand function calls unless someone else can point out a better reason to ditch them.

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.

There are a few corrections that were needed from my .WALK talk yesterday. Having the Rakudo pumpking sitting next to you makes answering questions much easier.

First, moritz_ strongly suggested I post working code and not off-the-cuff code anymore. His argument was that it further perpetuates the meme that Perl 6 is vapor. So here’s a properly working example:

class A {
    method baz { ... };
    method bar { ... };
};

class B is A {
    method baz { ... };
    method icanhaz { ... };
};

class C is B {
};

class D is A {
    method ucanhaz { ... };
};

my @candidates;
my C $c .= new;
@candidates = $c.WALK(:name<baz>);
say @candidates.map(*.name).join(', ');
@candidates = $c.WALK(:name<icanhaz>);
say @candidates.map(*.name).join(', ');

So the obvious correction there is the change to class. This is because modules cannot inherit. Also, the named parameters were supposed to use <> or quotes. The say calls were added to see the results immediately (aestetics).

Also, it seemed that in my attempt to understand WALK, I misread the entire intent of the returned results. The WALK iterator will in fact return callable methods (Code objects?). Those methods can then be called with the $* and $+ operators (as discussed in S12). The correct output is:


baz, baz
icanhaz


The two baz methods are B::baz and A::baz, while the icanhaz is just B::icanhaz. Since multi method dispatch never truely hides methods, similar to C++ (Base::method) and Java (super.method), A::baz is still available for dispatching.

Lastly, :name is not required, since it will return all methods. :name, hence why it was bundled in the filter parameter list, merely filters out method name matches.

That should wrap the loose ends. I hope the attendees enjoyed learning about method dispatch and WALK. I’m soliciting for next month’s talk if anyone wants to volunteer.

I will be putting on the first Dallas.p6m talk about upcoming Perl 6 features. This posting will discuss one of the introspection tools: .WALK.

Note: Any code posted below is for demonstrational purposes. It is left as an exercise for the reader to polish for any compiler or interpreter.

WALK is a function defined on Perl 6 objects that will walk the multimethod dispatch and return the appropriate matching candidates. It follows the entire multimethod dispatch, regardless of whether a version has been overloaded by the child, applying various match/non-match functions and returns the results. Let’s start off with an example:


module A {
method baz { ... };
method bar { ... };
};

my @candidates;
my C $c .= new;
@candidates = $c.WALK(:name(baz));
@candidates = $c.WALK(:name(icanhaz));
@candidates = $c.WALK(:include(B));


So basically what I did there was set up a cheezy object hierarchy and did a few WALKs over it. Let’s go over them and discuss what they did.

I should note that it is not obvious or clear from the Specs what a few of these options truely entail. For example, unless you are intimiately familiar with dispatch, the various dispatch method orders are not well defined. I keenly opted to skip them.

I should also note that there is very little information in the Spec (S12) pertaining to .WALK. After having written this post, I will obviously need to present a few questions to the mailinglist.

The first call returns < C B A > because they all have the baz method. The second call only returns B because it is the only one of < C B A > that contains the icanhaz sub. The third call returns < A C > because A was omitted from the results. However, there is a slight issue I wanted to raise with the third call. It’s not clear from the spec that :name is a required parameter (:name!). In all likelihood, the :name parameter is required and this call will result in a compile/runtime error.

There are a multitude of parameters that guide the tree traversal:

• :canonical for canonical dispatch order
• :ascendant for most-derived first, like destruction order
• :descendant for least-derived first, like construction order
• :preorder for like Perl 5 dispatch
• :breadth for like multi dispatch

There are a few other parameters that help with filtering classes/modules/methods along the hierarchy as WALK traverses the multidispatch candidates:

• :super to only include immediate parent classes
• :name to only include classes containing named method declaration
• :omit(Selector) to only include classes that don’t match selector
• :include(Selector) to only include classes that match selector

Another thing that the Spec does not discuss is whether subtrees are pruned out from the search or if they are all smashed onto a flat search space and only matches are returned.

So astute readers are wondering what the Selector parameter can be for the :omit and :include parameters. Let me show you an example taken straight from the spectest:


my @cands = $x.WALK(:name< m >, :include(regex { < [CDE] > }), :omit({ .^can('n') }));


How awesome is that?! You can specify a regex or use the .^can attribute. In perl5, the .can attribute returns a single Code reference. The new .^can attribute returns a .WALK iterator, which can be used with either :include, :omit, or all by itself.

This is a really cool way of letting me explore my objects more. To those of use who have wanted to do similar things with other languages, this feature will greatly assist inspecting foreign code for it’s capabilities (and obviously other things). I usually use introspection to find out if a plugin or if a class in a library has a certain capability (think versioning your classes). So to round out this discussion, I wanted to briefly mention what a few other languages are capable of that is similar.

Java has fairly decent introspection capabilities, referred to as Reflection. You can sift through the constructors, the declared methods, declaring class (if inherited), class fields, and even invoke methods. There are no built in techniques to automatically narrow the search space (defaults to the current Class object).

Python has very limited introspection capabilities. Python’s method is significantly more arcane than everywhere else, unless you like __method__() calls. Python allows you to get attributes on a class/object by using the __getattr__() function. I had trouble digging up a complete list of string literal attribute names, so buyer beware. Therefore, I should note that my comparison to Python is probably incomplete.

C++ has no such facilities. In order to accomplish this, you will have to conjur up clever hacks like this macro that is used to create a database of classes. Xlibs provides some legacy functionality similar to this that can be used for classes and functions, but is generally pretty limited. The closest thing to invoking one of the returns from .WALK in C++ is going to be a hand-rolled combination of boost::function and boost::functional.

Ruby has a way to keep track of known object instantiations, ObjectSpace, and then pull out methods (private, protected, public, and singleton) and instance data. This is done through the basic Object class. It can even do something similar to perl5’s .can (respond_to?). Unfortunately, there are also no built in techniques to automatically narrow the search space.

The ability to guide the search of multimethods built into the language is an advantage not found elsewhere. Keep in mind, I didn’t feel like researching all 10 million languages out there to see if this is a truly original feature.

This is getting a bit long to really be considered a lightning talk, so I will end it here. If anyone has any corrections, suggestions, or comments, feel free to use the comment feature.

It’s pretty obvious that I have been neglecting this space lately. It’s been well over 2 months since I last posted anything, and that was one of those annoying “updating things” updates.

Well, I’ve decided to partake in the Iron Man perl blogging challenge. Once a week, every week, I will post something, anything, about perl. This should be easy because it’s basically all I’ve been programming in lately and it’s easily my favorite language. My official start post is right now.

I’m working on an interesting new library that I’d like to think can change things in a big way for the open source community. I’m working on this with a fellow perl6 monger. Oh, you didn’t catch that? Yeah, I helped start the first Perl 6 Mongers group, right here in Dallas. DFW.pm is basically defunct; one of the problems that plagued it was the venue. Rather than trying to cater to everyone across this horribly sprawled metroplex, I think it would be best to just focus on a few key areas. We may rename it later, but Dallas.p6m seems fitting.

Speaking of which, I will be attending YAPC::NA 2009. My wife and I will treat this as our mini-vacation, since we haven’t taken one in 2 years! I contemplated giving a talk, but I decided I’m too new to this whole presentation thing and I’m not sure I have anything to really say. Hopefully next year I will have something interesting to give a lecture or talk over.

The semester is almost over and I’m still swamped to the gills. I’ve been neglecting everything lately due to the overwhelming amount of work I’ve been assigned. I will be really happy to make it through to the summer for some time off. I’ll still be working on my thesis, but that’s not nearly as pressing as normal class deadlines (unless you advisor makes you redo stuff right before you defend).