Recently in Perl 5 Category
Brad Fitzpatrick has announced that he is working on bringing Perl to the Google App Engine.
I'm happy to announce that the Google App Engine team has given me permission to talk about a 20% project inside Google to to add Perl support to App Engine. To be clear: I'm not a member of the App Engine team and the App Engine team is not promising to add Perl support. They're just saying that I (along with other Perl hackers here at Google) are now allowed to work on this 20% project of ours out in the open where other Perl hackers can help us out, should you be so inclined.
The architectural changes to make this happen are not insignificant. Check out Brad's post to find out how you can help.
Aaron Trevena wants to get the Perl 5 wiki up to 1,000 pages, and it's almost at 900.
The Most Wanted Pages is a great place to start. Pick a page that some other page has linked to, and create it. It's that simple.
Take a look at this block of code and see if you can guess what it does.
END: {
print "Exiting...\n";
}
print "s = $s\n";
BEGIN: {
$s = 'Hello from the BEGIN phase';
}
You'd expect that the BEGIN block sets $s at compile time, so then that gets printed in the print statement, and then the END block executes at the end of the program. Yes, it would, except that those aren't BEGIN & END blocks. They're normal blocks that just happen to be named BEGIN and END.
Credit Randy Lauen for bringing this to my attention. Today at my day job he found a horrifying code construct, one that I'd been using (incorrectly) for quite some time now. You see, these two blocks are not the same:
BEGIN {
# Here's some code that gets executed at compile time
}
BEGIN: {
# This code gets executed at run time, because the colon
# after BEGIN means it's just a plain old label
}
Randy had been tracking down a bug for over an hour and couldn't figure out why his variables weren't getting set at compile time. Turns out the BEGIN block he was modifying was actually a not-special-at-all BEGIN: block. And he found 40+ instances of the spurious colon in the codebase. Of course, INIT, CHECK, UNITCHECK and END are also rendered non-special by a colon as well.
Most of the time, this is invisible. People tend to put their BEGIN blocks at the top of the program, so the difference between a real BEGIN block and a block that happens to be named BEGIN are not noticed. Still, it's a a bug waiting to happen. Sounds like an ideal check for Perl::Critic policy, no? Mike O'Regan jumped to it, and submitted a patch to Perl::Critic, so those of you using Perl::Critic (and if you're not, you should be) can get warned of using colons on those specially-named blocks once a new version is released, shortly I hope.
I'm not the only one to have been doing this. Google Code Search turns up over 100 instances, including some in the core Perl tests (heck, maybe from me!), as well as mailman and POE.
Check your codebases. If you're using ack, it's just:
$ ack --perl '^(BEGIN|END|INIT|CHECK|UNITCHECK):\s*{'
Have you fallen prey to this? Let me know.
The schedule for YAPC::NA just got published, and there's plenty of good stuff this year. If you haven't decided to make the trip out to Chicago June 16-18 yet, this should help.
Cool stuff that jumps out at me as I peruse the grid: JT Smith talking about the premade application stack that WebGUI uses, Schwern on testing data with The Sims, and Kevin Falcone on timezone handling.
For the beginners, Kent Cowgill's intro to testing is a great way to get introduced to the topic, and I'm sure that Leonard Miller talking about Perl::Tidy and Perl::Critic will help instill good coding practices.
New this year, on Wednesday there will be workshops. Stevan Little will host a 2-hour Moose tutorial, and Jim Keenan will help you get started building and working with Parrot and Rakudo Perl.
Do you have recommendations on must-see talks? Let your fellow Perlbuzz readers know in the comments below.
We're nowhere near ready to switch to Perl 5.10 at work, even with the release of mod_perl to support it. I'd like to use smart matching all the time. Perltraining.au's put out an article about smart matching in its series of Perl tips that just makes me cry for what I can't use.
mod_perl 2.04 has been released and it supports Perl 5.10. If mod_perl has been a barrier to your uptake of Perl 5.10, there's no longer a reason to wait.
Tim Bunce has put together a presentation debunking three pervasive myths about Perl:
- Perl is dead
- Perl is hard to read / test / maintain
- Perl 6 is killing Perl 5
Jan Dubois posted about Microsoft's 3rd Annual Scripting Games, where you can win prizes for writing Perl programs to solve programming problems like "find a word that you can make out of a phone number," and "count the number of characters in a given text file."
I'd enter if there were interesting prizes, but all the prizes for Windows-only software packages. :-(
Ha ha, trick question, there is no "best" templating system except for the one that's best for your project. Vince Veselosky has a roundup of Perl templating systems where he examines everything....
... from the Swiss Army Chainsaw of Template Toolkit, through HTML::Mason and Text::Template down to the ever-tempting "variables interpolated in a here-doc" method.... Read on for a comparison of the major template systems in Perl, and my recommendations of which systems fit which circumstances.
It's a fine introduction to the various systems, and probably worth pointing to from the Perl 5 wiki, if not reproducing it there entirely.
I'm amazed at how David Landgren manages to summarize the p5p traffic, especially this week. Last week's summary is 19K of text covering everything from what happens when you bit shift infinity, to what features people want in Perl 5.12, to outdated Test::Harness components.
