hoelzro

Still alive, Inline::Lua?

2012-04-16T14:00:00Z

I was reading about the Inline module the other day, so naturally I looked to see if there was a binding for one of my other favorite languages, Lua. Sure enough, Inline::Lua exists; however, it has not seen a new release in nearly five years, and it doesn't even build on perls newer than 5.10. I like this idea enough that I'd like to put some time into it and cut a new release; however, I haven't been able to reach the author. So, in accordance with the guidelines I read in the CPAN FAQ, I'm making a post asking if the original author, Tassilo von Parseval, is still in the Perl community and interested in updating this module.

-Rob

Perl Podcasts

2012-02-13T15:13:59Z

I had to make a last-minute drive to Chicago last Friday, which is about a two-and-a-half hour trip from Madison. So naturally, to pass the time, I loaded up my phone with podcasts. When I was about halfway home, it hit me: I didn't have any Perl podcasts on my phone! Unfortunately, I don't know of Perl podcasts; I've seen Perlcast, but it looks like it hasn't been updated in a year and a half. So, this is a call to the Perl community: are there any Perl podcasts out there?

Asynchronous MySQL Queries in Perl Using DBD::mysql and AnyEvent

2011-10-19T16:40:46Z

A lot of people use MySQL, and these days, asynchronous-style programming has really taken off. If you're involved in both of these camps, you may be wondering
how to send a query to MySQL and have it inform your event loop when it's ready with the results of that query. A common solution is to use a thread or child process
for each connection, and exchange data using IPC. However, if you're using Perl and DBD-mysql 4.019 or better, you have an alternative: the new asynchronous interface.

Using the new async flag that you can provide to the prepare method, along with the new mysql_fd method, it's fairly easy to have MySQL play nice with AnyEvent.
Here's a simple example:

#!/usr/bin/env perl

use strict;

use warnings;

use feature 'say';

use AnyEvent;

use DBI;

my $dbh = DBI->connect('dbi:mysql:', undef, undef, {

    PrintError => 0,

    RaiseError => 1,

});

my $cond = AnyEvent->condvar;

my $sth = $dbh->prepare('SELECT SLEEP(10), 3', { async => 1 });

$sth->execute;

my $timer = AnyEvent->timer(

    interval => 1,

    cb       => sub {

        say 'timer fired!';

    },

);

my $mysql_watcher = AnyEvent->io(

    fh   => $dbh->mysql_fd,

    poll => 'r',

    cb   => sub {

        say 'got data from MySQL';

        say join(' ', $sth->fetchrow_array);

        $cond->send;

    },

);

$cond->recv;

undef $sth;

$dbh->disconnect;

This script will print "timer fired!" about once a seconds for ten seconds, then "got data from MySQL", and finally "0 3", which is the data from our SELECT statement. Obviously, this example is pretty trivial, but you could easily do this with multiple MySQL connections.

(cross-posted from my blog)

Edit-Plackup-Test-Rinse-Repeat

2011-10-17T13:49:54Z

At INOC, my place of work, I work on a lot of web applications with the backend written in Perl using Catalyst, and the frontend written in Javascript using ExtJS. With a UI written completely in Javascript, I often encounter bugs of the following form:

Fire up Catalyst.
Login.
Click through half a dozen controls in the UI.
Enter some data.
Click “submit”.
Watch the web application give you an angry error.

As you can imagine, the time for a single iteration of this cycle is fairly long, and the process is quite tedious. Obviously, if the error lies within the Javascript side, there's not much I can do about it, short of writing a Greasemonkey script to do some of the automation for me. However, half of the time, the server is returning some strange output given a certain set of inputs for a particular RPC call. Wouldn't it be nice if you could go through the application and have it record the requests you make to be submitted over and over again at a later time?

That's why I wrote Plack-Middleware-Recorder.

Plack-Middleware-Recorder is a distribution that comes with several modules:

Plack::Middleware::Recorder: A PSGI middleware that knows how to serialize requests to a stream.
Plack::Middleware::Debug::Recorder: A debugging panel that allows you to manipulate the recorder middleware from a browser.
Plack::VCR: A utility module that allows you to read a recorded request stream.

These modules allow you to build PSGI applications and scripts that record and replay requests to a web application. However, Plack-Middleware-Recorder also contains two scripts, plack-record and plack-replay, that do exactly what they sound like. So my workflow for handling a server-side bug goes from this:

Steps 1 - 6 above
Add some debugging log output
Repeat, and observe the new output

to this:

plack-record > requests.out
Steps 1 - 6
Add some debugging log output
plack-replay requests.out app.psgi
GOTO 3

Plack-Middleware-Recorder is still very young; I plan on adding better session support, dumping request streams to test files, and other features in the future. In the week since I've written it, I've already gotten a lot of mileage out of it; I hope other people find it just as useful!

-Rob

(cross-posted from my blog)