September 2009 Archives

Geany syntax for MooseX::Declare


Picking an editor is often not only a matter of "what suits me better" but also a religious thing. I tend to only look to the first aspect and - after using many different editors (Eclipse, Komodo, vim, emacs, ...) I decided to stick with Geany. It's a multiplatform GUI editor which is lightweight, handy to use, and offers the features I need. When I do not have a GUI available (fex. when working via SSH) I still use vim.

With MooseX::Declare (and CatalystX::Declare and Sub::Curried and many other modules) we now have new keywords in Perl, some of which were much awaited. It would be for Geany to show them highlighted with the proper colour. To achieve this, we can (easily) tweak the syntax highlighting system.

My explanation here applies to Unix system, but it's valid everywhere provided you use the correct system-specific paths.

If you just want the file and skip the explanation, click here to download the patched filetypes.perl (original from Geany 0.18 dist). :-)

Syntax definitions are kept in a system-wide directory (it's /usr/share/geany in my system) and are named in a filetypes.language fashion, fex. filetypes.haskell. If you edit these files directly, they will affect all users in the system: it is, however, a discouraged practice as upgrading to a new Geany version could mangle your changes depending on how your package manager works. The best option is to copy one of those files in your ~/.config/geany/filedefs directory; in our case:

cp /usr/share/geany/filetypes.perl ~/.config/geany/filedefs/

The file in your home directory will override the system-wide one. To add highlighting for the new keywords look for the:


section in the file and add whatever you want to the primary variable. I added:

class, method, extends, before, after, around, override, augment, role, with

At this point, you're done: just launch Geany again.

It looks like it's not possible to specify a regular expression for a keyword, like /is\s+mutable/. This would allow to give colour also to is mutable and is dirty. I'll ask the Geany community about that.

On Geany upgrades, be careful to check if there were changes in the original filetypes.perl and merge them.

You can also download the patched filetypes.perl (original from Geany 0.18 dist). For more information, read this section of the Geany user manual.

Pragmatic Version Control using Git
Travis Swicegood
Pragmatic Bookshelf, 2008
ISBN: 978-1-934356-15-9
US$ 34.95

Rating: 4/5 (very good)

Using a modern version control system likely means a choice between Git and Mercurial, which are way ahead of the previous generation (which includes the very popular Subversion). Git is becoming more and more widely used, with lots of open source projects switching to it. Even though quite easy to use for basic things, it takes some effort to learn to master all its features.

Pragmatic Version Control using Git provides most of the information needed, while also being a great starting point if you never used Git. It's written in a tutorial-like fashion, where each topic is covered by through explanations and focused examples (also available for download).

The first part covers Git configuration and very basic operations. The explanation is quite exhaustive, which is very important as it's fundamental to understand the philosophical differences between Git and other software: Subversion, for instance, works quite differently but many folks still try to use Git as if it was Subversion with another name: this is quite a pity, as Git offers much more power and flexibility. This difference is clear when you see that half of the book (90 pages) is only devoted to working with local files, which means that with Git you mostly (even only, in some cases) work locally (compared to Subversion where most of the work involves a remote repository).

The second part covers, besides some notions about how to work with remote repositories, the advanced topics (rewriting revision history, ...). One of the interesting parts is the one which explains how to migrate from, or even interoperate with, Subversion and CVS repositories: very useful if you're considering the switch to Git but you want it to be slow and without pain. Some useful notes on Gitosis (a Git repository manager) and other tools close the book.

A quick reference to everything Pragmatic Version Control using Git explains is available in appendix A, and a single-page cheat sheet you can detach from the book is also provided. These are really welcome, as finding a particular thing in a tutorial-like book like this can be quite boring.

This book is, all in all, a fine choice for learning Git. It might not be the best thing to use as a reference once you learned the topics, still it is acceptable even when used as such.

MojoMojo is a great wiki software based on Catalyst. Installation, however, can be quite a nightmare if you want to do it through the package manager of your operating system because of the many Perl libraries it depends on. Using the package manager is actually a good idea, unless you decide to install all dependencies locally through local::lib, as it doesn't pollute your system and makes upgrade operations much more linear.

Although almost no Linux distribution has packages for all all those libraries, Gentoo has a project which already provides ebuilds for them and for MojoMojo itself. They can be found in the Perl overlay:;a=summary

The overlay can be easily synced using the layman Gentoo tool (see this wiki page for more information). You can then just add the overlay with:

layman -a perl-experimental

and you're nearly ready to emerge dev-perl/MojoMojo. Yeah, nearly. You have to perform some (potentially) boring operations before, which include the unmasking of all the ebuilds in the overlay (300 or so): autounmask or a combination awk, perl and/or some other tool will help you adding them to /etc/package.keywords. Hopefully, portage will allow us to use wildcards for unmasking soon or after.

MojoMojo itself is currently hard masked because a dependency of it, dev-perl/Encode has conflicting files with perl 5.8.8. So, first of all you need to add MojoMojo and Encode to /etc/portage/package.unmask and then decide what to do regarding the conflict. You can either ignore it and install Encode with perl 5.8.8 or (best of all) unmask perl as well and upgrade it to 5.10.1 (it's in the same overlay). In my experience, perl 5.10.1 is very stable on Gentoo, and upgrading to it will also help testing it and speed its inclusion in mainstream Portage.

Once you sorted out the perl thing (don't forget to run perl-cleaner if you upgrade... ;-)), take a look at the MojoMojo USE flags and enable what you need. Here's an excerpt from the metadata.xml file:

<flag name="createdb">Create new Database automatically</flag>
<flag name="docbook">DocBook formatter</flag>
<flag name="tocgen">Table Of Contents Generator</flag>
<flag name="podformatter">POD formatterr</flag>
<flag name="syntaxhighlight">Syntax Highlightert</flag>
<flag name="transclusion">Transclusion support</flag>
<flag name="amazonboxes">Amazon boxes</flag>
<flag name="rssformatter">RSS Formatter</flag>
<flag name="emoticons">Emoticons</flag>
<flag name="recaptcha">reCAPTCHA for anonymous edits</flag>

There are two other entries in the file ( markdown and autodeploy ) which refer to older version of the software and are not to be used anymore.

When emerging, portage will surely ask you to unmask some more packages: it's boring, bot once done... it's done. When everything is unmasked, just relax while MojoMojo installs. ;-)

At this point you have everything you need, and you can just unwrap a MojoMojo package anywhere you like and customize it to create your wiki. At present time this is the only option, although ideally one should be able to use webapp-config to create a new blog in the future.

I recently installed perl 5.10.1 on a FreeBSD managed server I have in a datacenter. Being the server fully managed, I do not have root access, so I installed in my own directory. As usual, I typed in:

$ sh Configure  -de -Dprefix=/usr/home/mylocal
$ make
$ make test
$ make install

Almost everything went fine, and I also noticed that the 5.10.1 installation does not require to be able to read /home (or /usr/home, the parent of the user directory, anyhow) anymore (it did so in 5.8.8 and 5.10.0); I can therefore install on an "hardened" FreeBSD box without requiring the ISP to make that directory readable for me.

What still happens is that almost everything gets installed where prefix says to. The installer, however, still attempts to install scripts (fex. perldoc, cpan, ...) in /usr/local/scripts (failing for lack of write permission, of course). To fix this I edited, looked for the installscript variable and changed it to /usr/home/mylocal/bin.

Everything worked fine, but is this an expected behaviour? Shouldn't prefix influence all the installation paths?

About this Archive

This page is an archive of entries from September 2009 listed from newest to oldest.

August 2009 is the previous archive.

October 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.



OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.14-en