Andy Lester was the first to point out that the we will have Perl support on the next release of Android! I guess asking nicely, does help.

I am not saying they listen to me, but I asked as well.

Installing DBD::mysql on Solaris 10 seems to be less trivial than “cpan DBD::mysql” when you want to use the system-supplied perl (5.8.4) and mysql (4.0.31) installation. Google shows a lot of people asking how to proceed, but surprisingly no answers. Typically, one gets this error at make time:

[...]
"dbdimp.c", line 4468: improper member use: com
"dbdimp.c", line 4468: improper member use: com
"dbdimp.c", line 4468: improper member use: com
"dbdimp.c", line 4630: undefined struct/union member: pmysql
"dbdimp.c", line 4653: undefined struct/union member: pmysql
cc: acomp failed for dbdimp.c
make: *** [dbdimp.o] Error 1

To install the module do this:

1. Install the following Solaris mysql packages (if not already installed): SUNWmysqlr, SUNWmysqlu, SUNWmysqlS, SUNWmysqlt.
2. Type the following as root:
   cd /usr/sfw/share/src/mysql
./configure
3. Download the tar ball of the modules or, easier, go to your cpan build directory (set at cpan configure time), typically at ~/.cpan/build/DBD-mysql-<VERSION> (already there if you previously tried to install the module with cpan).
4. Run the makefile with the following arguments (adapt to your own needs if necessary):
   cd ~/.cpan/build/DBD-mysql-<VERSION>
perl Makefile.PL --libs '-R/usr/sfw/lib -R/usr/sfw/lib/mysql -L/usr/sfw/lib -L/usr/sfw/lib/mysql -lmysqlclient -lz -lposix4 -lcrypt -lgen -lsocket -lnsl -lm' --cflags '-I/usr/sfw/include -I/usr/include -I/usr/sfw/share/src/mysql/include'Installing /usr/perl5/site_perl/5.8.4/sun4-solaris-64int/auto/DBD/mysql/mysql
5. Complete the normal installation (make, make test (if you have a test db running), make install).

That’s it.

Auto-completion is a nice feature for an IDE. While Padre supports some auto-completion functions, method auto-completion is an important missing feature. This post is a short round-up of features present in other IDEs.

What auto-completion features does Padre support today?

Beside automatic bracket completion, Padre has a nice auto-completion implementation for variables (first character -including sigil- then ctrl + p):

Eclipse + Epic

Epic (an add-on to Eclipse) has a nice working auto-completion feature activated by the method invocator (->).

As a reference, the java auto-completion in Eclipse:

Komodo Edit

Komodo Edit also has auto-completion for methods, but does not show those inherited from parent classes making the feature rather useless for OO development.

Netbeans

Netbeans has no Perl support, nevertheless the java auto-completion feature is a good example:

The method auto-completion feature is activated by the “.” (“->” in Perl). Not only you get a list of accessible methods (with expected parameter type and return value), but also the javadoc documentation for the selected method.

How should Padre support method auto-completion? Some ideas

1. Method autocomplete should be activated by “->” and “::”. This way class hierarchies can be autocompleted as well. With “::” support for functions can be added.
2. Private methods should be hidden. By convention, private methods start with “_”.
3. Linking method autocomplete to perldoc is a winner combination when programming to not yet familiar APIs and certainly friendly to new Perl developers. While Perl is not strictly typed, a well formatted perldoc entry for a method should make clear what kind of parameters are expected and what the return value could be. However, documentation is rather freely formatted, so it would be difficult to implement in a generic way (without adding formatting restriction to classes).

We all remember the “Perl is dead” hype from not so long ago. In short: Perl 6 wasn’t there yet and perl ironically wasn’t a copy of the language of the day (python, ruby, c#, …).

I was positively surprised by the response of the perl community. It wasn’t the typical “our programs run fast” (to ruby fanboys*) or “space as syntax wtf?” (to python fanboys). Instead it seemed that community took notice of the criticisms and made pretty clear that waiting for Perl 6 was not an option. Today, Perl 6 is doing fine (you can write code in Perl 6) and so is Perl 5.

So what did the community do? Well, Perl Best Practices -and corresponding module Perl::Critic- was a milestone telling people to stop writing perl 4 scripts and respect sane best practices to achieve clean and elegant code. Next to the many great modules already at CPAN (DBI::*, POE::*, DateTime, DBIx::Class (after PBP), WWW::*, etc), the community decided to address some clear shortcomings.

Moose (inspired by Perl 6) was an answer to one of the -in my opnion- greatest shortcoming of Perl 5: the basic OO framework. Perl-based Catalyst jumped on the Ruby-On-Rail wagon. chromatic, a core developer and important community member, started to think out loud what actually “modern perl” means and how we can improve perl by getting rid of obsolete features and bad practices.

An other missing piece, was a beginners-friendly and perl-centric IDE. Padre is aiming to fill this need. Gabor Szabo was able to quickly form a community developing padre (including Alias of Strawberry Perl and PPI fame). I guess this was the kind of project I was waiting for.

I hope that by being part of this project I can contribute to this positive perl new wave.

* fanboy != user

In case you haven’t read it elsewhere, High-Order Perl written by Mark Jason Dominus is now legally available on-line without cost. Get it here.

Of course, if you find the book useful and/or interesting you should buy it. You will not only acknowledge Mark’s work, but you will keep the Perl book micro-cosmos alive. Books that help you learn and widen your knowledge are a must for a language to flourish (not only for languages, by the way).

Having the real thing before buying gives you the power as a programmer to decide if it’s worth your money (no one can buy 1000 books). This beats reading reviews, table of contents or even a quick look in the bookstore.

Thanks for the trust, Mark.

While randomly “googling” I found an interesting news post from 1998:

People show up in comp.lang.perl.misc all the time asking how to use the contents of a variable as the name of another variable. For example, they have $foo = ’snonk’, and then they want to operate on the value of $snonk.

That’s very easy to do in Perl, so they usually get some people to tell them to do it. And they usually get some people asking them why they didn’t use a hash instead.

As a Perl programmer it’s probably one of the most common questions you will hear from people learning Perl. I remember posing the same question back then (before I got to the chapters of references and hashes ). Anyway, it’s a nice read and it may be an useful link for the next time (soon) someone asks you this question…

I love perl. Really. This is not a post inspired by “5 things I hate about Perl“, but rather a question for the wider perl community out there (hi perlshere!). How do you write your OO perl code?

I have some code out there that follows the inside-out objects methodology of Perl Best Practices. Lately I have been writing java code, and inside-out objects feel like a lot of extra – not very intuitive – work to create your classes. I have been looking at Moose, but again it looks pretty cumbersome to create classes (constructors, named parameters for methods, returns, etc.). I am just probably missing a good howto (besides the cookbooks on cpan) or even a printed book on Moose. Any tips out there to get into Moose fast or a nice complete and intuitive alternative (extra points if it’s similar to java’s OO framework)? Thanks.

EDIT (Feb. 16th 2009): it seems I have a direct line with The Perl Foundation: a grant was approved for Dave Rolsky to work on the Moose documentation. Yannick greated a nice pdf output of the manual (see this as well).

apt-gettable perl modules on Ubuntu are great. A nice packager at Debian Gnu/Linux compiled the modules and included all dependencies specially for you .

This is extremely handy when you are looking for a solution for a programming problem that you know someone else solved before. You apt-get the modules you need and have a quick try.

While doing exactly this (tryng to install HTML::TextToHTML) , I discover CPAN on Ubuntu was broken:” Can’t call method “value” on an undefined value at /usr/share/perl5/IO/Uncompress/RawInflate.pm line 64.”.

I don’t think it’s a Debian/Ubuntu problem, but rather a upstream bug. Some people have the same problem on Windows. How nice the apt-gettable modules are, there are always cases when you need to build modules not yet in the Ubuntu repositories or you need a newer version (both cases here). A non-working CPAN is not acceptable. This is what I did.

$ sudo apt-get remove libcompress-raw-zlib-perl

This will remove some perl modules dependent on this package.

$ sudo apt-get remove autoremove

This removed the following packages on my system: libio-compress-base-perl libgetopt-argvfile-perl libfile-temp-perl libpar-dist-perl libextutils-parsexs-perl libextutils-cbuilder-perl libyaml-perl.

$ apt-get install gcc libc6-dev

Install a compiler and include files.

$ sudo cpan

Configure cpan answering the questions; type “exit” to exit CPAN.

$ sudo cpan Bundle::CPAN

This will install most basic CPAN dependencies.

$ sudo cpan <module-name>

To install modules you need.

It is nice when your command line script has clear switches and parameters that have a long and short variant to please a different public. Have a look at this fictional example:

$ myscript.pl "config settings preferences" /var/tmp admin clean

or

$ myscript.pl --file config,settings,preferences --dir /var/tmp --user admin --clean

It’s undeniable that the last one looks more professional and less error prone. The user knows what kind of input is expected and he can type them in whatever order he/she wishes. When he/she is comfortable with your program he/she can even use a shorter notation. The program can be started like this with the same results:

$ myscript.pl --dir /var/tmp --user admin --clean --file config,settings,preferences

$ myscript.pl -f config,settings,preferences -d /var/tmp -u admin -c

How do we achieve this without writing a huge amount of code to treat the command line parameters (@ARGV)? Getopt::Long to the rescue, a real timesaver.

Here is an script template for the use of Getopt::Long:

#!/opt/csw/bin/perl

###################
# A program to do stuff              #
#                                                   #
# Bugs to xxx@xxx                      #
###################

### Modules ###
use strict;
use warnings;
use File::Basename;
use Getopt::Long;

### Parameters ###

if ( !@ARGV ) {
print “\nPlease read the help page: ” . basename $0 . ” -?\n\n”;
exit 0;
}
my ($help, $version, @files, @files_tmp, $dir, $user, $clean);
GetOptions(
‘help|h|?’              => \$help,
‘version|v’             => \$version,
‘file|f=s’                => \@files_tmp,
‘dir|d=s’                => \$dir,
‘user|u=s’             => \$user,
‘clean|c’                => \$clean,
)
or die “\nInvalid switch. Please read the help page: “
. basename $0
. ” -?\n\n”;

@files = split( /,/, join( ‘,’, @files_tmp ) );

sub help {
print “Some help information here…\n”;
}

Let’s review the code.

First, you probably need to change you shebang (#!) to something like “#!/usr/bin/perl or #!perl” depending or you system. I use the perl from blastwave on Solaris, that’s why the shebang points to their binary.

“use File::Basename;” and “use Getopt::Long;” tells perl to use the modules (File::Basename is used to get the name of the script without the path), something you probably already know. Then we check if the program has been started without parameters (!@ARGV). If that’s the case, we exit the program after showing the help page.

The Getoption() function is the interesting bit. Here we define with long and short parameters the program should accept on the left. This is connected to a variable reference on the right (you can ignore the reference part in your code later). You use a pipe (|) to define alternatives like long and short parameter name (“help|h|?’) and “=s” to specify that you need to supply a string as parameter. When you expect multiple parameters for a switch (like the file example), you store these in an array instead of in a scalar. You retrieve the input but reading the variables (no need to dereference).

The “or die” bit is also interesting. Getopt::Long recognizes wrong inputs (“Unknown option:”), nevertheless it continues with the execution of the program ignoring the wrong input. I however, prefer to exit the program when this is the case. The program will exit (with a nice error message) if you invent or mistype switches. As a finishing touch, we create a proper array splitting the input on commas.

That’s it. Fast and easy.

szabgab writes (aggregated on planet.perl.org) about the absence of a decent IDE for perl. To be correct, he rather acknowledges the existence of some IDEs like Eclipse + Epic or Komodo but he prefers to work with the old trusted vi + command line.

That’s fine, but like he writes in his post, some people expect an IDE as they are used to using one while developing in other languages, specially in the Windows world. In my case, I know my way pretty well in Unix (I use it professionally and at my desktop) and vi and still, I prefer to use an IDE. Why?

Well, I’ll answer this question by giving an answer to the “survey” that szabgab proposes. I use Eclipse + Epic for perl. The following text is copy-pasted from szabgab’s post with my answer beneath each line.

Beginners (especially in classes) need these:

• Good Syntax highlighting
  → check.
• Automatic syntax checking
  → check.
• Bracket highlighting and bracket matching
  → check.
• Code suggestion and auto-completion for perl keywords
  → check.
• Showing the available parameters of keywords
  → check.
• Context sensitive help on perl built-ins (including variables and constructs) and on modules
  → check.
• Pod viewer
  → check.
• Integrated Debugger (expression evaluation, breakpoints, watches etc.)
  → check.
• Mouse over tool tips for variable contents
  → not that I know off.
• Debugging: Edit and Continue support
  → check.
• Jump directly to locations (editor-wise) Perl has warned or died at
  → check.

When writing applications (the first few years) people also need these:

• Display subroutines in a sidebar
  → check.
• Auto-completion for methods in OOP development
  → check.
• Remote editing (via ftp, ssh, etc.)
  → I don’t use this, but I suppose it’s built into Eclipse. I use my own scripts executed from the IDE.
• Remote debugging (when the code is actually running on another machine
  → no idea.
• Integration with version control
  → great integration with subversion (the version control I use).
• For web application emulation of a real Web server
  → check (however, I haven’t use this much).

And the more advanced stuff is here:

• Refactoring support
  → check.
• Tool to build GUI
  → None. However, I use this IDE with great results in combination with Glade and gtk2-perl.
  
• Integration with unit testing
  → Not built in, but it can be added using the “External Tools” (this is how I executed scripts remotely, however when I need to edit something in place on a Unix server I use vim).

In short, I have found a professional and complete toolset for my perl needs. It has most of the features needed for a serious IDE and even more (like RegEx engine, export to html, etc). Now that I use netbeans for java, the epic perl plugin is the only reason I keep eclipse installed.

A perl IDE dreamed in the past is a reality.