Monday, July 27, 2009

Perl's popularity problem...

There has been a recent flurry of blogs on Perl's perceived popularity problem:

I'm a little cynical. Many good insights and areas for improvement are identified. But Perl needs to gain mindshare. And the only way to do that is to deliver the goods: Perl needs best of breed and/or innovative killer apps...

There is very little going on today which makes Perl relevant to anyone outside the Perl community. The reality is that Perl isn't much on anyone's radar except the people who already use it...

The insights which particularly appealed to me are:

  • Perl5 and Perl6 could definitely benefit from a "This is not your father's Oldsmobile" slogan. Perl doesn't market itself well.

  • Perl could use a modern clean cohesive comprehensive web portal which borgs the best of what the scattershot sites out there provide: CPAN, PAUSE, Perl Mongers, perldoc, perlmonks, ironman, use.perl, perlbuzz, the various community SCM repositories, professional training, perl jobs, etc. An effort to unify those disparate sites and services into a cohesive whole using modern and enlightened Perl would give Perl5 a chance to redefine itself.

Perl may look dead to outsiders, but there is a lot going on within the Perl ecosystem. There is: Perl6 (std, Parrot, Rakudo, SMOP), Moose, Catalyst, DBIx::Class, The list will vary from one Perl programmer to another. There is Padre, which shows promise of being of interest to non-Perl developers. And new in-roads into Bioinformatics. But O'Reilly and James Tisdall laid that foundation back in 2001 and 2003.

Another problem we need to answer, is why projects which are bootstrapped with Perl leave it behind?

Git, Linus Torvald's SCM love child, was originally assembled with a whole lot of Perl duct table, bubble gum, and glue. But if you visit, you'll be surprised by how irrelevant Perl now appears to be to git.

Where are the new exciting, relevant solutions which use Perl?

Maybe they exist, but we're not aware of them? Muldis Rosetta is a truly relational RDMS (not SQL) being developed by Darren Duncan. Sounds interesting and promising... Does it work? Is it fast enough? Is it ready for use in production environments? Can it work with DBI, DBIx::Class, ODBC, JDBC, etc? Why aren't more developers involved with it?

Mojolicious looks like a fresh new MVC. In a fairly crowded field, it may be hard to distinguish itself. Take a look at Sebastian Riedel's recent Mojolicious::Lite blog.

Where are the other fertile grounds from which new solutions will arise? What other projects are out there which are using Perl to solve something new or solve an old problem in a better way?

Thursday, July 9, 2009

Legacy Traps

Here's an interesting dialogue from #perl6 yesterday:
TimToady  but the fact is, Perl 5 is basically in a no-win
situation long term, which we first recognized in
PerlJam TimToady: now you're alienating all the staunch perl
5 supporters :)
TimToady I'm only alienating them "long term"
KyleHa If loving Perl 5 is wrong, I don't want to be right.
PerlJam Someone mentioned (probably on use.perl somewhere)
that Nicholas tried regular release cycles a while
back. I'd like to know if that's true and if so,
what became of it.
ruoso I don't really think the regular releases is the
TimToady I love Perl 5 too, but it's stuck (culturally, and
maybe technically) in a legacy trap, and the Perl 6
approach is the only long-term way out of that.
moritz_ ruoso: it's not about *regular*, but about being
able to release when there's something to fix
TimToady Perl 5 is a velociraptor, but we need an
acceloraptor now.

There ought to be a corollary to that saying about "Fast, Good and Cheap. -Pick any two". -Something to deal with legacy vs. innovation and revolution vs. evolution. But I suppose the latter is fundamentally a balance between looking backward while moving forward, the threshold of pain you're willing to undergo, and how you attempt to minimize it.

I wouldn't pretend to have the experience or wisdom to find the right balance. However, it doesn't appear to be a new problem.

C++ went through a period of upheaval not too long ago. There was a nice Dr. Dobb's article on it back in 1997. Well worth reading.

Here's a Linux kernel developers thread on the same topic of evolution and change. -A nugget from Theodore Tso:
"Clearly, we are right to mock Solaris for making claims that
they will never, ever, *ever* change an interface, not even
one that goes back sixteen years to Solaris 2.3. But it
doesn't follow the opposite point of view, that constant
mutability of kernel interfaces to make sure that things are
always perfect and pure and clean is the right one either."

Tuesday, June 23, 2009

Transcoding video for OLPC XO using VLC on OSX

This is more a note to myself than anything else, but perhaps someone else will find it useful? I certainly find it useful to transfer DVDs over to the kids' OLPC XOs running teapot's Ubuntu intrepid distro for XO.

On OSX using VLC, the following will transcode a video stream/file down to something that will play well without skipping on an OLPC XO 1.0. I.e., a theora/vorbis file named w/ the ogg extension using a 320x240 resolution at 15fps. -You'll wind up with an out.ogg file in the current working directory.

Open an editor and save the following to a file named vlc2xo:

/Applications/ -I dummy -vv "$1" \
--sout='#transcode{width=320,height=240,scale=1,vcodec=theo, \
vb=768,acodec=vorb,ab=64,channels=2,deinterlace, \
audio-sync}:standard{access=file,mux=ogg,dst=out.ogg}' \
Make it executable: chmod 755

Now, you'll be able to open terminal and execute the script with an argument specifying the file or input stream to be transcoded. Examples:

./vlc2xo dvdsimple:///dev/rdisk1
./vlc2xo /Volumes/MyExternalDrive/movies/FoTR/FoTR.iso
./vlc2xo /Volumes/MyExternalDrive/movies/RoTK/

Note: in the first example, dvdsimple is used to avoid dvd navigation issues. Also, you can use diskutil list to get a list of disk devices and enumerate over them using diskutil info [identifier] to identify the dvd drive. Once you identify the /dev/disk#, use /dev/rdisk# w/ the same #. If you know or figure out why we need to reference rdisk# instead of disk#, drop me a comment, I'd like to know...

scruffy:~ ggoebel$ diskutil list
#: type name size identifier
0: GUID_partition_scheme *298.1 GB disk0
1: EFI 200.0 MB disk0s1
2: Apple_HFS Scruffy 297.8 GB disk0s2
#: type name size identifier
0: Resident Evil Extinction *7.6 GB disk1
#: type name size identifier
0: FDisk_partition_scheme *298.1 GB disk2
1: Windows_NTFS Tramp 298.1 GB disk2s1

(and if the dvd's label isn't enough to identify the dvd device...)

scruffy:~ ggoebel$ diskutil info /dev/disk1
Device Node: /dev/disk1
Device Identifier: disk1
Mount Point: /Volumes/Resident Evil Extinction
Volume Name: Resident Evil Extinction

File System: UDF
Partition Type:
Bootable: Not bootable
Media Type: DVD-ROM
Protocol: ATAPI
SMART Status: Not Supported

Total Size: 7.6 GB
Free Space: 0.0 B

Read Only: Yes
Ejectable: Yes
OS 9 Drivers: No
Low Level Format: Not Supported

Media Type: DVD-ROM
Erasable: No

Note: The last example works when pointing to a directory containing the VIDEO_TS and AUDIO_TS directories from a ripped dvd.

The VLC documentation for the format for a stream is:
Stream MRL syntax:

URL syntax:
[file://]filename Plain media file
http://ip:port/file HTTP URL
ftp://ip:port/file FTP URL
mms://ip:port/file MMS URL
screen:// Screen capture
[dvd://][device][@raw_device] DVD device
[vcd://][device] VCD device
[cdda://][device] Audio CD device
udp://[[<source address="">]@[<bind address="">][:<bind port="">]]
UDP stream sent by a streaming server

Sunday, June 7, 2009

Catalyst::View::Mason Documentation ne Implementation

I've got an old gentoo Apache mod_perl Mason site which I maintain for work. Mostly it is used for mining data from our less than desirable issue tracking system (Soffront Track) in order to help make realistic guestimates of what we can deliver and when.

It is running on an old quad xeon box that we'd experimented with, and decided not to use in production. Since work is a "Microsoft" shop, it has long been an item on my todo list to move it over to a windows box... but for some reason, I've never really gotten around to it.

However, a couple years back I did do the least amount of work necessary to get it to run in a windows w/ Catalyst::View::Mason environment. I've changed laptops a couple times since then, Perl 5.10.0 was released and Catalyst 5.8.

So last week, I reinstalled the latest version of all of the above on my laptop so I could take my work with me on the go.

I found that I had to add:
__PACKAGE__->config(use_match => 1);

to my for backward compatibility.

What was slightly annoying, is that while this was ultimately easy enough to find and fix... it isn't what the README says (

Use "$c->request->match" instead of "$c->action" to determine which
template to use if "$c->stash->{template}" isn't set. This option is
deprecated and exists for backward compatibility only.

Currently defaults to 1, to avoid breaking older code, but new code
should always set this to 0.

(more later... my plane is boarding...)

Thursday, May 21, 2009

Adding Perl Support to Google App Engine

I was asked the other day to help setup a website for our elementary school's PTA. I thought for a while about the various free services available vs. virtual hosting and finally wound up going with Google Apps.

You might be wondering what this has to do with Perl. Well one of my quirks, is that I tend to alternate between adding perl or linux to my google searches whenever I want to find a decent dialog on a topic. Guess what turns up with a search on: google + apps + perl?

Apparently about 9 months ago, Stephen Adkins, Dean Arnold, Brad Fitzpatrick, Artur Bergman, Chia-liang Kao, Yuval Kogman, Jonathon Rockway, and others were working on a Perl App Engine implementation for Google App Engine. It looks like it stalled.

But maybe with your help, and a show of support, we can get them to pick it up again. On the "Open Issues" list for Google App Engine, the top 3 requests are adding support for PHP, Ruby, and Perl. You can express your preference for Perl support by going to the "Open Issues" list, finding issue #34, and selecting the star beside it.

At the time I'm writing, Perl is about 300 votes behind Ruby and about 1,000 behind PHP.

Update: As of Sat. May, 23rd at 10:19 EST, Perl has almost closed the gap with Ruby by half. The current votes are:
  • PHP: 2055
  • Ruby: 1558
  • Perl: 1396

Monday, May 11, 2009

Padre on OSX

Work and life have been keeping Perl mostly on the sidelines this past week.

I've been following Gabor Sazbo's blog posts on Padre since he first asked for suggestions for a name. But I haven't actually used it. The idea of a cross platform internationalized open source editor written in Perl is actually pretty exciting. Especially with all the pluggins available and promise of better syntax highlighting. I've always heard that only perl can parse Perl. So it is nice to see a lot of developers actively developing a best of breed editor in Perl.

I noticed that the instructions for installing Padre on OSX would have had me running a massive update of the system's perl via cpan. I've always been a little risk averse. The idea of upgrading the operating system's perl sounds like a recipe for trouble.

So I tried installing padre using my local install of Perl 5.10.0. Unfortunately, Padre requires a Perl compiled with -Dusethreads. So... why not... I recompiled a threaded perl executable. I was then able to run cpan and install Padre without problem. Padre executes and comes up just fine.

I took a little time to update the wiki instructions just so the next traveller will know that it is indeed possible to run Padre on OSX compiled locally from source. But now my time is up. I'll have to write up my experiences with Padre next time.

Monday, May 4, 2009

cross pollenation of perl6 implementations

Most days, I try to drop by and scan through the conversations of the various people actually implementing and testing Perl6. More often than not, 98.6% of the conversations involve details that are over my head. But it is still nice to check in on the ebb and flow of progress. As often as not, I learn a thing or two too...

Today it was nice to see über tester Jonathan Worthington and Rakudo's Patrick Michaud talking about refactoring Rakudo's p6opaque. What was nice, beyond the open and informative dialog... was the many references to SMOP's design and dialog with Daniel Ruoso. (FYI: SMOP is a bottom up implementation starting with Perl6 OO features.)

I often hear references to how the various implementations have exercised the specs from different angles. It is nice to see how the various implementations are strengthening and facilitating each other.

Monday, April 27, 2009

Rakudo on OS X 10.4

I've decided to do the download, compile and run the test suite for each of the Perl6 implementations which are being actively developed: Rakudo, SMOP, and Elf.

Rakudo seems to have the largest number of developers, the most activity, and passes more of the spec tests. So I'll start with it.

From the Get Rakudo page I found the latest snapshots. At the time I'm writing, the latest snapshot is rakudo-2009-04.tar.gz.

So starting with my macbook running OS X 10.4... I downloaded it, opened terminal, untarred it, cd'd into the resulting rakudo-2009-04 dir and per the instructions executed:
$ perl --gen-parrot

This results in:
Generating Parrot ...
perl build/

Checking out Parrot r38250 via svn...
Can't exec "svn": No such file or directory at build/ line 46.

Looks like I never reinstalled Subversion when I reinstalled OS X 10.4 onto a larger drive.

Okay. So I head over to and click on the openCollabNet link (because I already have the Apple Developer Tools installed). Once there, I filled out a request for contact information (blech), and downloaded the 18MB Subversion 1.6.1 Universal.dmg. Yes, I could compile from source, but I'm being lazy.

After running the pkg installer, in order to get svn in my PATH, I had to edit ~/.profile and add the line:
export PATH=/usr/local/bin:$PATH

Okay... back to where I began:
$ perl --gen-parrot

I get further. Up to the point where it is brought to my attention that the certificate for does not come from a trusted certificate authority. It reminds me of Adam Kennedy's comments in his recent "Beautiful is better than ugly" post:
And for god sake, can someone with a spare thousand bucks leftover from a YAPC PLEASE organise legitimate crypto certificates for the SSL websites? This whole self-signed certificate crap makes us look like incompetent amateurs (when we are supposed to actually be competent amateurs)

Oh well... I accept it and spend the next few minutes watching it fetch, configure, and compile the parrot source in a subdirectory.

You can now use 'make' to build Rakudo Perl.
After that, you can use 'make test' to run some local tests,
or 'make spectest' to check out (via svn) a copy of the Perl 6
official test suite and run its tests.

That jives with the original instructions. So I do:

...and a minute or two later after no apparent errors:
make test

...and less than a minute later:
make spectest

...this one results in spec tests being sync'd via svn before running. It took about 34 minutes before spitting out:
All tests successful.
Files=367, Tests=10640, 1445 wallclock secs ( 6.53 usr 2.91 sys + 2019.76 cusr 86.89 csys = 2116.09 CPU)
Result: PASS

I noticed that by default, rakudo produces a perl6 binary. So for fun:
$ ./perl6 -e q{hello}.say

Not hard at all. No frustrations. Easy as pie.

In my next post, I will find time to lather, rinse, and repeat on boxes running WinXP and Linux. Then, time permitting, I'll start digging into the tests and specifications...