Testing Perl 5.10.1 RC 1

UPDATE: Since this blog post was written, this got a lot easier with perlbrew. I wrote about this here There's a new stable release of perl in the works - Perl 5.10.1 - that's reached "Release Candidate" stage.  In other words, we've got a shiny new version of the perl interpreter and associated core Perl modules that the pumpking (the person in charge of the release) thinks is ready, but he wants us to all test it on our systems with our code to make sure that there's no problems he can't spot himself before it's finally released. So how do we do that? Well, we can follow gugod's instructions to build a version in our home directory. Below is what I did for my system (a Mac OS X 10.5 box, with the developer tools already installed from the CD that shipped with the computer) First we download and extract the distribution:
bash$ wget http://search.cpan.org/CPAN/authors/id/D/DA/DAPM/perl-5.10.1-RC1.tar.gz
bash$ gunzip -c perl-5.10.1-RC1.tar.gz | tar -xvf -
bash$ cd perl-5.10.1-RC1
Then we then configure it.
bash$ Configure -de -Dprefix=${HOME}/local
-de means "Accept the defaults" and "Go on accepting the defaults". -Dprefix tells the installer where to install - in this case in "local" in our home directory where it won't interfere with the system Perl. We then can tell it to build, test, and install itself.
bash$ make
bash$ make test
bash$ make install
This all will take some time. Either go make a cup of tea, or just get on with something else. Whenever I want to test the new version of Perl I can use the export command to modify my path to put this new perl first.
bash$ export PATH=${HOME}/local/bin:${PATH}
This means that when I type perl from my shell (or use any of the other perl utilities in this shell) from that point on it'll run the version of perl I'm testing rather than the system perl that came with my Mac.
bash$ perl -v

This is perl, v5.10.1 (*) built for darwin-2level
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2009, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
We can now start installing modules from the CPAN in order to test out our new perl. I must admit that I jumped straight for the big guns: Task::Kensho. "Tasks" are psudo-packages that you find on the CPAN that don't really contain any code of their own, but just provide documentation and depend on a bunch of other modules. They're a common way to load a collection of modules. Task::Kensho is one of the big ones here - it's a large-ish collection of modules that are commonly used by modern Perl programmers, and installing it basically will tell cpan to install all the modules that I need to get up and running and start being productive. It took me about an hour to install all of these modules from a local on disk cpan mirror I had previously created with minicpan, but quite a lot of that was delays caused by me configuring my cpan shell to prompt me before doing anything (because I wanted to keep track of what it was doing, as I was testing the new release candidate.) All in all it was a fairly painless experience. I look forward to the release proper of 5.10.1 in the near future!

Share "Testing Perl 5.10.1 RC 1"

Share on: FacebookTwitter

say "Hello World"

This is a blog.  There are many like it but this one is mine.

-- badly paraphrasing Full Metal Jacket

Hi.  You might know me.  I'm Mark Fowler.  No, not the fictional guy from Eastenders or the deceased serial killer, but the Mark Fowler whose best known on that there Internet in connection with the Perl programming language. And I've decided to do a very silly thing.  Matt Trout, king of the rants and opinions, is trying to encourage more people to write Perl blogs.  And I said that not only that I would but I'd also post at least once a week as some part of a crazy iron man challange.  Ooops.  That sounds like a lot of work. Why have I decided to do that?  Well, I do a lot of Perl stuff that's worth talking about, but I don't really write about it any more, which is a shame because I think it's interesting at least. I used to enjoy keeping a very active blog on use.perl.org, but I got fed up with the whole primitive nature of use.perl.org. It was obviously time to move somewhere else.  And being a geek, I though it might be fun to write my own blogging engine to do that.  This is Yak Shaving at it's best. How long could it possibly take to write your own blogging software?  Well, if all you want to do is knock out a few pages of text, not long at all.  If you however want rich GUI editors, open ID support, trackbacks, comments, anti-spam filters, gravatar support, previewing and draft posts, workflow management, and about a gazillion other things that make up a modern blog it might take a smidgen more than not long at all. This is even more of a problem if you've in fact got less than a smidgen of spare time because:
  1. You're a professional Perl programmer who spends all his time doing much more serious Perl development or running teams doing professional Perl development, so you don't actually feel like doing boring aspects of projects in your spare time.
  2. You hence look for shiny and fun projects to play with in your spare time because it's your spare time, so you want more instant payback.
  3. You took on a big project half way through the rewrite that's much much more fun, but very demanding on your time and can't be put down.  Little baby geek in training, I'm looking at you ;-)
In other words it went the way of all other programming projects:  The requirements were not properly scoped and estimated, and the fact that other, more pressing projects had to be delivered in the same timescale wasn't accounted for. You see, I forgot to apply one of the virtues of a Perl programmer;  Laziness. Or, put another way, I should have applied a little agile methodology and done the least possible thing I could have done to get the desired result.  What I should have done is said "What software have other people written that I can use, and if need be, alter to do what I need.".  Or, in the days of cloud computing, I should have said "What hosted service can I use that does everything for me, from deployment to working out how to make it scale."  So now after spending literally minutes filling out forms online I have a wordpress blog and I can actually start blogging again. So, having started the new blog describing how much of a Class One Idiot I am, why should you listen to me?  What am I likely to discuss? Posts that are in the draft folder currently include
  • A bunch of discussion of Perl modules I've started using in the last few years.  I used to review 25 modules a year for the Perl Advent Calendar and I miss writing about cool modules.  (I don't miss the grueling post-per-day schedule however)
  • How Devel::Declare is allowing redevelopment of the Perl language directly from the CPAN, and how we're even using in production now
  • Something on how Ash Berlin's TryCatch module is the improvement to Perl I've been waiting for my entire programming career.
  • Waffle on XML::Easy, my new favourite XML module of choice, and how I used it to create Test::XML::Easy.
  • Improvements to my Perl modules;  Where I'm heading with Test::Builder::Tester after leaving that code base dormant for so long.
  • How I'm moving all my code to github, and what changes I'm making to the packaging of all my CPAN modules as a matter of course as I do so.
And eventually I'm going to talk about my super secret Perl project when it comes out of stealth mode.  But I'll leave that for another post...

Share "say "Hello World""

Share on: FacebookTwitter

blog built using the cayman-theme by Jason Long. LICENSE