use Perl

Google has officially announced the funded proposals for Summer of Code 2008. I'm very pleased with the quality of proposals and we're all looking forward to a great summer.

The following is a brief run-down of the projects. We'll be putting all of the progress into an aggregator for the students to post updates as they work (I'll link to that when it is up.) The following oversimplifications of these projects are my own words -- the students wrote excellent proposals (and I think we might post the fulltexts soon because the above google link contains only the abstracts.)

Flesh out the Perl 6 Test Suite

Adrian Kreher will be transforming the Perl 6 Synopses into running code.
Mentored/supported by: Moritz Lenz, Jerry Gay, and Will Coleda

wxCPANPLUS

Samuel Tyler is going to create a wxPerl GUI for CPANPLUS.
Mentored/supported by: Herbert Breunung, Jos Boumans, and Steffen Müller

Native Call Interface Signatures and Stubs Generation for Parrot

Kevin Tew will be making it easier to use NCI (e.g. at runtime) for all parrot-hosted languages.
Mentored/supported by: Jerry Gay, chromatic, and Will Coleda

Incremental Tricolor Garbage Collector

Andrew Whitworth will be tackling the task of creating a Parrot garbage collector which doesn't need to stop the world to take out the trash, and hopefully turns into the 1.0 GC.
Mentored/supported by: chromatic, Jerry Gay, and Will Coleda

Math::GSL

Thierry Moisan will be writing, documenting, and testing a swig-based binding to the GNU Scientific Library.
Mentored/supported by: Jonathan Leto, Alberto Simões, and Steffen Müller

Full Text Search Implementation for Bricolage CMS

Krishnanunni P.N will be adding postgresql-based full text searching to the Bricolage Content Management System.
Mentored/supported by: Vivek Khurana and David Wheeler

A big thanks to these mentors and congratulations to these students.

Note that I'm listing multiple people as "mentor and support staff" for each project. In all cases, there is at least one person to backup the mentor, Herbert and Jos will be tag-team mentoring on wxCPANPLUS, some of the backups might end up playing assistant, and there is always somebody assigned to oversee things. In short, we've planned everything with an N+1 failover architecture and usually a supervisor node. This should make sure that students always have someone to turn to (though I think we might need to order more Jerry.)

Huge thanks and gratitude to all of the students who submitted proposals (which were of great quality, making it very difficult to decide) and all of the mentors and managers who volunteered, as well as all of you readers who helped promote the program. Of the mentors who volunteered, some ended up without a project, but many put a good deal of effort into working with students and helping evaluate proposals. Thus, I will mention them here and remind them that they might not be off of the hook yet: Andy Armstrong, Ash Berlin, Shawn Boyette, Tim Bunce, Nik Clayton, Kieren Diment, Darren Duncan, Rodrigo Fernandes, Shlomi Fish, Urivan Flores, Richard Foley, Jeff Horwitz, Paul Johnson, Mark Keating, Adam Kennedy, Yuval Kogman, Jonathan Leffler, Stevan Little, Zbigniew Lukasiak, Joe McMahon, Shawn M Moore, Greg Sabino Mullane, Steve Peters, Chris Prather, Marcus Ramberg, Allison Randal, Jonathan Rockway, Daniel Ruoso, Michael Schwern, Gabor Szabo, Matt Trout, Reini Urban, Jesse Vincent, Mike Whitaker, Brock Wilcox, Simon Wistow, and Ruslan Zakirov. Wow, what a list! And again: thanks!

I hope I didn't miss anyone, but if I did it is the fault of my filing system and not a reflection of my appreciation ;-) Thanks also to anyone who contributed to the wiki pages -- that effort played a role in getting us accepted into the program at all. A special thanks to Andy Armstrong for hosting the mailing lists, Richard Dice and the Perl Foundation for supporting my efforts, Steffen Müller, Alberto Simões, Jerry Gay, and Will Coleda for helping carry the load and keeping me sane, Vivek Khurana for writing the aggregator app, and all of the folks at Enlightened Perl for getting organized (or should I say "organised"?) and making the effort to get a second, slightly different Perl umbrella through the door.

I do wish we had gotten more slots and it is unfortunate that so many mentors who volunteered were left with nothing to do. But, I think the only way to change that next year is going to be to get more students interested in Perl/Parrot and get them to apply. Most of what determines the number of slots an organization gets is simply how many students apply. It seems cruel, but this is a competitive program, so Google basically gives each organization only the top 20% of their applicants (and we actually got 30% of ours.) So, yes: we had more mentors volunteer than the number of students who submitted proposals. I think this says a lot about the Perl community's enthusiasm, but maybe also says something about our demographic. We should try to do better with the publicity next year, but I am content with having gotten a 20% increase in slots from 2006 and an Inf% increase from last year (where we had a whopping zero because we didn't try hard enough to get in.) In any case, I'm glad that so many mentors stepped up to pledge their support and the entire Perl community should thank them.

Stay tuned for more updates. We'll be working on getting all of the students onboard with their respective projects, svn access, etc over the next few weeks and should have everybody ready to go by May 26th when the program officially kicks into coding mode.

The Perl Foundation is participating in Google's 2008 Summer of Code(tm) and we have a lot of capable, willing mentors looking forward to working with some talented, driven students. So, we would like you to help find those students (and quickly -- the application period opens March 24th and closes March 31st.)

This is a rare opportunity for students to get a chance to get a paid summer of hacking on exciting projects like Parrot, Perl 6, Moose, Jifty, SVK, Catalyst, or their very own Perl modules or applications. It also brings new talent into the community and gives the student a hefty "real world" experience with a knowledgeable mentor. Further, employers love to see this sort of demonstration of teamwork, handling deadlines, communication skills, resourcefulness, etc.

We're looking for promising students who are interested in open source (or maybe you know someone who *should* be interested in open source.) Knowledge of Perl is optional if the project is Parrot-related. The student doesn't need to be an expert in the problem domain (after all, learning is part of the process), but should bring a big pile of creativity, problem-solving skills, and determination.

Students should review the page of suggested projects, but are encouraged to bring their own proposals (those are often the best.) The most important first step is to get in touch with the community and start discussing their project idea with potential mentors.

Students: don't delay! We would like to see one or two drafts of your proposal on mailing lists before it gets submitted to the Google form. If you're working "in secret", that seems to indicate that we'll have a hard time getting updates from you over the summer. Similarly, procrastination in sending the proposal might count against you.

Additional information and links can be found here. We have a mailing list available for general questions and discussion, and will be available in #soc-help on irc.perl.org.

Google has posted some flyers if you happen to have a university bulletin board or hallway handy.

Additional info is on google's SoC page and their FAQ.

(Note that google has particular requirements to do with the fact that they are paying the students. The student must be able to show their
eligibility regarding enrollment and employability.)

Remember, the Perl community draws talent from many fields, so if you came to Perl from a non-computer-science major and still have contacts in that department from your university, it is probably worth mentioning to them.

Andy Lester reminded me that I have roughly the opposite of a tendency to state the obvious, which isn't a particularly great PR strategy.

So, what does Perl get out of participating in Summer of Code? Why should we spend all of this time and effort to mentor?

For starters, there are the community and publicity benefits:

1. New blood. My hair might still only be white on the inside, but I am getting too old to play the part of Perl's "young crowd."

2. A place in the minds of students (and academia in general.)

3. Staying in the headlines -- if we don't have a presence, we lose mindshare.

On top of that, students are competing for these internships -- so we're getting self-selected and motivated individuals writing new code. Those who enjoy teaching will understand what a great experience that can be. (And those who don't know if they enjoy teaching couldn't pick a better chance to try it.)

And those are just some generalizations. Use your imagination and your own point of view and you should be able to find a few specific reasons of your own. There have been quite a few good project ideas suggested so far on the wiki, including several for parrot.

So, for me it seems much more like a question of why wouldn't you want to help make Perl a successful participant in summer of code.

The deadline for Google's summer of code applications from mentor organizations is fast approaching and I need your help to keep perl from getting left behind like it did last year.

The wiki page has links where you can post your ideas for students and signup to be a mentor. Please post your ideas and signup before March 8th -- to increase our chances of getting accepted, we need to demonstrate a significant pool of willing mentors and lots of potential projects to inspire students.

If you speak for a large Perl project, consider volunteering yourself as a manager. I would like to delegate most of the cat-herding, as the Perl community (and the number of projects) is quite large.

Contact Eric Wilhelm (ewilhelm at cpan dot org) or join us in #soc on irc.perl.org if you would like to be a project manager or have questions about mentoring. Stay tuned for more details.

The Hall of Shame page on the wiki has been called "a flame war waiting to happen". Really? Does it help if it comes with reasons and I'm willing to put my name on my opinions?

IIRC, Schwern had a litmus test for this sort of thing. Should probably find that link...

Yesterday I closed about 20 tickets in Module::Build without writing any code. Some of them had been fixed and never checked-off, others were duplicates and several were not bugs.

Of the 11 non-wishlist bugs in the queue, only 5 are known issues, the rest are probably fixed, but need to be verified. When a queue gets too long, the only way to clear it out is to sit down and play historian for a day (and it was a long day.)

1. Get an axe.
2. Cut some wood.
3. Sharpen the axe.
4. Cut more wood.
5. Note the difference.

It's still hard work, but it's a good deal easier with a sharp tool. The thing that catches you unaware is that the tool goes dull as you use it and needs to be sharpened again. It's a lot like the frog in a pot of water being slowly brought to a boil -- you don't realize the incremental decrease in sharpness until you put a new edge on it.

But, we have power tools!

1. Get a chainsaw.
2. Cut some wood.
3. Sharpen the chainsaw.
4. Cut more wood.
5. Note the difference.

A dull power tool is still innefficient. It just happens to have enough excess power that you maybe don't realize the dullness as easily. When the tool is sharp, more power goes to cutting and less to heat (this is why you usually cut/drill metal with a lubricant.)

How does this work in the context of software? The tools don't get duller in an absolute sense, but they can get less sharp relative to the advances in theory, hardware (e.g. running single-threaded on a multi-core system), etc. They also get dull with regard to the challenge of solving new problems -- as in: none of us would have jobs if all of the problems had been solved.

So, have you sharpened your tools lately? Have you stopped to wonder if they are dull?

Other than the lack of a real operating system, the main thing that has always aggravated me about palm is the need to push that stupid button in order to initiate a connection with the desktop. They've long-since gone from serial to usb and still no way to initiate a connection via software.

Well, I'm taking this full-circle. I've discovered (due to having accidentally acquired a button-less cradle) that the hotsync button does nothing besides short two pins on the connector. (At which point I tell myself "duh. what else would a button do?") So: usb-serial cable, a wee reed relay, and some solder should get me to "desktop sends sync command to palm" which leads to "fun with cron and/or FAM." Wow, Palm really needs to get their act together.

Don't even say iphone. Apple's idea of interface design is "ease of sale over ease of use". PalmOS might suck, but AT&T and apple together would be far too much evil/incompetent for me to stomach.

So I decided to finally (after all of this compatibility work) take TAP::Harness out for a spin and make TAP::Harness::Parallel. That comes with some pain about the output formatting API (and I'll push it to CPAN as soon as we stabilize that -- right now you have to ride along and get TAP::Harness from its svn too (and possibly r491 because we're still working-through the single-process assumptions in the formatter.)) But, the preliminary results are between 40-60% reduced waiting. If your test suite takes more than 10s to run, it is probably worth it.

runtests -r -j 9

Note: I symlink bin/prove to runtests -- the Test::Harness transition isn't quite complete.

Expect about 40% time reduction in typical tests suites. The perl 5.8.8 core tests dropped to 200s from 500s. The parrot tests seem to be playing along as well. (Both of these require the directory-based partitioning.)

The biggest problem is resource conflicts. Have you ever run your tests simultaneously before? Probably not -- it is likely that they reuse tempfile names, server ports, etc. Time to start tacking $$ onto your tempfiles or using File::Temp. Of course, the directory-based partitioning (run each directory as a process) tends to help drop-in compatibility, but can block performance if things are unbalanced.

Next steps probably involve more switches and various forms of partitioning.

I've often wanted to contact the maintainer of some foo.perl.org page and not found any contact info (e.g. qa.perl.org, learn.perl.org, etc.)

Schwern's "Blame Schwern" talk made a good point, but what if the "somebody should" or "wouldn't it be cool if" involves an existing website? You need to know who to talk to.