/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.