97 posts tagged “perl”
Catalyst 5.7014 is out the door. Hopefully that will stop the flood of questions about a "strange uri_for() behavior." With that done, I've taken out 5 more RT tickets.
Two extremely old wishlist items were rejected (RT #26758, RT #24132). This is basically due to the fact that they were over a year old, and really should be talked about on the dev list if they are still inclined to have them resolved.
A couple others required that I cook up a test or two to ensure the patch was applying was satisfactory (naturally, we would always hope to have a test submitted along side the patch): RT #26455, RT #34437.
The last ticket seems to have been related to a regression in 5.7013, as the ticket author claims the latest release fixed the issue. Closed! (RT #35994)
I've put the 5-a-day thing away for a bit to focus on other things. Firstly it was trying to get a new release of Catalyst-Runtime out the door (5.7013 hit CPAN on the 17th). One of the last bits preventing that release was some back-compat methods for Catalyst::Stats so it could mimic Tree::Simple behavior, which is what $c->stats() used to return.
Unfortunately, this release introduced two regressions, now fixed in svn:
1) "sub foo : Path {}" in the root controller didn't work.
This was as a result of my attempt to allow Path(0) to match properly. A simple 1-line fix resolved this problem. This bug also prevents some components' tests from working successfully (so far Catalyst-Model-Adaptor and Catalyst-Plugin-Unicode) as they used this idiom in their test apps.
2) invalid namespace for relative arguments to uri_for from an action that was run from a $c->forward() command.
Since there are a few conditions to satisfy before this bug appears I'm not too suprised it snuck in to the release. Peter Karman provided a much needed test case and the simple fix (remove "local $c->{namespace} = $self->namespace") which i've included in the 5.70 trunk.
I hope we can get 5.7014 out the door relatively swiftly.
I've also fixed up a couple of Catalyst::Plugin::Authentication RT tickets. Both were simple pod fixes: RT #36062, RT #36063
I ventured into some DBIC related bugs this time.
RT #32497 - rejected (Catalyst::Model::DBIC::Schema)
RT #31848 - doc fixed (Catalyst::Model::DBIC::Schema)
RT #29282 - duplicate (DBIx::Class::Schema::Loader)
RT #23749 - already patched this last year (Catalyst::Plugin::Session::State::URI)
RT #20142 - closed (Catalyst::Plugin::UploadProgress)
RT #32276 - rejected (Catalyst::Runtime)
RT #26732 - closed (Catalyst::Runtime)
RT #34293 - duplicate (DBIx::Class)
RT #32988 - pod fixed (DBIx::Class)
RT #33217 - closed (DBIx::Class)
I ended up doing twice my quota for today (it's easy to take care of the low-hanging fruit). A variety of Catalyst::* and DBIx::Class tickets were closed.
RT #15941 - rejected (Catalyst::View::TT)
RT #32254 - duplicate (Catalyst::Plugin::Authentication)
RT #30506 - closed (Catalyst::Plugin::Authentication)
RT #33302 - closed (Catalyst::Manual)
RT #32091 - closed (Catalyst::Manual)
RT #29496 - duplicate (Catalyst::Manual)
RT #32636 - pod fixed (Catalyst::Manual)
RT #34256 - dependencies updated (DBIx::Class)
RT #33667 - patch applied (Catalyst::Session::Store::FastMmap)
RT #32393 - closed (DBIx::Class)
The Ubuntu "5-A-Day" campaign has caught my eye. It's turned a heinous task into a bit of a game. It reminds me a little bit of the ESP Game for image tagging (i.e. boring task => game).
I don't expect I could ever really take care of 5 bugs every single day, but I've given myself a little jump start by closing 7 Catalyst-related bugs yesterday. Only one of them took a significant amount of time to fix as it required some patching to the various parts of the Catalyst dispatch cycle.
Here are my five (plus two):
RT #30660 - Just needed to be closed
RT #30087 - Again, just needed to be closed
RT #35690 - Fixed POD
RT #33236 - Tiny grammar fix
RT #29334 - Fixed in trunk
RT #26452 - Test workaround in trunk
RT #24743 - Latest Catalyst::Manual upload fixes this
I've been using Ubuntu since Dapper was released. As Hardy is the next LTS release, I decided now would be a good time to blow the whole thing away and start fresh. At the same time, I thought I could give rid of some KDE-based software I've been using and stick to a strictly Gnome environment.
I've been using Amarok as my media player, but, as stated above, that doesn't jive with a pure Gnome setup. By default Rhythmbox is installed. I can import all of my tunes in no problem, but I'm missing some play stats.
Given my old Amarok database, which is just an SQLite database, and a Rhythmbox database, which is a simple XML file, with freshly imported tunes I was able to write a script to pull out some of my old data including: rating, import date, last play date and play count. NB: Rhythmbox ratings don't understand half-star ratings, though it doesn't complain.
Usage: import.pl rhythmdb.xml collection.db
use strict;
use warnings;
use XML::Simple;
use DBI;
use URI;
my $xml = shift;
my $data = XMLin( $xml, KeepRoot => 1, ForceContent => 1 );
my $dbh = DBI->connect( 'dbi:SQLite:dbname=' . shift, undef, undef );
my $sth = $dbh->prepare( 'select rating, playcounter, createdate, accessdate from statistics where url = ?;' );
for my $row ( @{ $data->{ rhythmdb }->{ entry } } ) {
my $mp3 = URI->new( $row->{ location }->{ content } );
next unless $mp3->scheme eq 'file';
$sth->execute( '.' . $mp3->file );
my $dbrow = $sth->fetchrow_hashref;
$row->{ rating }->{ content } = $dbrow->{ rating } / 2;
$row->{ 'play-count'}->{ content } = ( $row->{ 'play-count'}->{ content } || 0 ) + $dbrow->{ 'playcounter' };
$row->{ 'first-seen' }->{ content } = $dbrow->{ 'createdate' };
$row->{ 'last-seen' }->{ content } = $dbrow->{ 'accessdate' };
}
XMLout( $data, KeepRoot => 1, XMLDecl => 1, OutputFile => $xml );
Dear lazy-perl-web,
Has anyone done non-blocking access to USB devices? Device::USB uses libusb 0.1.x -- which only does blocking access. libusb 1.0 is to include callback-based access -- it's under development at least, but no perl bindings exist.
Is there anything else out there to try?
At $work, we decided that we kind of liked the idea of showing thumbnails of the sites we've linked in a particular section of our site. Naturally, there are existing services that can be used to do this. However, we weren't too hip on relying on those services.
We decided to try and make our own thumbnail service. We took an old machine, put Ubuntu (7.10) on it, and created a fairly simple script to control Firefox and generate the screenshots. It uses X11::GUITest to do the automation and Imager::Screenshot to process the screen:
use strict;
use warnings;use Imager::Screenshot ();
use X11::GUITest ();
use Digest::MD5 ();
use CGI ();my $start = '~/blank.html';
my @urls = load_config( shift );
my $destdir = shift;
my $id = close_and_reopen_firefox();my $count = 0;
for my $url ( map { CGI->unescapeHTML( $_ ) } @urls ) {
# skip "comments"
next if $url =~ m{^#};
# skip existing screenshots
next if -e gen_filename( $url );load_page( $url );
sleep( 20 );
take_screenshot( $id, $url );# reload firefox after 100 urls
if ( ++$count == 100 ) {
$id = close_and_reopen_firefox( $id );
$count = 0;
}
}# close firefox
X11::GUITest::SendKeys( "%({F4})" );sub gen_filename {
my $url = shift;
return "${destdir}/" . Digest::MD5::md5_hex( $url ) . '.jpg';
}sub take_screenshot {
my $id = shift;
my $url = shift;
my $i = Imager::Screenshot::screenshot( id => $id );# remove the scrollbar + scale
$i = $i->crop( right => $i->getwidth - 15 );
$i = $i->scale( xpixels => 150 );
$i->write( file => gen_filename( $url ), jpegquality => 75 );
}sub load_page {
my $url = shift;
X11::GUITest::SendKeys( '%({LEF})' ); # go "back"
X11::GUITest::SendKeys( "^(l)" );
X11::GUITest::WaitWindowViewable( 'Open Web Location' );
X11::GUITest::SendKeys( "${url}{ENT}" );
}sub close_and_reopen_firefox {
my $id = shift;
if ( $id ) {
X11::GUITest::SetInputFocus( $id );
X11::GUITest::SendKeys( "%({F4})" );
}X11::GUITest::StartApp( "firefox $start" );
( $id ) = X11::GUITest::WaitWindowViewable( 'Mozilla Firefox' );
sleep( 2 );
X11::GUITest::SetInputFocus( $id );
X11::GUITest::SendKeys( "{F11}" );return $id;
}sub load_config {
my $file = shift;open( my $data, $file );
my @urls = split(
"\n",
do { local $/; <$data>; }
);
close( $data );return grep { length } @urls;
}
Now, you might have noticed that we close firefox after 100 urls -- in reality, it never gets that far. Things seem to segfault around 25 urls in. I don't particularly understand why it's so unstable. We've disabled the "session recovery" feature so firefox won't get stuck asking questions on startup, plus fast back<->forward history rendering in case it was leaking memory.
Hopefully someone will find this bit of code useful, and perhaps someone has some ideas as to how we can make this setup a little more stable.
I've pushed an initial release of XML::Atom::Ext::OpenSearch to CPAN. It's a pretty simple add-on to XML::Atom that will lead you read and write OpenSearch enabled Atom feeds. This module has been in the works for nearly a year. I've been working with jshirley and miyagawa and with the release of XML::Atom 0.28, all of the bugs seem to be ironed out.
In the distribution, I've included a Changes file which is YAML-compatible. NB: I've also copied the file to Changes.yml as one cannot expect every Changes file to be YAML. For the purpose of discussion, here it is inline:
# Revision history for Perl extension XML::Atom::Ext::OpenSearch.
0.01:
date: Wed, 07 Nov 2007 08:39:38 -0400
maintainer: Brian Cassidy <bricas@cpan.org>
urgency: low
changes:
- original version
I've basically pilfered the ideas from the debian changelog specs. It's simple enough that it could be hand-generated, but at the same time parts could be auto-generated. Comments?
Neighborhood
Explore friends, family, friends & family, or entire neighborhood.
