On Tuesday, I released version 0.02 of Net::NationalRail::LiveDepartureBoards to CPAN. So far, no one has complained. This module is probably of interest only to people in the UK; it looks up which trains are next to arrive/depart from a particular station.
This release was prompted by a patch sent to me by Ian Dash, implementing a filtering feature I was too lazy to write myself. If someone wants to put a fancy GNOME applet around it, I'd be grateful. ;) I think the next step is to add a nicer OO interface.
My original reason for writing the module was to advertise this SOAP API that ATOC publishes - it could easily be wrapped in languages other than Perl. That particular URL was found by inspecting the official widget for Windows Vista.
Posted: 14 Jan 2010 19:41 | | Comments (1)
I wrote a plugin for Hudson today, which integrates Devel::Cover (Perl's test coverage tool) into the build reports.
Actually, that's currently an exaggeration. All it does is add a checkbox in the configure page, and a link to Devel::Cover's reports on the build page when it's enabled. I spent the day remembering how to program in Java.
Tomorrow I might be in a position to extend it into something more attractive - I'll publish it very soon, but I need to run it past my employer. Watch this space.
In other news, I volunteered to package Hudson for Debian, and then discovered just how many dependencies it has. This should keep me going until squeeze+1, I think.
Posted: 07 Jan 2010 00:44 | | Comments (1)
On Wednesday, I fixed #551228 in libgstreamer-perl - from the bug log, it looked like it would be an intriguing parallel-build problem, but I reckon it was just a faulty test.
Next I applied a patch from the upstream bug tracker for #544894 in libtk-filedialog-perl, which was fine; but then we noticed that there was no explicit copyright notice in the source, so it hasn't been uploaded yet. The code is from 1996, so we would request removal from Debian if it weren't for 'horae' depending on it. Hmm...
Then yesterday I found the time to test #520406 in libdbd-mysql-perl, which I remember being open as long ago as DebConf. It turns out it's dead easy - there's already a test case and a patch upstream, which was applied a while ago, so the bug is already fixed in squeeze. Today I prepared an updated package to fix this in lenny.
So, I'm still falling short of one RC bug a day, and pkg-perl has more RC bugs open than at the start of the week. :( The weekend's not over yet, though.
Posted: 14 Nov 2009 15:42 | | Comments (1)
I've been writing some Perl DBI code which involves some fairly involved error handling; I've been looking for a way to roll back transactions neatly when certain errors happen.
I very nearly reinvented the concept of a 'transaction scope guard' which I now find is implemented in DBIx::Class (with Scope::Guard implementing a more general version). A lexical variable can be used to detect in which cases a transaction should be ended, because the object it points to will get DESTROYed when it goes out of scope. Some rough code to illustrate the concept is below.
# $fallback controls whether we use nested transactions,
# which is slower but lets us commit all the other lines in the batch.
sub process_batch {
my $fallback = shift;
# This catches any exception handling that makes us leave the function.
# The DESTROY method of $transaction contains $db->rollback()
my $transaction = $db->txn_scope_guard();
for (1..2000) {
# File access error will get thrown to outside of function,
# so the transaction will be rolled back.
my $line = get_next_line();
last unless $line;
my $parsed;
eval {$parsed = parse_line($line)};
if ($@) {
# Handle line parsing errors here without interfering with
# DB error handling.
warn "Could not parse $line\n";
next;
}
# here's the actual db code
eval {
$db->savepoint() if $fallback;
$db->process_one_line($parsed);
}
if ($@) {
if ($fallback) {
# Just roll back to savepoint. Transaction continues.
$db->rollback_to_savepoint();
} else {
# Propagate error outside of function, ending transaction.
die $@;
}
}
}
$transaction->commit();
}
The advantage is that rollback code can be kept in one place, and not repeated all over the various error handling cases.
I had actually gone off this idea, because I couldn't see any documentation defining exactly when the DESTROY method gets called in Perl. But given it's got into DBIx::Class, it must be fine! I also prefer their API over what I was considering implementing; the transaction object that gets returned will handle only commit(), not any other database calls.
Posted: 25 Oct 2009 01:11 | | Comments (0)
At work, I have been refactoring old Perl code. Part of me feels that this was tangential to the main aims of the project I've been assigned, but another part of me can list all the bugs I've found/fixed and the advantages in terms of maintainability, so on balance I think it was a good idea.
Something I like even more than tidying code is reducing the amount of code required. (I've been doing a lot of that as well.) Breaking code into reusable modules is the essence of what I'm trying to achieve - later projects within the company (and perhaps beyond) should not have to reinvent what I'm writing. I'm attempting to replace boilerplate code with existing modules from CPAN where I can - I'm fortunate in that this seems to be possible licensing-wise within our product.
Now, there is some code which loops over a list of plugins, and forks off a background process to deal with each of them. Which CPAN module should I use? There are a few which look promising (like the classic Proc::Daemon), but force the parent process to exit. Not good for a loop. There's one which does dodgy hacks with parsing the output of 'ps', rather than using 'kill 0 => $pid' like every other module. Some handle pidfiles (which I want, provided I can customize the name, but what if I didn't?), and some don't (which is fine, I'll just use one of the separate pidfile modules). But why do CPAN modules reimplement the pidfile handling themselves anyway?
One of the best approaches I've seen so far is MooseX::Daemonize. Moose's role system looks like it would be very useful, but I'm a bit hesitant to introduce Moose to the company just yet. Maybe I should.
My point is, there is all this code, but subtle problems are preventing its reuse. I see the same thing going on at work; there are some utility libraries, but they contain large numbers of mostly unrelated functions. Developers often do not spot code which might be useful later, so they are left as a subroutine in a script. Ironically, I am reimplementing these functions in a more modular fashion, and hopefully this will catch on.
Posted: 04 Oct 2009 23:27 | | Comments (0)
I spent the last day and a half writing a vaguely interesting Perl module for testing some code which gives a subtly different answer each time (i.e. incorporates data from time() and /dev/urandom) and has side effects (i.e. writes to the file system).
By overriding Perl's built-in 'open' function, it is possible to prefix each filename with the location of a temporary directory, effectively emulating chroot(). I also replaced Perl's time() with one that always returned the same answer. This meant that the login code I was testing would return a reliable result.
You have to be careful with prototypes. Spot the difference:
my $result = gmtime(time+$seconds); my $result = gmtime(time()+$seconds);
Without adding a prototype to the new time() function, these will give different answers. I now have to go back to work tomorrow and close a bug I mistakenly filed. :)
I'm hoping to finish off my evil hacky overriding module and release it to CPAN. I want to add some routines to set up and tear down temporary chroot directories. Obviously there are some limitations to my approach; I'm not currently handling relative paths very well, and system() calls will not be "chrooted". But it should be quite handy and reusable in any case.
Posted: 09 Sep 2009 19:16 | | Comments (0)
I am not having a good year.
Traditionally, when annoyed, I make extravagant purchases that I may or may not regret later. In this new economic climate, however, I have found a substitute outlet.
Arriving soon at a CPAN mirror near you: Net::NationalRail::LiveDepartureBoards 0.01 - an interface to a SOAP API from ATOC. Given a station code, you can obtain the next few arrivals/departures/both.
This is in hacky Perl, but the module should be easy to translate to other languages which have SOAP libraries.
Posted: 08 Jan 2009 00:00 | | Comments (1)
I tend to update DateTime::Event::WarwickUniversity at around this time each year, according to the changelog. Version 0.05 will appear on CPAN with the next update. My testcases still pass, at least.
Posted: 01 Nov 2008 00:00 | | Comments (0)
Following my update on Monday, I've made changes to the build systems of both DateTime::Calendar::WarwickUniversity and DateTime::Event::WarwickUniversity, in my search for higher kwalitee. These are not important updates, they just add a few more tests, and so on.
Posted: 22 Nov 2007 00:00 | | Comments (0)
Warwick University appear to have changed some of their future term dates, so I have released version 0.02 of DateTime::Event::WarwickUniversity to CPAN.
This release also fixes bugs which were happening when using DateTime objects with time zones, so everyone should probably upgrade.
Overall, I'm surprised that it took me a year before I had an excuse for a new release. It would be worth adding the ability to get a real date from a given term week, but I haven't quite needed it yet.
Posted: 19 Nov 2007 00:00 | | Comments (1)
| < | January 2010 | > | ||||
| Su | Mo | Tu | We | Th | Fr | Sa |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 | ||||||
Tim Retout tim@retout.co.uk
JabberID: tim@retout.co.uk