December 2007 Archives

The Perlbuzz section CPAN Watch is going on an indefinite hiatus. Kirrily Robert, Skud, who has driven CPAN Watch since its start, is moving to San Francisco from Australia, and just doesn't have the time to keep things going.

I'll still be keeping you informed about cool new CPAN releases, but instead of CPAN Watch I'll be putting them in the Mechanix section. So, point your RSS/Atom readers over there for now.

I've just uploaded CPAN::FindDependencies version 2 to the CPAN. This is pretty much a complete re-write which has lots of cool new Stuff:

• uses Parse::CPAN::Packages instead of CPAN.pm, so loads faster and takes a lot less memory;
• much better core module detection;
• user can specify which version of perl to use when figuring out what's in core;
• can cache META.yml files and use a local 02packages file instead of fetching it from a CPAN mirror at startup;
• add 'maxdepth' parameter to limit how far down the dependency tree it goes;
• much better tests;
• 'cpandeps' script is now documented

Why am I telling you this? Cos, for the perl-qa folks, this will be the new brane for http://cpandeps.cantrell.org.uk/ soon. For the module-authors list - the bundled 'cpandeps' program is a useful tool for getting an idea of how much extra code gets pulled in when you make your users install a dependency. Re-using code is a Good Thing of course, but taken to extremes it can be a real pain in the arse for those for whom perl is just another environment that they have to support on their machines.

I wrote about David's dependency checker before, and it's pretty slick.

Yann Kerherve has released Find::Lib, an alternate way of loading libraries in non-standard locations. Find::Lib lets you specify paths like so:

use base Find::Lib '../bootstrap/lib' => 'My::Bootstrap', %param;

I'd love to hear from anyone who's used it and what they think.

ack is my replacement for grep geared to large source trees. I've just released 1.75_01 (a developer release, please note) which is a big speedup for what I suspect is the most common case of scanning large directories of many relatively (<100K) small files and not finding matches in all of them.

Here's what it does: It checks the size of each file, and if it's <100K, slurps up the entire file. Then, it scans the entire 100K file at once, and if there are no matches, then there's no need to do the line-by-line more expensive searching.

In my test scanning a couple of big source directories like ~/parrot, it saved about 40% run-time. If I had -C or -B to store context, it saved about 70% run-time because the saving of context is more expensive.

So, please, check it out and make sure all is still working. Also, any eyes on the algorithm I'm using would be appreciated, too. I'm sure I can do things cleaner or a bit more speedily, but right now I'm mostly worried about accuracy.