A few days ago I released a hacky script that re-formatted e-books from Project Gutenberg so they worked better on a small screen and then used a third-party utility to convert them to Palm Doc format.
To make it easier for non-geeks to install, I've re-written it as a module on the CPAN (with a supporting script that gets installed at the same time) which uses Palm::Doc instead.
I wanted to be abe to commit to my CVS repository while I was offline - eg while using my laptop on a train. But CVS doesn't support that, and to make it pretend to support it would involve some quite monstrous hacks. Of the commonly used VCSes, only git supports offline commits, so I decided to try that instead. There are some excellent instructions here which mostly Just Work.
There are two small flaws. First, it died importing this file. I couldn't be bothered to analyse why, and just deleted it and its history from the local copy I'd made of the repository (I used rsync to suck it down from Sourceforge). Contrary to the documentation, 'git cvsimport' does not carry on where it left off if it gets interrupted half way through, so once I'd deleted the offending file I had to also delete the broken git repo and start again. Once it had finished I then added the most recent version of the file to the git repo in the usual way. So I lost the history of that file. Thankfully it doesn't matter in this case.
The second flaw is a minor one. It tells you to delete the repo's contents leaving just the
First impressions of using git as "CVS with offline commits" are good. It works very well for a single user editing code in various different places throughout the day. I have yet to experiment with multiple concurrent edits. While I'm sure it works well if you use git in a distributed fashion, I still don't quite trust it to work in a similar fashion to CVS, with multiple users pushing changes to a central repository. But if I have any problems, you can be sure I'll grumble here about them.
I am embarrassed - nay, ashamed! - to have to confess that I didn't bother to run the code through all my various CPAN-testing machines before releasing it, and so I let something escape which only works on perl 5.10. Aaiieeeee!
Mind you, you'll only notice the bug on 64-bit platforms and there's not a lot of 64 bit perl 5.8 or 5.6 around.
I fixed a fairly major bug in File::Find::Rule::Permissions (it was interpreting the 'other' access bits as being permissions for all users, as opposed to all except the owner and users in the owning group) and also added tests. Yes, it now has real tests. OK, so they're all mocked up because to do real real tests you'd need to be root so you could create files with weird owner/group/permission combinations. Actually, they're not all mocked up, because if you're stupid enough to run the tests as root then exactly the same tests run for real.
Second, I've fixed a cosmetic bug in Number::Phone::UK, and added some stuff to Number::Phone::Country (thanks to Michael Schout) so that it can tell you what the national and international dialling prefixes are for any country. There's also the usual UK phone number allocations database update.
Lyle pointed out another problem with how CPANdeps detects distributions that contain both XS and a "pure perl" alternative implementation. Some distros name the pure-perl implementation Blah::PP or something similar, instead of Blah::PurePerl. Unfortunately, PP can mean a few other things too. The only way to get this absolutely right is to manually examine all distributions that look like they might contain some non-perl code, so rather than do that and build a database that the application can use (a database that would go out of date overnight), I took the lazy route and just wrote up some explanatory notes on exactly how the "purity" option works.
For authors who want to help my heuristic show the right result for your modules, then all you need to do is include the string "pureperl" (it's case-insensitive) in your MANIFEST file.
... =~ /
which looks for some stuff, followed by either a space or the end of a line. It uses
Perl isn't dieing, but it tells me that it wishes it was. Last night it went out on the piss with Python and Ruby (PHP was the designated driver) and it did rather too many cocktails. It isn't quite sure what happened, but it woke up in the gutter in a puddle of its own fluids and its head hurts a lot.
It asked me to ask you all to keep the volume down.
> select count(*) c, os from cpanstats group by os order by c desc;
Oh dearie me. Fittingly, the next vendor in the Hurders' sights is SCO.
CPANdeps has been getting more heavily used recently, and all of the users hitting my shonky code have been occasionally DOSsing the server. That's because the old code would eat up to 134MB of memory to generate a set of results. And that's because I was using Parse::CPAN::Packages to convert from module names to package names. That reads the entire 02packages file into memory and converts it into a very large data structure.
The new version of the code stores that in the database instead, so instead of using 134MB I now only use 25MB per request. This means that I'm hitting the database harder, but even so, things should still run a lot better because even serving 25 requests in parallel (the maximum it's configured to do) it will only need 625MB, so you won't all be fighting over swap space.
I would like to thank Jonathan Rockway once again for writing the excellent CPANdeps test suite which lets me be confident that the site still works just as it did before. His test suite is available on the CPAN as Angerwhale