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)

Monday June 15, 2009
05:12 PM

Champlain/libchamplain marathon is over

The libchamplain dev team was really busy this weekend trying to fix some last minute bugs and to complete all bindings (Python, Perl and C#). Today the new version of libchamplain (0.3.3) was released and the race against the clock is now over.

I've realized that I forgot a few minor changes and fully completed the bindings only today, after the official release. This is not too much of a problem as the Perl bindings are mainly published through CPAN. For most users the version bundled with libchamplain should be good enough to use. For the purist that want 100% of API coverage they will have to wait until their favorite CPAN mirror has received the new version of Champlain (0.4).

Monday May 18, 2009
03:31 PM

Glib closures

Libchamplain had a major release a few weeks ago and it introduced a MapSourceFactory which allows map sources to be registered, instantiated and easily swapped. This is a great addition as all map sources are now created in the same way. Displaying a combo box with all maps available is truly simple now.

The factory also allows user code to provide their own map source and to register it with libchamplain. Which means that once the factory will be properly binded in Perl it would be possible to implement a MapSource in pure Perl!

I was anxious to get this new feature but it came at a price: the bindings have to support the passing of a Perl sub (CODEREF) and to execute it when a map source is implemented in Perl. While, Glib and Gtk2 are overloaded with CODEREFS (after all the signal systems is implemented through callbacks), I had no idea how to implement this. To make things worse the callback for creating a new MapSource had no arguments which made the task impossible.

I finally had the time to refactor libchamplain and to modify the C callback signature in order to accept an extra parameter. Exactly as all Glib and Gtk2 callbacks do. This made it possible for me to reuse Glib's mechanism for binding callbacks. Thus, now it possible to create a MapSource in Perl!

This was the last bit that was missing in the Perl bindings. Now Champlain.pm has a total coverage of all functions and variables defined in libchamplain. The code needs still to be cleaned up a little bit and some pieces need to be refactored. But at least and at last I have a working version.

Wednesday May 06, 2009
12:20 AM

Plenty of new releases Gtk2:: goodies

This last month has been a busy period and I managed somehow to work on 3 Gtk2 based CPAN bundles: Champlain, Gtk2::Ex::Entry::Pango and a new module Gtk2::Unique.

In the past weeks someone was looking for the Perl bindings to libunique (a library for writing single instance applications). The bindings didn't exist so I decided to write them as they can be quite useful and might end-up being used one day in Xacobeo.

This project took a little longer than I expected even though the C API is quite small (3 header files). I got delayed considerably because I'm still learning how to write proper GObject bindings. The important thing is that the module has been released and is now in CPAN Gtk2::Unique

In the meanwhile I also managed to release a new version of Gtk2::Ex::Entry::Pango which is backward compatible with all versions of Gtk2 that support Pango and most important behaves correctly when the text entry gains focus. Now when default Pango markup is used to display text when the widget is empty it will clear the default text when the focus is gained and restore it when focus is lost (if there's no text). This is similar to what Firefox's search bar is doing and apparently Windows Vista (I don't have it so I can't tell).

Lastly but not the least, libchamplain had a major release (0.3). The number of improvements and additions is too long to be enumerated in this post. One thing is assured the library is getting better and better. This new version has a lot of API changes, this is for the best so bare with us. The bad thing is that the API changes where so numerous that the bindings are lagging behind. Don't worry it's just a question of time and the bindings will be ready soon.

Sunday April 12, 2009
12:52 AM

Xacobeo has a new contributor and supports HTML files

Daxim requested to join Xacobeo and submitted some nice patches that greatly improve the build system.

Now that we are more than two with commit access to SVN I really wished that Google Code would provide support for Git. I know that other services such as github and gitorious exisit but none of them provides the extra goodies that Google Code has (a built-in bug tracker, a download section, wikified site, etc).

This release adds the ability to open HTML files with Xacobeo. Don't expect the HTML page to be rendered in Xacobeo; although this could be done with Gtk2::WebKit or Gtk2::MozEmbed it's just that I don't see where in the window I could add this extra widget. What this feature does is to display the proper HTML DOM. For the moment the HTML parser has to be requested through the command line and only applies to the first document.

Monday March 23, 2009
01:37 AM

New release of Champlain

Yesterday I've released a new version of Champlain. This release addresses two issues: better support for Gt2 and unit tests.

In the previous release I wasn't able to provide proper support for Gtk2. I'm quite new at packaging a Perl module for a glib (or gnome) library and I made a big mistake. Ebassi came to my help and managed to fix my mess. Now the Gtk2 wrapper works as expected and without hacks.

This time the package has unit tests and covers most of the public API (some parts that will be disappearing soon where omitted). It took me longer than what I would expect for writing the tests because of many small bugs. Thus, the majority of the time was spent writing test cases isolating the bugs, fixing libchamplain and logging bug reports. At the end this pays as libchamplain is becoming more robust and other bindings will also benefit of the bug fixes.

Not only did this project gave me the opportunity of learning on how to create a package from scratch for an glib library it also introduced me to git. I've still haven't managed to master this new tool. I truly see advantage of having a distributed version control system, but the learning curve is quite high. Furthermore, the error messages are not too helpful. Although, I got told that in the past they where worst!

Monday March 16, 2009
01:31 AM

Perl bindings for libchamplain

In the past days I was writing the bindings for libchamplain and the first release is now available on CPAN Champlain.

So what's Champlain? It's a Clutter based canvas that supports numerous free map sources such as OpenStreetMap, OpenArialMap and Maps for free. The canvas can also be embedded in any Gtk2 application.

This is a first release so some bugs might be lurking around, although in all honesty there's barely any code in this bindings. At the moment the module is not well documented nor tested. I plan to address this in the following releases. I'm also waiting for libchamplain to freeze a bit more it's API.

Sunday February 15, 2009
03:00 PM

Release weekend

Jozef brought me the big news today: Debian GNU/Linux 5.0 released (Lenny). Congratulations to the Debian team. I'm looking forward for the next release. Don't forget to improve the speed of apt-file ;)

Inspired by the majestic release of Debian, I was compelled to make a release of Xacobeo. This new release addresses a nasty bug: the application crashes when opening non XML files. It never occurred to me to open something else than an XML file (except for HTML). But an user did try it and reported the results (Segmentation Fault), it is now fixed.

This new release makes Xacobeo reentrant, that's right you can now read Xacobeo's source code with Xacobeo. Actually, this is misleading as nothing will be displayed as Xacobeo's source code is not a valid document. But at least Xacobeo will no longer crash.

Speaking about opening non XML files. This week at work a colleague wanted to edit an existing HTML file and to save the results so he came to ask me about XPath, which he doesn't know. I showed him how XPath worked and he was quite impressed by the technology. Of course I tried to display the HTML document with Xacobeo but the document wasn't valid and a big chunk was missing. I replaced a single parse_file() by parse_html_file() and Xacobeo could handle HTML! I have to give XML::LibXML and libxml2 all credit for this. Of course, Xacobeo doesn't support yet HTML but in a near future I'm planning to implement this.

Saturday February 07, 2009
11:16 AM

Xacobeo traducido dans votre jazik

I have a uploaded a developer's release of Xacobeo (version 0.06_02) to CPAN. From now on the application is using i18n which means that it can be translated quite easily to different languages. I have included two translations to Spanish and French. I'm guessing that these translations will probably need to be revised as I don't know the exact XML terminology any other language then English

I was surprised by the number of Perl modules available in CPAN that provide i18n. Specially the ones that interface with GNU gettext. At the end it can get quite confusing when comes the moment of making a choice.

Another pitfall that I've seen is that there doesn't seem to be a proper way (a Perl way) for generating the .mo files from the .po files. I had to revert to invoke msgfmt from Module::Build which isn't too portable.

Sunday January 04, 2009
04:36 AM

Productive holiday season for Xacobeo

This holiday season was some how particular as I had no choice but to take a two week vacation. It was a mandatory top management decision for all company employees. This was a great opportunity for me to continue the development of Xacobeo, all of course, founded at my own expenses ;)

So what's Xacobeo? It's a simple XPath visualizer (see CPAN Xacobeo). It started as a Perl script that allowed me to execute an arbitrary XPath query and to see the results in plain Gtk2 GUI. Of course the script was quite simple and had a lot of shortcomings, nevertheless it was quite useful for parsing XML or writing XSLT.

I once showed it to Jozef who introduced it to Pepl. They both convinced me to release the script to the public. At first I was reluctant because the script was far from being ready to be used widely. On the other hand I figured out that if two to users found it useful maybe it deserved a chance.

Since it's first public apparition in CPAN, Xacobeo had 4 major releases and a few development releases with each version adding new features or fixing some existing bugs. I have now merged the XS development branch and made it available through CPAN as a development release (version 0.05_XX). In my opinion this version makes the software more usable as the two slowest parts of the application are now written in XS and have been heavily profiled. This allows the Xacobeo to handle quite large documents in a reasonable time, thus making it ready for prime time. So if you want to give it a try, now is the right time!

In retrospective, releasing Xacobeo was a good thing as it has taught me a lot:

  • Configuring Perl's build scripts (Makefile.PL, Build.PL) for applications instead of modules
  • XS
  • The internals of Gtk2, XML::LibXML, gtk2 and libxml2
  • Pango markup (see Gtk2::Ex::Entry::Pango)
  • How helpful the perl-XML and perl-Gtk2 mailing list are
  • Contributing a patches and bug reports to Gtk2, XML::LibXML and libxml2

Of course the project is still young and more development will be needed. I hope that I will be able to publish new versions of the tool and to learn new things.

I wish you all a Happy New Year!

Tuesday October 07, 2008
04:39 PM

From YAML to XML through a DTD

The Bratislava PM web site has now an RSS feed. This feed is currently generated from a custom made YAML file that's transformed to RSS thanks to XML::RSS. This approach is simple and quite flexible but has some quirks.

First, it's almost impossible to verify that the format of the YAML file is following the default template without writing our own validation. For instance, if a feed entry is missing the title, the link or the date there's no built-in mechanism to inform us of this errors.

Secondly, the main content of each feed element is allowed to have HTML. In fact, all feed items that we have include HTML. Mixing HTML inside of a YAML file doesn't make the input file too nice since it has now two markup languages. Of course, one can argue that YAML Ain't Markup Language (tm), nevertheless it is weird to embed HTML in YAML.

Finally, converting YAML to XML seems strange. YAML is mainly used to provide data structures, configuration files or data serialization. Using it for content manipulation might be pushing it too far.

For this particular context XML seems more appropriated. Some of its advantages are that it's possible to validate through a DTD, an XML Schema or RELAX NG. HTML and XML can coexist without problems, specially if XHTML is used. And transforming an XML file into another an RSS feed can be easily done through XSLT.

Using XML as the input file provided some interesting advantages. First, thanks to a DTD not only can we validate each feed entry in the input file, but we can also validate the HTML that's embedded in the feed's description.

By using some clever XML and DTD hacks it's possible to create a custom made feed that can be validated without too much effort. Let's we assume that an RSS feed contains an events and that each event has:

  • title
  • link
  • description (can contain HTML)
  • subject
  • creator
  • date
  • id

The following DTD describes and validates a feed input file:

<!ELEMENT ba:events      (ba:event*)>
<!ATTLIST ba:events
    xmlns:ba  CDATA   #FIXED "http://bratislava.pm.org/dtd/events-1.0.dtd"
>

<!ELEMENT ba:event       (ba:title, ba:link, ba:description, ba:subject, ba:creator, ba:date, ba:id)>

<!ELEMENT ba:title       (#PCDATA)>
<!ELEMENT ba:link        (#PCDATA)>
<!ELEMENT ba:description (#PCDATA)>
<!ELEMENT ba:subject     (#PCDATA)>
<!ELEMENT ba:creator     (#PCDATA)>
<!ELEMENT ba:date        (#PCDATA)>
<!ELEMENT ba:id          (#PCDATA)>

Although this DTD can be used for simple feed elements it has a problem: it doesn't allow any HTML inside the element ba:description! Does defeating the purpose of replacing YAML by XML. But all is not lost as this can be easily fixed by importing the XHTML DTD within our DTD and by redefining the element ba:description in order to accept any HTML tag that a div accepts:

<!-- Import that XHTML DTD -->
<!ENTITY % xhtml PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
%xhtml;

<!ELEMENT ba:events      (ba:event*)>
<!ATTLIST ba:events
    xmlns:ba  CDATA   #FIXED "http://bratislava.pm.org/dtd/events-1.0.dtd"
>

<!ELEMENT ba:event       (ba:title, ba:link, ba:description, ba:subject, ba:creator, ba:date, ba:id)>

<!ELEMENT ba:title       (#PCDATA)>
<!ELEMENT ba:link        (#PCDATA)>
<!ELEMENT ba:subject     (#PCDATA)>
<!ELEMENT ba:creator     (#PCDATA)>
<!ELEMENT ba:date        (#PCDATA)>
<!ELEMENT ba:id          (#PCDATA)>

<!-- The definiton of 'ba:description' is the same as a 'div' -->
<!ELEMENT ba:description %Flow;>
<!ATTLIST ba:description
    xmlns     CDATA   #FIXED  "http://www.w3.org/1999/xhtml"
>

Thanks to this new DTD the element ba:description can include any HTML element that's allowed within a div element. The DTD will make the validation and will ensure that valid HTML is inside the element. For instance, adding the element body to the element ba:description will be rejected by the DTD even though it's a valid HTML element it's not allowed to be within a div.

The element ba:description is declared in our DTD the same way that the element div is in the XHTML DTD. Furthermore, the element is allowed to set the default namespace to XHTML. Thus, making all child elements of ba:description to belong to the XHTML elements, this is very handy when processing the XML file latter on.

It's is not difficult to see that the new version of the feed will be generated from an XML file as using XML is quite advantageous here.