/home/rafl

$ history 1|awk '{print $2}'|awk 'BEGIN {FS="|"} {print $1}' \
  |sort|uniq -c | sort -r |head -10

On my laptop:

1557 vi
 710 perl
 692 man
 661 cd
 648 ac
 513 sudo
 510 grep
 499 rm
 388 ls
 180 wajig

On weedy.perldition.org, my server:

1967 sudo
1052 vi
 810 cd
 766 l
 352 screen
 316 perl
 250 ..
 213 wajig
 212 find
 194 rm

.. expands to cd ..

l is shorthand for ls

and ac is my alias for apt-cache.

I recently wrote two two new Perl modules. The first is called Linux::Sysfs and is a library binding for libsysfs. It offers a convenient interface to sysfs (/sys). After releasing the first version of it for peer review and, later on, to CPAN, I received a lot of reports about test failures because of a missing or outdated libsysfs.

Therefor I wished to have something like GNU autoconf for Perl modules. It would be possible to write something similar in pure Perl (someone actually tried it: Config::Autoconf), but compiling C programs from Perl in a portable way isn't much fun.

Therefor I decided to write some Perl glue around autoconf and autoheader so those tools are easy to use from Makefile.PLs and such. I did so and the result is ExtUtils::Autoconf. It'll be on CPAN within the next few hours. Until then the current version is available from here.

It currently has some documentation about using it from an ExtUtils::MakeMaker-based Makefile.PL. Instructions about how to use it with Module::Build and Module::Install are still missing.

The Module::Install part will be done by an extension called Module::Install::Autoconf, which I'm currently about to write. For the Module::Build part I don't really have an Idea on how to do that, so any help from some Module::Build people would be very appreciated.

David, you wrote about Class::DBI performance.

Even without benchmarking you could have found out, that Class::DBI is quite slow. Fortunately there are some alternative object-relational mappers available in the perl universe. The best ones I found so far are Rose::DB::Object and DBIx::Class. I took a closer look at both and would like to share my experience.

As this shows, RDBO is faster than DBIC in most of the case. The generated SQL doesn't differ too much and therefor it must be the perl side of things that makes the difference.

Matt S Trout <dbix-class@trout.me.uk> says:

However, RDBO achieves its perl speed by aggressive inlining of
stuff etc. - for example the main object retrieval function in
RDBO's manager class is >3000 lines in a single sub. DBIC values
extensibility over a few extra sub calls, so methods are much more
broken out and there are many more ways to hook into the DBIC
execution process to extend.

Also its idea of resultsets is something I really love. Here's a small example to illustrate that:

my $user_rs = $schema->resultset('User')->search({ registered => 1 });
$user_rs    = $user_rs->search(
  { comment.title => 'Foo' },
  {
  	join     => { 'article' => 'comment' },
	order_by => 'user.name',
  },
);

# no sql executed yet.
# now you can use your resultset as an iterator or query a list
# of User objects from it or ..

while (my $user = $user_rs->next) {
 ...
}

# or

my $count = $user_rs->count;

Using these resultset makes it extremely easy to built up queries piece by piece and to work together well with, for example, a templating system. You don't need to fetch all row-objects and give them to your template. You can just pass the iterator to the template library.

There's a lot more to say about this two object-relational mappers (for example RDBO supports prefetching of multiple one-to-many at once, which DBIC doesn't), but maybe you just should take a look yourself. I personally prefer DBIx::Class for its vast extensibility.

Yesterday I did some work for the XMMS2 Debian packages. Thereby I noticed that libxmmsclient0, the xmms2 client library, that allows you to write your own xmms2 clients, is bound to quite a lot of languages, but perl bindings were still missing.

I took a look at the library interface and it seemed that creating bindings shouldn't be a big deal. Therefor I gave a try and wrote Audio::XMMSClient.

There are still some rough edges, but it works pretty well already. The interface is quite close to the C API, so it's possible to work with it even if documentation, examples and a test suite are still missing.

Comments on the API, the namespace and whether this module should go into the xmms2 distribution, like other language bindings, or directly to CPAN are most welcome.

Aircrack, one my favourite wifi tools, was quite dead for a while. Bad enough, but after I switched to the madwifi-ng driver recently I discovered that I can't do injection anymore, which is quite bad. I searched for a workaround and found aircrack-ng, a fork of aircrack, which has been made recently. There weren't much changes to the aircrack codebase yet, but at least everything works well with madwifi-ng now.

Now, as aircrack seems to be moving again I mplemented some changes I always wanted to have, such as attack names (documentation patch) instead of attack numbers I could never remember and tried to get them submitted to upstream.

What I normally do that situation is to check out the latest development version from the projects version control system, prepare a patch against it and send it to the development mailing-list afterwards. That's hardly possible with aircrack-ng. Not only that one or two persons are having a master copy of the code instead of using a nice, public accessibly version control system, but also the total lack of mailing-lists or any other possibility to coordinate development besides an IRC channel and a wiki, which is only partially editable, makes contributing quite hard. After announcing some of my patches on IRC several times one of the upstream developers finally took a look at it and said he applied it so it'll be released in the near future.

I'm happy about that, but the deficits in the development process still exist. Therefor I offered to sponsor hosting, including mailing-lists, a version control system, a bug-tracking system and whatnot. It was thankfully declined as they already seem to have a hosting plan. Great! Unfortunately they don't have the money for that currently, but they at least have plan. Hooray for aircrack-ng..

Debian packages for the latest release already exist and should be upload in the next days, btw.