Perlsphere

Test::Most::Exception - Important, But You Won't Need It

nobody@example.com (Ovid) — 2008-11-17T15:29:24Z

Recently I uploaded the new Test::Most. From the end user perspective, the only real change (aside from being a touch easier to install), is that if you ask it to die when a test fails, it no longer just dies. Instead, it throws a Test::Most::Exception. The vast majority of people will never, ever need this feature. However, our test suite gets a bit tricky at times and we do things like this:

foreach my $test (@tests) { my $tests_finished = eval { $test->run }; if ( my $error = $@ ) { report_error( $test, $error ); } else { ... } }

Internally, the way we report failures depends very much upon whether or not the tests halted because Test::Most was told to halt on failures, or whether they really died. Now I can just do this in the &report_error sub:

if ( eval { $error->isa('Test::Most::Exception') } ) { ... }

And much grief is saved.

In other news, I've been asked to add timing data to Test::Aggregate and I've thought that prove's state mechanism should possibly be extended to capture aggregated state information. In other words, while I didn't really intend to, I'm writing yet another new test harness. You would think I've learned my lesson after writing the new Test::Harness (also by accident, I might add).

And yes, I've toyed with colored test output for it ...

Why Dist-Zilla is Probably Not For Me

nobody@example.com (Shlomi Fish) — 2008-11-16T08:44:37Z

rjbs' introduction to Dist-Zilla piqued my interest, and I used CPANPLUS-Dist-Mdv to prepare .rpm's for it and its depenedencies and install them. However, I wondered about a potential problem with it, before I even tried it, and speaking with rjbs on IRC confirmed that it exists.

Dist-Zilla generates the resulting .pm, scripts, etc. from templates, and as a result the lines that are reported by errors and warnings are not the same as the ones you've edited. This makes tracing lines back to their source much more difficult. Since most of my times is spent debugging and handling errors (whether I encounter them or I find them on CPAN testers or in bug reports), and I want to edit the source directly, I think that Dist-Zilla is not for me. What instead I'd like is a way to change common, repeated text (like version numbers, licensing, URLs, etc.) commonly across all the files in a certain distribution, or in many distributions. That and also that module-starter (or whatever) provide scaffolding for creating a new .pm file.

I appreciate rjbs's efforts, but I'm going to stick with module-starter (and contribute to it).

Perl 5.8.9 RC1 is out

nobody@example.com (acme) — 2008-11-12T14:22:32Z

Amelia

As Nicholas pointed out on the front page of use.perl.org, Perl 5.8.9 Release Candidate 1 has been uploaded to CPAN. It contains a whole bunch of changes since Perl 5.8.8. We have tested it on our machines. We have tested it on build farms. We have tested it with as much of CPAN as we could. What we haven't tested it with is the DARKPAN: your code, your computer and servers, your work code, or any of your modules. Blame Transfer Protocol initiated, as Nicholas points out slightly more informally on the London.pm mailing list: we would be very generous indeed if you could test the release candidate all code that you have to hand, and especially with work code. Think of it as your civic duty, if you lived in the city of Perl.

Read and post comments | Send to a friend

Gutenberg API

nobody@example.com (Ovid) — 2008-11-12T10:39:02Z

As far as I can tell from reading the archives and checking their Web site, Project Gutenberg does not appear to have an API. The closed I've found is an RSS feed and an RDF document. These don't really constitute and API, but the latter can be parsed for adding to an SQLite database. Still trying to figure this out, though. Trying to grab one version of their catalog in RDF format:

gutenberg $ tar -xjf catalog.rdf.bz2 tar: This does not look like a tar archive tar: Skipping to next header tar: Archive contains obsolescent base-64 headers tar: Error exit delayed from previous errors

I was able to unzip their .zip version of the same file, but I was disappointed to learn that their Perl examples are rather old and no longer appear to properly parse the data.

But why would you care? Because I think I want to make this happen:

gutenberg --read "Art of War"

You know, sometimes I worry about posting neat ideas to use.perl for fear that someone would jump the gun and Just Do It. I realize now that this is foolish for two reasons. First, they Won't Just Do It. Second, if they did, I'd be happy just to have the project done :)

Suggestions welcome. There needs to be an easy way to update the database, track what a user has read, allow them to "bookmark" a book (or better yet, "annotate" a document"), etc. I've never used an eReader. I never gave a damn about them, really, because I like the feeling of a book in my hands. Still, this seems worthwhile.

My 2nd generation release automation hits 1000 releases

nobody@example.com (Alias) — 2008-11-11T15:57:41Z

After moving from CVS to SVN a number of years ago, I heavily modified my original first generation release script to take advantage of some of the basic features of SVN, like everything being accessible by HTTP by default.

For example, you can see the current incarnation of my release automation directly in the repository here:
http://svn.ali.as/cpan/tools/release.pl
Because my release automation is so intensely tuned to the way I work, I've never felt that (as a whole process) it was worth foisting on the CPAN. I find it quite interesting that of all the people with 100+ CPAN modules, no two of them use the same release system, and all of them (except maybe SMUELLER) rolled their own.

So I release bits and pieces, the reusable components used to implement single tasks, and that's been enough for me.

After 1000 releases, however, my current system is definitely feeling the strain. Although it makes releasing extremely quickly, the lack of awareness of the overall repository is becoming a problem.

With so many packages, and several dozen external committers, it has become impossible to know which modules in the trunk match the most recent release, which have updates, and whether or not those updates are significant.

It's also impossible to do any form of bulk updates, bulk incremental release, or bulk releases (something that has always bothered me when I maintain Module::Install).

So to mark the 1000th release by my second generation release automation, I've commenced development on a new third generation "release" automation system that could perhaps be more accurately described as a "repository automation system".

Having recommitted to using svn for my repository (for reasons that may become more obvious later) and with the code likely to be tied very closely to the way I work, it will most likely be of no direct use to anyone else. And the "release" packages won't be going up to the CPAN.

But if you interested in the whole release automation area, you may wish to watch and see what comes out of it.

You can see the beginnings of this work at the following path:
http://svn.ali.as/cpan/trunk/ADAMK-Repository/
The initial first few "releases" will be focused on building up a cohesive object model of my own repository. The intent is to understand what modules are maintained in the repository, what releases have been done and WHEN (in repository revision terms) and what SVN path/revision pairs map to which conceptual places.

With this in place, a second layer of logic can focus on issues of release state vs repository state, on change (and who made those changes), and on knowing if modules are passing tests, and whether or not arbitrary external patches will break those tests.

And finally, now I finally have a good Perl editor in sight (albeit 6 months or a year from being ideal for me), I have a chance to tie the repository automation directly to my editor with a personal plugin that lets me just look at any file within a package, and run a "release" command from a menu and have everything needed to SAFELY release modules.

And man, THAT would be awesome.

Environments for Mojolicious

nobody@example.com (Sebastian) — 2008-11-11T14:09:04+01:00

Back in the days when i was working on Catalyst, i thought it would be a great idea to have a special debug environment. You could activate it with a simple -Debug flag in the import list. But what if your development process has more stages than development and production? Right, you are screwed. That's why we've decided to use a more ambitious concept we call Modes in Mojolicious, where you can have an unlimited number of different environments.

package MyApp;
use base 'Mojolicious';

sub production_mode {
    my $self = shift;

    # Production templates
    $self->renderer->root('/Users/production/templates');
}

sub development_mode {
    my $self = shift;

    # Development templates
    $self->renderer->root('/Users/dev/templates');
}

sub startup {
    my $self = shift;

    # Default templates for everything else
    $self->renderer->root('/Users/defaul/templates');
}

1;

As you can see we've chosen a very minimalistic approach that feels in line with the rest of Mojolicious. Switching between modes is as easy as changing a environment variable.

% MOJO_MODE=production bin/my_app daemon

Subtle improvements in Windows Vista

nobody@example.com (Alias) — 2008-11-11T03:06:25Z

I've moved my home 4-core parallel-coding/gaming machine over to Vista, following the typical "wait for the first service pack" approach that most people take when considering new Microsoft operating systems.

I have to say that it pretty much WORKSFORME and apart from a few different dialog boxes and what not I'm settling in mostly fine. And of course, being a developer, I've jealousy turned off all the eye candy to save the resources for myself :)

One of the more subtle changes in Vista that I hadn't paid attention to before but have noticed since I started doing some Padre coding on it is that Vista has changed the directory layout for home directories.

Instead of the previous (horrible) style...
C:\Documents and Settings\Adam\My Documents
We now have a much cleaner...
C:\Users\Adam\Documents

The obvious improvement here is for the server hackers and command line users, who have much less to type.

But one additional and more interesting benefit is that this change removes all of the whitespace from these paths. What attracts me most about this seemingly simple change is that in a single stroke it lets us avoid a ton of deeply buried bugs in certain very old Perl modules that require lists passed as whitespace-separated strings.

Avoiding these bugs is one of the reasons that Strawberry Perl is locked down to C:\strawberry, because if we allowed installation to arbitrary paths it would be too easy for people to enter whitespace-containing paths that might break things in unexpected ways. (The other reason is the lack of power in InnoSetup, which I'm in the process of fixing by moving to WiX)

It also simplifies things somewhat for people with whitespace escaping troubles.

Now granted, it doesn't FIX the problems as such. Escaping bug fixes now need to be done. But now the bug is not EXPOSED on quite so many operating systems it helps to limit the scope of the bug and reduce the impact from it between now and such time as it is resolved more thoroughly in all the various places fixes are needed.

The ultimate effect of this "whitespace tweak" is that Vista (and I assume Server 2003/2008 as well) are much better platforms for building Unix-originated Open Source applications on than XP was.

As much as I had grown to like "My Documents" (and File::HomeDir will continue to use the terminology in ->my_documents) I think this change represents a win for engineering over marketing, potentially at a slight cost to usability for computer novices.

But I guess that as a ratio of the population, computer novices are in a slow inevitable decline (at least in the developed world where the bulk of Microsoft's revenue comes from) so this does make some sense...

A case for Catalyst

nobody@example.com (Andy Lester) — 2008-11-10T22:51:16Z

By Jay Shirley

Software is like any other product that is depended upon for doing any particular function. Software, vehicles and computer hardware are all simply tools intended for a particular audience; audiences that tend to become polar, enthusiastic and fanatical. Whether it is the car tuning crowd, the overclockers or the Perl hackers, they share the same thing in common: being devoted to something.

This devotion drives a great number of innovations, and this is where Software really stands out. Particularly amongst the Open Source crowd, where Software is bound with something even more polarizing: Personality

The merging of software and personality is both a blessing and a curse. People are seldom more motivated than when working with something that feels alive; but to attack or criticize is, by definition, personal.

The people who are the most knowledgeable to defend, market, recommend (or even attack) are the ones already entrenched. They are part of the personality mesh, and as such it is exceedingly difficult to try to promote and defend a software product without going into the years of positive experiences one has shared with the product.

This article is no different. I love Catalyst and have used it for years. I will, however, attempt to back up my passion with articles of reason and rational points rather than espouse virtues that are little more than anecdotal.

To get started down this path, I think it is important to properly frame Catalyst in scope. On its own, it doesn't do much. It certainly doesn't do much well, but Catalyst by itself is really little more than a web server; it is a request handler and dispatcher and sends the response to the client.

By itself, it fails to talk to a database or handle sessions. It won't even authenticate a user. It has no template system, and no caching. So why does Catalyst have a fanatical fanbase and successful sites with it?

Quite simply, it's the CPAN.

The Catalyst philosophy is populist, not dictatorial. A belief that tools should be built to do a specific feature or function, but not require usage of any given tool; granting flexibility to a developer to solve problems the Catalyst community has not thought of how to solve.

Catalyst doesn't require you to use Template Toolkit or Mason. It doesn't push DBIx::Class as The One True ORM. It lets you pick. It trusts that you are a software developer and you are solving a problem. Catalyst just makes it easy to make your decision, and integrate that solution and start working. Between helper scripts and thin model adaptors (Catalyst::Model::Adaptor), there is virtually no hassle in integrating any CPAN module or custom code directly into your applications. The side-effect of the "trust the user" philosophy, aside from a fantastic framework, is that it is quite simply just that: a framework. It operates and evolves on the principles of synergy alone, striving to make the whole greater than the sum of its parts. A simple goal of striving to make a developers life easier, more productive and deliver higher quality results.

The results are easily quantifiable. Software development, at its core, is about solving a specific and well-defined problem. The more advanced the software is (in evolutionary, organic growth), the tasks at hand are solved more efficiently, properly and faster. The most significant improvements in development speed and quality come in the form of frameworks and libraries that have been peer reviewed, tested, poked and approved by the fanatical masses.

This lowers the barrier of entry to solve problems, and in general increases the supply of developers to meet the seemingly inelastic demand of problems that need solving. In effect, there is a framework for everybody, from the novice tinkerer who simply has an itch to scratch to the mathematically minded engineers that operate on puritan principles. Catalyst strives to match the pace of the whole spectrum, which is significant work. It makes the upfront learning curve a bit steeper than it could be. Looking historically over the documentation and tutorials, this will change and the learning curve will be greatly reduced.

The important thing that every developer, whether extending Catalyst or using just the minimums, Catalyst is simply a tool. Tools in the software sense are different than in the tangible world, they can change shape and function. They can easily be used incorrectly, or adapted and accidentally solve an unexpected problem.

Catalyst developers understand this, and the goal is to simply develop a robust foundation, particularly in the web application space, to solve problems. How those problems are solved is left up to the developer, though. The Catalyst community, just as the Perl or any other community, has suggestions and opinions but ultimately the responsibility lies on the developer. A core tenant of the Catalyst (and the greater Perl philosophy) is to trust that the developer knows enough to solve the problem. The tool should never impose philosophical beliefs; imagine if a hammer would only hammer specific nails, what problems could be solved then?

This lack of capability, or rather tools being an obstacle rather than an aid, was what drove Catalyst to grow and evolve. Taking original concepts from other frameworks (like Maypole) and extending those ideas in an open minded fashion, and also to use more modern development practices and factor out common code to be shared outside of Catalyst.

When Catalyst hit version 5.5 several years ago, the codebase was solid enough to call mature. It was grown up, but not done growing. At this point, the mature development cycle began and rather than a rapidly growing and changing framework, a stable and robust framework was in existence. This started a chain of high-quality (and some high-traffic) sites that were built on Catalyst. There was much rejoicing.

There are a lot of websites running on Catalyst, for a full list please view the Catalyst wiki.

Jay Shirley is a Catalyst evangelist, an EPO founding member and just another Perl hacker. He's launched and managed several large scale projects on Catalyst, as well. He is the co-founder of Cold Hard Code, LLC, a company set up to use Perl and open source technologies to spawn quality websites.

Module::Install paranoia

nobody@example.com (Phred) — 2008-11-10T19:55:11Z

==> Auto-install the 3 mandatory module(s) form CPAN? [y] n

==> The module(s) are mandatory! Really skip? [n] y

If I type 'n', do I really need to be reminded again??

The evolution of Perl frameworks

nobody@example.com (Andy Lester) — 2008-11-10T15:03:16Z

by Mark Stosberg

In 2006, the arena of Perl web frameworks pitted the heavyweight Catalyst against the lightweight CGI::Application. Since then Perl’s framework options have continued to evolve. While both CGI::Application and Catalyst remain popular, several new options have appeared lately. Here’s a quick rundown.

Titanium provides CGI::Application and a bundle of recommended plugins with unified documentation and easier installation. Because the underlying components are the same solid ones that have already been in use, it’s safe and stable to use, despite the new name. Future plans include providing a download package which bundles the dependency chain, for even easier installation.

HTTP::Engine is Moose-based evolution of the HTTP request object we saw in Catalyst, along with the abstractions to run web apps on various server backends. In short, it focuses on the HTTP parts of the web framework stack. On top of that you can build a complete framework in whatever style you want.

Mojo and Mojolicious represent a project lead by Sebastian Riedel, one of the original Catalyst contributors. Mojo is distictive for having no dependencies beyond core Perl. Mojo provides the same kind of low-level HTTP components as HTTP::Engine, while Mojolicious represents one possible complete framework built on top of it. Mojolicious’ distictive feature is a new dispatching design in the spirit of Ruby-on-Rails “Routes”. I have more in-depth review of Mojo.

Some trends I see:

Shared infrastructure — While Perl frameworks continue to compete at a high level, we continue to collaborate on shared utility modules. Projects like HTTP::FillInForm and Data::FormValidator get used by several frameworks, not re-invented.
CGI.pm must die — While we share some things, HTTP::Engine, Catalyst and Mojo have all invented their own HTTP request object, replacing the function of CGI.pm. Clearly there is an interest is moving beyond this old standby, which crams 172 subroutines into the CGI name space. (CGI::Application remains neutral on this point, outsourcing the query object)
Potential for convergence — A number of CGI::Application and Catalyst plugins are rather similar, but not interchangable. Because they are open source, they are usually easy to port from one framework to the other, but this is not ideal. HTTP::Engine and Mojo are both a kind of “framework for frameworks”. I see potential for projects to agree on which backend they use, while providing distinctive experiences for programmers who may want to choose a lightweight framework or a featureful one. The result could be web framework plugins which more widely useful to the Perl community.

Mark Stosberg has been using programming Perl for the web for over a decade. He is the Principal Developer at Summersault and maintains several CPAN modules including Titanium and Data::FormValidator.

MacBook Pros and Cons

nobody@example.com (Ovid) — 2008-11-10T09:39:55Z

Despite earlier protestations that I was getting fed up with Apple and may use Linux on my next Laptop, I broke down and, um, bought the new MacBook Pro 15". I'm ridiculously happy with it (no problems with connectivity this time!), except for one thing:

Why the hell did you screw up the keyboard, Apple?!?!?!

(The above pic is not really the keyboard, but it's pretty darned close)

I mean, the keyboard feels great and I love the fact that it lights up in the dark, but that's about it. Everything else seems to suck.

My first indication that I was going to have a problem was when I kept hitting the backslash, '\' instead of the "Enter" key. Apparently, on the European version of their keyboard, Apple thought it would be funny to introduce an extra-slim version of the enter key, one that's ridiculously easy to miss while typing. Thanks Apple!

Some of the keys just don't make sense to me. For example, I can now type the plus-minus sign (±) and the section symbol (§). While that's all well and good, unless you want a 573 key keyboard, sooner or later you have to give something up. What did they think was a fair trade-off? Hmm, where's the octothorpe/hash symbol (#)?

Excuse me? On a BSD based system they left off the hash symbol? I know various European keyboards push this symbol all over the place (it's shift-3 on US keyboards), so I hunted and hunted over my keyboard, convinced that I had missed it. Nope! It's not there.

I finally had to hit Google to find the damned key. Seems you have to hit alt-3 for that. This is just unreal. They gave up the '#' for the '±' and '§'? I'm dumbfounded. Apparently it's not like this on the US keyboard.

I hate C

nobody@example.com (schwern) — 2008-11-10T06:23:41Z

I'm in C portability hell with Time::y2038. The code to test the usable limits of the system time functions is touching off all sorts of fascinating bugs in various operating systems, many of which cause the test program to hang.

Oh, and then there's reports that "old" (read 2002) versions of Visual C++ don't speak C99 but some Microsoft extension gibberish. And, of course, Vista problems.

C: Fast, elegant, portable. Pick any one.

Also I need to add in code to test the limits of the system's mktime() and I haven't devised a sensible way to do that. I suppose I have to do a binary search over the year, then month, day, hour, minute and second. Oi, not fun in C. Maybe I'll just do it by year, that's really all the granularity I need.

Perl 6 and Rakudo command line to be worked on in earnest

nobody@example.com (Andy Lester) — 2008-11-09T22:55:36Z

The Perl Foundation has announced a Hague Grant for Jerry Gay to implement the Rakudo Perl command line interface.

The work will be to define the S19 synopsis pertaining to command-line interaction with Perl 6, and to provide a Rakudo implementation of the synopsis.

Jerry will need to document the Perl 6 command line syntax, implement its tests, create a command line parsing library for Parrot, and implement a subset of the Perl 6 command line syntax.

I couldn't be happier with this direction. I made some vain stabs at command line interaction on Rakudo long ago, but not much came of it. Having a command line interface will make it much easier for users to work with Rakudo as it progresses. Perl without being able to do filtering magic isn't very Perly, no?

Patrick Michaud also received a Hague Grant, to work on the Perl Compiler Toolkit and regexes and other internal hoohah. I'm sure it's useful, but this feeble-minded reporter's head hurt when trying to follow the details of the grant.