Beginning with Perl 5, version 12, the Perl 5 language began an annual release cycle, with a new stable release around May of each year. Beginning with version 14, the Perl 5 maintainers also announced a formal support policy and ended support for version 10.
This is a significant change from the history of Perl, so I though it would be interesting to see how recent release cycles have compared to historic ones. The chart below shows releases over time since Perl 5, version 4 when releases were more officially split between "stable" and intermediate releases.
click for larger view
(Note: Starting with version 7, odd numbered versions were reserved for development releases and are omitted above. Versions 13 and 15 moved to a monthly release cycle for easier community testing of incremental development.)
I think the overall change to a shorter development cycle will benefit both users and maintainers of Perl 5. For users, each new release will be a smaller change from the previous, lowering upgrade risk, plus they can have confidence in an ongoing process of improvement. For maintainers, it avoids taking away effort from mainline development to retro-fit patches into a Perl that is many years old and might have substantially different guts.
20 January, 2012 i
ironman,
p5p,
perl,
perl programming |
Comments Off
Imagine if Perl 5's caller
returned an object which represented the call chain to the point of the
object's creation.
I want to inspect the call stack within a helper module, but I don't care about the call stack within the module. I want to use lots of little helper functions, because that's good design, but caller works against that. Looking up the stack means keeping track of the magic number of call frames within my module I currently use, and that's one more thing to update when I change things.
That's structural code highly coupled to the arrangement of other code, and
if that doesn't wrinkle your nose with the subtle aroma of fragility and peril,
I don't know what will.
Imagine if instead:
my $caller_object = capture_caller_state();
while (my $call_frame = $caller_object->next)
{
next if $call_frame->is_eval;
say $call_frame->location_as_string;
my $next_frame = $call_frame->previous;
...
}
Imagine if you could pass this object around.
I know things get complicated if you pass this object up the call chain, but
stack unwinding is a solved problem in that anyone capable of recognizing the
problem should be able to figure out cheap and easy ways to fix it.
Alas, Perl 5.14 doesn't have this feature, and it's probably too late for
5.16 to get it, so for today I'm stuck imagining what might be.
(If you've never thought about this sort of thing before, you owe it to yourself to learn more about Continuation Passing Style, which is at least an order of magnitude more mind-bending at the start and at least two orders of magnitude more useful.)
19 January, 2012 i
features,
modernperl,
perl5 |
Comments Off
Last weekend I attended the Orlando Perl Workshop. While the "hallway track" is one of the best parts of Perl workshops, the talks I saw were also excellent. Here is an overview of the sessions I attended.
Doing the Jitterbug
Jonathan Leto (dukeleto) presented Jitterbug, a cross language continuous integration tool for git (and written in Perl). It's a smaller, lighter tool than Jenkins, though it lacks distributed testing capabilities. It seems really good for small to medium sized Perl projects, as it already understands how to build and test things with a Makefile.PL or Build.PL. (see slides [pdf])
Javascript is Code
Jay Shirley (jshirley) gave a non-Perl talk that explained why Javascript tends in practice towards spaghetti code. He recommended the YUI3 framework and explained why it provides better structure and why it would be familiar to Perl programmers used to Moose.
A Brave New Perl World
Stevan Little (stevan) presented some ideas from the work-in-progress prototype of a meta-object protocol (aka MOP) for the Perl 5 core. I'm really excited by this and I think the design team is finding a pragmatic balance between power and simplicity.
Tweakers Anonymous
John Anderson (genehack) gave an editor-agnostic half-rant/half-tutorial about why and how to tweak your editor to be more productive and less repetitive. There were some good tips that I've already put intro practice, like teaching the editor to automatically "chmod +x" when saving any "*.pl" file. (see slides)
The First Thing Tak Did - Elegant Remote Control For Sysadmins
Matt S. Trout (mst) showed an insanely complicated but powerful command line tool to remotely execute any pure Perl code over ssh, without needing any prerequisite modules installed on the remote machine. It's worth exploring just to understand the magic that makes it work.
Game Development with Perl & SDL
Breno Oliveira (garu) gave a playful talk that showed how easy it has become to use Perl to write simple graphical games. In only a couple dozen lines of code, he demonstrated a simple 2D platform game using the built in physics model. (see slides)
Cooking Perl with Chef Solo
This was my talk, where I explained what I've been doing to make it possible to deploy Plack apps using Chef and Perlbrew and friends. (see slides)
Lightning talks
There was the usually assortment of amusing talks, though several presenters thought it would be "fun" to present their 20 minute (or longer) talks in 5 minutes for anyone who missed the original. (Note to future presenters -- please don't do that. Pick 5 key slides and just show those.)
The most interesting to me was the lightning talk by Bruce Gray (util), who introduced Rosetta Code, a site that shows how different languages solve hundreds of common programming problems. He said that Perl needs more solutions written to catch up to other languages, so if you have time and interest then please check it out.
Keynote
Cory Watson (gphat) gave a funny talk that in style was nearly worthy of Larry Wall. It meandered around the broad theme of "diversity" and whether more ways of thinking about things makes one smarter. It eventually circled back to Perl, but the overall call to action was to get out of the usual comfort zones and try something you haven't done before and aren't good at -- whether radical or minor -- in order to stretch your brain. (I can't do it justice in text -- I think you had to be there.)
Hackathon
On Sunday, I went for brunch with some other attendees and then parked myself at the hackathon until it was time to leave for the airport. While I was there, I sucessfully ported my auto-install CD creation tools to work on Debian ISOs instead of just Ubuntu ISOs, so I can test my Perl/Chef tools on that server platform as well.
Coda
As a final note, Chris Prather (perigrin) -- who appeared ably supported by his family -- put on an excellent conference and I want to thank him for the work that went into it. I hope I can attend again in 2013 and recommend it to anyone who wants to get away and have some fun with Perl in the dark of January.
18 January, 2012 i
conferences,
opw,
perl,
perl programming |
Comments Off
Sometimes you find bugs in the most surprising places.
I've long used test-driven
design for code I care about. Knowing that it works, works reliably, and
will continue to work helps me write the right thing. As I've gained experience
with testing, I've come to appreciate the nuances of how and what to test and
why. For example, I often don't bother to test exploratory code—it's more
important for me to learn how code might work to help me figure out how to
design the real thing than it is to hew to a rigid mindset of "You must always
test everything."
Similarly, I see little value in rigorously testing basic accessors, and thank goodness for Moose for turning class declarations into declarative code.
In more serious discussions of testability and testing, people often argue
that testing UIs is impossible, or merely difficult, or rarely worth the
trouble to do so completely. I agree to some respect; the most effective way
I've seen to test UIs is to test the backend data model rigorously, write a
very thin controller to marshall and unmarshall requests and responses, then to
write a handful of tests which explore the edge cases of UI interactions. That
requires a deep understanding of what happens for each interaction, and you can
only test those interactions which produce measurable side effects.
Let that latter point sink in for a moment.
My most recent work on multiple projects includes a lot of embarrassingly
parallel batch processing work, where the user interface is largely static,
produced daily from a series of templates. Generally the templates are
correct if they pass the eyeball test with live data.
This works except when it doesn't.
Consider a snippet of Template Toolkit code to display a list of stories:
[% FOR e IN entries %]
<div class="story story[% loop.count %]">
<h3><a href="[% e.url %]">[% e.title %]</a></h3>
<p>[% IF e.author %]
[% e.author | html %]<br />
[% END %]
[% f.format( e.posted_time ) %]</p>
[% IF e.has_image %]
<img src="[% e.image.full_file %]" alt="[% e.title | html %] image" class="image" />
[% END %]
<p>[% e.short_content | html %] <a href="[% e.url %]">Read More</a></p>
</div>
[% END %]
That code had a bug. Can you find it by eyeballing it? Neither could I, for
a long time. I'll give you a hint: it never displayed images associated with
stories. Give up?
I wrote backend test after backend test, fixing a couple of other bugs along
the way, then traced through the code in a debugging batch until I had
convinced myself that the data model was completely correct. The bug
had to be in the template because it could be nowhere else.
Rigorous template tests didn't seem to help either, and I'd almost convinced myself that I had a nasty spooky action at a distance bug somewhere in the data model before I saw the problem:
[% IF e.has_image %]
<img src="[% e.image.full_file %]" alt="[% e.title | html %] image" class="image" />
[% END %]
When I added a test for the has_image() method on story objects
to the data model tests, it failed immediately because that method did not
exist. It used to exist, but a refactoring somewhere went too far and
removed that method and its tests from everything except the template. Because
Template Toolkit is not so strict about the distinction between method and
property access, the lack of a method is no big deal. It fell back to property
access on a hash and, finding no such value in the hash, returned a false
value.
There are ways to fix this. I'm sure there's a plugin for Template Toolkit,
and probably a debugging/diagnostic mechanism somewhere I haven't yet
discovered. Yet the problem remains.
I've heard it said (Rich Hickey? Martin Odersky? I think it was Rich.) that
every bug in your program has passed the type checker. That statement contains
wisdom. Yet it's also true that every bug in your program has passed the test
suite. (We assume you run with type checks and keep your test suite fully
passing.)
Neither is a substitute for careful thought and understanding. Both protect you only as far as you can take advantage of them.
My next post will explore some options for making these kinds of errors
easier to catch way before the point of weird debugging sessions.
17 January, 2012 i
bugs,
perl5,
testing |
Comments Off
These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.
17 January, 2012 i
Parrot,
Perl 5 |
Comments Off
The Parrot project is now using
GitHub's issue tracking system.
Parrot has used GitHub's source code control for months now, but
we had hundreds of tickets in the
Trac system. Now,
over the past few weeks, I've been working with
Rick from GitHub
to migrate the tickets out of Trac into GitHub's issue system.
Like most data conversion projects, the challenges were less about
the coding and more about making the decisions about how to massage
the data between two similar systems. For example, Trac has fields
for Severity and Priority of tickets, but GitHub only has free-form
tagging, so I had to create GitHub tags that correspond to Severity
and Priority in Trac. GitHub's tracking system doesn't handle file
attachments, so my conversion code had to make inline comments of
the file attachments.
Most time-consuming of all was the conversion of users from Trac
to GitHub. We needed the issue history to have accurate user IDs
on them, so I needed
a big lookup table to do the job.
While users like "coke" and "chromatic" have the same user IDs on
both the Trac instance and GitHub, Trac user "jonathan" is "jnthn"
on GitHub, and so on. Anyone I couldn't find a match for became
generic user "Parrot".
The
actual code to do all this
is only about 200 lines of Perl code, which should be no surprise
for someone who has the CPAN at his disposal. I used
Net::Trac to
read from the Trac instance, and the
JSON module to write
out JSON files in the GitHub API format.
The bulk of the code is
project-specific conversions to make little data tweaks like change
severity to tags, and to make the output code a little more friendly
in Markdown.
I have to specifically thank Rick at GitHub for helping us through
this project. I used a lot of his time with questions about how
GitHub would handle my import format, and we had two test imports
for us to see real results, so that I could adjust my conversion
process. The final results are beautiful, and the Parrot team is
excited to see this move made.
I've long been a fan of GitHub
and how they help out the community,
and this just adds to it. This sort of aid to open source projects
should stand as an example to other companies that work with open
source. Many companies give back to the communities of the projects
on which their businesses are based. It's fantastic to have a
company willing to use human capital actually working with a project
in which they have no direct involvement. In helping us, GitHub
gains nothing but the grateful thanks of the Parrot project.
16 January, 2012 i
github,
Parrot |
Comments Off
The Modern Perl book went to the printer earlier this week; this is the 2011-2012 edition.
You can already preorder Modern Perl: 2011-2012 from Amazon and it'll be available from other bookstores in the next couple of days. I expect copies to ship by early next week.
What's new?
I closed every bug filed against the previous edition—a handful of typos, a few confusing sections, and some suggestions on improvements. I took most of these suggestions.
I also revised almost every paragraph of the book, even at the sentence level. While I'm proud of the first edition, this new edition is clearer, shorter, more concise, and more accurate.
I removed some sections that didn't work. This didn't amount to much, but
some of the things I recommended made little sense anymore and some of the
experimental modules I mentioned turned out to be less useful than hoped. You
won't miss them. This includes a big revision of the smart matching section in
anticipation of changes in 5.16 and 5.18 (simplicity is the rule of the day;
the simpler your use of the operator, the less risk you face for confusing
behavior and edge cases).
I also added explanations for the new features in Perl 5.14, especially the
/r modifier on regular expressions, and prepared for further
features added in 5.16.
You might notice subtle improvements in formatting; the font size used for
code examples is larger and callouts are much more attractive. We're still
experimenting with the best way to format books to make readable text while
avoiding brick-sized tomes, so feedback is more than welcome.
As with the first edition, we'll make electronic versions available for free
from the Onyx Neon site. We hope to have ePub versions ready in the next two
weeks. We'll also put raw HTML online on modernperlbooks.com at the same time
(this also allows us to link to translations with greater ease). In addition,
we're making most of our publishing tools available as CPAN distributions,
including the formatting modules (Pod::PseudoPod::DOM) and the
rendering pipeline (Pod::PseudoPod::Book). This will allow you to
make your own version of the book in other languages if you desire, or to
create new and attractive books in many formats. We'll make our own Kindle
version, rather than using Amazon's conversion tools (they didn't work as well
as we'd hoped), and we hope to get the book in the Nook store as well.
We plan to release a new version of the book late this year or early next
year to cover 5.14 and 5.16. We'll almost certainly drop support and mention of
5.10.
We couldn't have done this book without you. Thanks for reading. Please
share with your friends.
12 January, 2012 i
books,
modernperl,
perl5 |
Comments Off
Buddy Burden explanation of taking over maintenance of CPAN distributions is important. It's empowering. If you've ever thought "I should contribute something to Perl", start there.
You can do it.
Sure, it's easy for me to say that. I've written a few things about
Perl a few people have read. I have a few patches in a few projects and a
couple of modules on the CPAN myself. (You're reading this, aren't you? So I
have at least one reader. Thank you for your time!)
Even with all that in mind, two questions still come up far too often, and I think they prevent or delay us from providing code and documentation for other people to use freely:
- Does anyone care?
- Is it good enough (yet)?
You can see this attitude in the recurring debate over the responsibilities of authors. While some people say it's irresponsible or childish or unprofessional to upload code without full test coverage or complete documentation or an iron-clad promise to respond to every bug within 24 hours with a fix, an apology, a new release, and a sandwich (and yes, I exaggerate for effect), we're doing each other a disservice setting these demands on ourselves and each other.
Yes, we should do our best.
... but yes, we can start from something small and incomplete and
refine it in smaller steps. It doesn't have to pass every test on every
platform known to man if you can get feedback on where it fails and release a
new version tomorrow. It doesn't have to have every feature you plan to add, if
it does something useful that other people might want to use today. It doesn't
have to have every option documented if it's usable right now.
I'm not suggesting that we allow ourselves to be irresponsible with what we
share, but I am suggesting that we can allow ourselves the freedom to share a
little earlier and a little more often. We have the ability to upload new code
every day (every hour!) if we want.
So what if it's not perfect? Even if you waited until you thought you'd achieved perfect, you probably would miss, even by a little bit.
Start small. Do your research—work to your best quality—but let yourself hit smaller goals and make things a little bit better a little more often. Share earlier. This is a lot better for everyone.
9 January, 2012 i
cpan,
modernperl,
perl |
Comments Off
These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.
9 January, 2012 i
conferences,
cpan,
Perl 5 |
Comments Off
The Modern::Perl CPAN distribution is much more conservative than I think most people thought it would be when I first released it. (Count me in that group.) Where I once intended to collect a bunch of useful CPAN modules in the style of Task::Kensho or perl5i, both of those do what they do far better than I can do.
Instead, I see Modern::Perl as enabling the core features I wish were on out
of the box by default in Perl 5. While it'd be nice to pull in Try::Tiny and sometimes I
might wish for fatal warnings, the former is not a core module and the second
isn't something I use in every program.
Consequently the module hasn't needed much maintenance. Yet I've added a couple of missing features that should keep it useful and usable into the
future. I uploaded a new version yesterday and will upload one more today with a little bit more polish.
First, it now requires autodie as a distribution
dependency. It doesn't load autodie, but installing
Modern::Perl on 5.10.0 will also install autodie. (Anything 5.10.1
and newer includes autodie in the core.) You don't have to use it,
but now you can rely on any Perl considered modern to have autodie
available.
Second, it now loads IO::File and IO::Handle so that you can
call methods on lexical filehandles without having to load either manually.
Perl 5.14 fixed that usability niggle, but Modern::Perl fixes this for people
using 5.10 or 5.12. (Why both? I can never remember which one superseded the
other in 5.12, but better safe than sorry. I welcome a patch to load one over
the other with a version check—and please test carefully.)
Third, I added unimporting support so that you can write no
Modern::Perl; within a scope to disable strictures, warnings, and
language bundle features. It's an all or nothing switch and will remain that
way, but I can see this being useful in specific cases, especially when
updating older code in stages.
Finally I added date support to importing. If you write use
Modern::Perl; you'll get the features of Perl 5.10 (with the caveat that
if you're using Perl 5.11.3 or newer, you also get the
unicode_strings feature, of which all you're likely to notice is
that Unicode strings work better in more places).
Yet for forward compatibility, you should be using:
use Modern::Perl 2012;
... which enables 5.14 features. You can use 2009 and 2010 to get 5.10
features and 2011 to get 5.12 features. If you use the wrong date on the wrong
version of Perl 5, you'll get an error, which is as it should be.
Next year I'm likely to drop support for Perl 5.10, in which case you'll
probably get an error message that that year isn't modern enough, but I could
be convinced to do a version check instead. I haven't decided. The tradeoff is
between providing a minimal module suitable for use in programs which helps
people write better code from the start and between telling people what they
should and shouldn't use. Besides all that, the relevant code is only a couple of dozen lines of very simple Perl. Anyone reading this can reimplement it almost trivially.
Of course, this all comes about because the Modern Perl book
goes to the printer today. We're very proud of the new 2011-2012 edition which
concentrates on Perl 5.12 and Perl 5.14. It addresses all of the known typos
and confusing parts of the previous edition, covers new features in Perl 5.14,
and is, from all reports, even better than the first edition.
The book should be in stores in the next week or so, and we'll have
electronic editions up this month for free download and redistribution. (We
hope you tell lots of people to buy the print edition because it's great and
more people need it on their desks, but sharing is caring and we support
that.)
5 January, 2012 i
books,
cpan,
modernperl,
perl,
perl5 |
Comments Off
