Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

potyl (8582)

potyl
  (email not shown publicly)
Jabber: emmanuel.rodriguez@gmail.com

Journal of potyl (8582)

Saturday October 24, 2009
02:54 AM

Pexeso game now on CPAN - Game::Pexeso

I've finally packaged the Pexeso game as a CPAN application: Game::Pexeso. Now there are no excuses for not playing it!

The source code is available on github: pexeso git repo.

Remember that if you want your face to be in the game that you have to create a CPAN account!

Sunday October 18, 2009
03:44 AM

Declarations and Scope followup on Chromatic's post

Chromatic as a good post on Declarations and Scope. I'm glad to see that I'm not the only one that follows this best practice. Which by the way I was surprised to not see in Damian Conway's Perl Best Practices.

What I find the most strange is that I get constantly asked why I'm wrapping all my scripts into functions and that I don't have just plain executable code from the beginning. One of my posts in StackOverflow raised a lot of critics just by following this simple best practice: Scope bashing.

I think that all conscious perl programmers always employ use strict; and use warnigns. So I find that localizing all our code in scoped blocks (let it be a do {};, a function or even a simple code block {}) is just too practical to be overlooked. I don't think that doing this adds too much noise nor distractions to the original source code. Yet the benefits gain are huge!

Not only does this technique protects your variables from becoming global but it also helps when the code needs to be refactored. There's nothing more annoying that having a monolithic script without functions that can't be refactored easily because the code assumes each single variable to be a global!

Monday October 05, 2009
01:50 AM

Enable/Disable touch pad

I use a MacBook as my main computer. I work on that laptop and do all my random hacking on it as well.

What might seem odd is that I run Linux on that hardware. Installing Linux there and getting it to work properly requires a lot of work and sacrifice: the web cam doesn't work and the OS sees a single CPU. Otherwise all is working fine and if the proper software (fan control) is installed the laptop won't overheat. I can even play an OpenGL game in Perl!

One thing that I have noticed since I work on this MacBook is how clumsy I can be while typing. I would always hit the huge track pad and destroy my own work! OS X has a feature to disable the touch pad when a mouse is plugged and I would like to have the same feature in Linux. I think that the next version of Gnome will have this feature, but I want something like that now.

Luckily in Linux we have all the tools to implement this. What's missing is something to put all the pieces together, something like a glue language. So I wrote a small Perl script that can toggle the touch pad for me: toggle-touchpad. I binded the script to a keyboard combination through my window's manager keybindings and I can now enable/disable the touch pad at will!

This script will only work if the synaptic touch pad is configured to use shared memory. This means that the following option has to be set in the synaptic's driver section of your X11 configuration file:

Section "InputDevice"
        Identifier      "Synaptics Touchpad"
        Driver          "synaptics"
        Option          "SendCoreEvents"        "true"
        Option          "Device"                "/dev/psaux"
        Option          "Protocol"              "auto-dev"
        Option          "HorizScrollDelta"      "0"

        # Use shared memory
        SHMConfig       "On"
EndSection

Once the driver is configured to use shared memory the touch pad settings can be modified at runtime without needing to restart the X server. The program synclient can be used for playing around with the touch pad's settings. Once that done disabling the touch pad is as simple as doing:

synclient touchpadoff=1

Voila!

Monday September 28, 2009
01:46 PM

Log::Log4perl now supports %R

Log::Log4perl 1.25 has been released and it has two interesting enhancements:

  • Color configuration and attribute support added to ScreenColoredLevels
  • Patternlayout now supports %R, which returns the time elapsed from the last logging event

The first enhancement looks really nice but I didn't had the opportunity to try it yet. I really like to use the color appender yet I always found the default color choice a bit odd. I used to work around this by creating a custom profile for my terminal with colors that matched the Log4perl log levels and fixed them to my liking. It's a bit hackish but on the other hand not everyone has the same color tastes.

I can comment a bit more on the second addition to Log4perl: the format %R in Patternlayout. This format is very similar to %r which prints the time elapsed since the start of the program except that %R prints the time elapsed since the last event successful logged event. This is exactly the same functionality as Log::Log4perl::Layout::PatternLayout::Elapsed but now available out of the box with Log::Log4per!

I got used to employ %r in my console appender while developing scripts. This was nice as I could see the execution time of the program and find the program's hot spots as I developed. I have to agree that this doesn't replace a good profiler but you will be surprised of the results.

The problem with %r is that finding the time elapsed between two consecutive log events requires compute the time difference between each consecutive log event. This can be easily done with another Perl script that will parse the output and show the time elapsed between each log event.

While parsing the output of a program with another program works, specially in Linux/Unix where pipes are so easy to do, it still wasn't the right thing to do. That's why I wrote Log::Log4perl::Layout::PatternLayout::Elapsed a long time ago. This allowed me to use that same functionality but from all programs using Log4perl without requiring to pipe the output through another program.

I'm glad to see that the modification is now in Log4perl and that I will be able to use without this feature right straight from Log4perl!

Saturday September 26, 2009
04:09 PM

Finding uncovered XS functions in Perl bindings

As I've said in my previous posts. I have two CPAN modules that provide bindings for C libraries.

One thing that I have I realized while I was writing these bindings is that sometimes C functions pass under my eyes unnoticed and that I forget to provide bindings for them. This can happen for various reasons:

  • The C library failed/forgot to document some functions.
  • New functions are added without being announced during the development.

I asked a few months a go on the gtk-perl-list on how to proceed in order to find the functions that are missing code coverage in the the XS module. I took the suggestions posted in the mailing list and made this script: xs-coverage

I've used this script with a couple of bindings and I was quite satisfied. On my bindings it did find C functions that where missing in the XS files. But this script did even more: it showed me C functions that shouldn't have been public in the first place and undocumented functions in the library! This script is really helping me to improve the code coverage of the bindings that I maintain.

Even though xs-coverage is written in Perl i doubt that it is portable as the program relies on the command nm for inspecting the .so files.Furthermore, so far my script this has been only tested in Linux and could probably only work there. I'm not even sure that the program will work with standard C libraries as I only tested it with Glib based libraries. Another drawback is that the program will not detect XS aliases. Although, Vincent Pit suggested that I might be able to get around that bug by inspecting the functions from the XS module by loading it in the Perl script and walking the package's symbol table.

If you have some suggestions or feed back on the script please let me know or fork it and send patches.

Thursday September 24, 2009
01:27 PM

Writing Perl bindings for GObject based libraries

I have in CPAN two modules that provide Perl bindings over two existing C libraries: Gtk2::Unique and Champlain. These two modules both wrap C libraries that use Glib's GObject framework. I don't want to go too much in the details of explaining how GObject works, so I will just keep it brief. What's important to know is that the library provides and object-oriented framework for C that's easy to map to other languages through bindings (Perl, Python, Java, C++, etc). It provides classes, interfaces, a generic type system, memory management for objects, signals and even inheritance. You might not know too much about GObjects but you might be using them indirectly as it is the basis for Gtk2 and the Gnome desktop.

GObject and Glib have already Perl bindings: Glib. The Perl module on it self doesn't look so impressive as other Perl modules in CPAN offer the same functionality, nevertheless the module is capital. What makes it so unique is that it provides all the basis for the GObject framework. All the hard work of providing a mapping between GObjects's data structures, runtime, memory management and type system to Perl is covered by Glib!

Thanks to Glib's bindings, writing Perl bindings for a GObject based library is very easy. Most of the time all that's involved is to provide a map file that describes the C data structures (Objects, Interfaces, ect), to map their C names with Perl package names, to provide the prototypes of the C functions to bind in the XS files and to write the unit tests of course. That's it! Perl's Glib module will take care of the rest as it provides the utilities for compiling and linking the C code for us. It really is that simple.

The GObject framework is still evolving and gets new features. One that's very promising is introspection. This means that in a near future writing Perl bindings for a GObject based library will be almost if not automatic. And this future might not be so far as some work has been already made in order to give us even easier wrappers: Introspection for GTK2-Perl.

Saturday September 19, 2009
04:34 PM

Champlain is now using Clutter 1.0

I finally had the chance to resume my work on the Perl bindings for libchamplain which had a major release 0.4. The major change in this new version is the port to Clutter 1.0.

Clutter, for the ones that don't know what it is, is an open source toolkit for creating fast, visually rich, portable and animated graphical user interfaces (GUI); more information here: clutter's home page. The library is fast and portable because it uses OpenGL and allows the creation of powerful GUIs very easily.

The toolkit is used as the basis of the moblin platform, the next major version of Gnome (3.0) will require clutter and even phones start to have clutter installed (Nokia N900). There's no doubt that Clutter is here to stay.

Lately SDL has been having a lot of attention since it got revived. This is a good thing as having more toolkits is always welcomed. But I have a feeling that this new enthusiasm has eclipsed Clutter's 1.0 release at least in the Perl blogosphere. This is a pity as Clutter is starting to make its mark in the open source world and has plenty of extra neat addons:

  • Gstreamer (Multimedia toolkit)
  • Gtk (for embeding in existing GUIs)
  • Champlain (geographical maps)

I decided to try to show case Clutter and I implemented the pexeso game. This version is a Perl variant of the familiar game written in Perl and for the Perl community. The game is available for download here: pexeso in clutter. I hope that you will appreciate it!

Monday September 07, 2009
02:02 AM

Summer of 09

The summer is almost over and I didn't realized it! This year was full of adventures and surprises.

It all started when I accepted a job at booking.com and joined the team in June. New company, new town and new country! All while my wife stayed in Bratislava, pregnant with our first baby!

Then there where the many flights to Bratislava during the weekends. Luckily Sky Europe had a cheap Amsterdam/Vienna connection. I've said had because the company is no more as it died one week ago. Everyone saw this coming: flights started to be delayed, then flights where operated by other companies, afterward flights where redirected to Bratislava (that was actually nice for me) and then flights got canceled.

I didn't mind too much having my flights delayed of a couple of hours. Now that I have git, being disconnected is no longer a problem. This gives me a good way of passing my time: Open Source. Thanks to git I was still able to hack and to commit code from the airport while I was monitoring the next delay (yes flight schedules where that bad that delays where delayed). Once I arrived home all that I needed was to push my changes and voila!.

Not only did I get to fly to Bratislava I also managed to go to YAPC::EU 09. That's something that I wasn't expecting as I just joined Booking.com! Once more the flights where delayed and a lot, luckily I wasn't alone this time as daxim and pepl where in the same flight. This YAPC was great and I had the chance to see some old friends that you only get to meet from YAPC to YAPC.

Finally, I'm made it back to Bratislava last week. Just in time for assisting to the birth of our first baby! Laurita was born last Thursday and I'm now going to visit her and her mother to the hospital as often as possible. While the family is being monitored and recovering at the hospital daddy is working from home and still hacking during the weekend. I know that very soon my random hacking during the weekends and evenings will be postponed for a while, but it's going to be worth it! I'm looking forward to have my whole family back under one single roof.

Wednesday July 01, 2009
03:38 PM

Perl movie player

A few months ago I was playing with Gstreamer and I wrote a small movie player in Perl 5 thanks to the Gstreamer bindings.

For those that aren't familiar with Gstreamer it consists of an open source multimedia framework. Gstreamer allows an application to play, stream and covert any kind of multi-media content. It is mainly used in the Gnome desktop for playing sounds and viewing movies.

If you are a bit curious play with the following movie player:

#!/usr/bin/perl

=head1 NAME

gst-video-player.pl - Video player made in Perl

=head1 SYNOPSIS

gst-video-player.pl video

Where I<video> is the URI to a video (file, http, etc).

=head1 DESCRIPTION

This program shows how to create a video player using Gtk2 and Gstreamer. This
player can handle all video formats supported by Gstreamer.

=cut

use strict;
use warnings;

use Glib qw(TRUE FALSE filename_to_uri);
use GStreamer '-init';
use GStreamer::Interfaces;
use Gtk2 '-init';
use File::Spec;
use Cwd;

exit main();

sub main {
    die "Usage: file\n" unless @ARGV;
    my ($uri) = @ARGV;

    if ($uri =~ m,^[^:]+://,) {
        # Nothing to do as the input is already an URI
    }
    elsif (! File::Spec->file_name_is_absolute($uri)) {
        my $file = File::Spec->catfile(getcwd(), $uri);
        $uri = filename_to_uri($file, undef);
    }
    else {
        $uri = filename_to_uri($uri, undef);
    }
    print "Playing: $uri\n";

    # Create the main pipeline and GUI elements
    my ($pipeline, $player, $sink) = create_pipeline();
    my ($window, $canvas, $buttons) = create_widgets();

    $player->set(uri => $uri);

    # Buttons used to control the playback
    add_button($buttons, 'gtk-media-play', sub {
        $sink->set_xwindow_id($canvas->window->get_xid);
        $pipeline->set_state('playing');
    });

    add_button($buttons, 'gtk-media-stop', sub {
        $pipeline->set_state('ready');
    });

    # Run the program
    Gtk2->main();

    # Cleanup
    $pipeline->set_state('null');
    return 0;
}

sub create_pipeline {
    my $pipeline = GStreamer::Pipeline->new('pipeline');

    # The pipeline elements
    my ($player, $sink) = GStreamer::ElementFactory->make(
        playbin     => 'player',
        xvimagesink => 'sink',
    );

    $pipeline->add($player);
    $player->link($sink);

    $player->set('video-sink', $sink);
    $sink->set('force-aspect-ratio', TRUE);

    return ($pipeline, $player, $sink);
}

sub create_widgets {
    # Create the widgets
    my $window = Gtk2::Window->new();
    $window->set_title("Gst video test");

    # This is where the video will be displayed
    my $canvas = Gtk2::DrawingArea->new();
    $canvas->set_size_request(300, 150);

    my $vbox = Gtk2::VBox->new(FALSE, 0);
    $vbox->pack_start($canvas, TRUE, TRUE, 0);

    # Prepare a box that will hold the playback controls
    my $buttons = Gtk2::HButtonBox->new();
    $vbox->pack_start($buttons, FALSE, TRUE, 0);

    $window->add($vbox);

    $window->signal_connect(destroy => sub {Gtk2->main_quit()});
    $window->show_all();

    return ($window, $canvas, $buttons);
}

sub add_button {
    my ($box, $stock, $callback) = @_;
    my $button = Gtk2::Button->new_from_stock($stock);
    $button->signal_connect(clicked => $callback);
    $box->add($button);
    $button->show_all();
}

Sunday June 28, 2009
04:29 AM

Asynchronous HTTP with Gtk

I wrote a small demo for Champlain that shows how to query Flickr and to display thumbnails of geotagged pictures that are publicly available. I already had a demo script that downloads an image from an URL. So writing this new demo wasn't too difficult, yet buliding the basis for it (the HTTP download part) was tedious.

The basis of the HTTP protocol are quite simple. So simple in fact that a simple GET command can be easily issued by hand through telnet. But today we no longer communicate with HTTP 0.9 and the protocol has been greatly enhanced with proxy support, SSL, keep-alive, pipelining, web services (XML-RPC and SOAP) and so on. Writing an HTTP client from scratch is pure madness, specially when LWP does everything so easily.

So what's the problem if we already have a great HTTP client library in CPAN? The problem is that in a GUI all I/O has to be made asynchronously. For a GUI this is crucial, if I/O is NOT performed asynchronously then the GUI will simply freeze while it's waiting for the I/O to resume and stops responding to user input. As far as I know there's no easy way for performing asynchronous HTTP (or HTTPS) requests that integrate well with Glib's main loop, at least in Perl 5.

Libchamplain performs its HTTP requests through libsoup which is fully integrated with Glib's main loop. Sadly, libsoup doesn't have bindings for Perl 5 yet.

I though of using POE for this but it requires a whole rewrite of the application. With POE, the logic has to be written using the POE framework and the GUI is added latter as a different component. This makes the application no longer look like a Gtk2 application but more like a POE component that happens to have a GUI.

At the end I implemented a minimalist version of Libsoup in Perl 5 thanks to Net::HTTP::NB. My implementation is far from ideal but it works well enough for the purpose of the demo.

Remember when I said that writing an HTTP client fro scratch was pure madness, well I speak from experience and keep in mind that most of my work is still using Net::HTTP::NB for everything that involves the protocol. First of all my asynchronous client is not even fully asynchronous! In my version, the HTTP request is written with blocking I/O and only the response is read asynchronously. I tried to implement some basic version of keep-alive, it works but it is probably not that optimal. My library doesn't even have proxy support and it doesn't even keep track of the different TCP connections that the clients do.

I'm really thinking of writing the bindings my self. Although libsoup's API is quite extensive as it provides an HTTP client/server library for GNOME and this makes the task more time consuming. If anyone else would be interested in having libsoup's binding let me know. If I see that there's a demand beside my own personal need for a demo I will start the project sooner than expected.