Advogato blog for pjf

21 Jul 2008

Mon, 21 Jul 2008 09:44:28 GMT

autodie 1.99 stable released - codename jarich
I said that I'd get a stable release of autodie out before OSCON. Since OSCON starts in 5 hours, and I intend to use all that time for sleeping, that means it's being released right now.

After 243 commits since project inception, and three and a half months of work, the first stable release of autodie is making its way to the CPAN. This is not marked as a developer release, so you'll be able to install it using the regular CPAN installer, or dh-make-perl, or whatever other tools you prefer to use to manage your modules.

The observant reader will notice this is a 1.99 release, but I've occasionally bandied around the phrase "autodie - It's Fatal 2.0". The 1.99 release is because I expect to get feedback, patches, and bug-swatting done over OSCON, so the hallowed 2.0 version will appear after the 1.99 release has run the gauntlet of being (ab)used by my peers.

That's not to say the 1.99 release isn't good. It's awesome. autodie has already gone through eight dev releases, as well as being used on my own systems. Go and use it.

Note that autodie does overpower (and on some systems, overwrite) the version of Fatal.pm that comes with Perl. Some of the internal interfaces of Fatal have changed to support new functionality. If you've been calling internal Fatal subroutines (ie, things not documented in perldoc Fatal), then you may wish to hold off until the 2.00 release.

The 1.99 release codename is "jarich", after Jacinta "jarich" Richardson, who pretty much gave up an entire week of her time assisting me with talk preparations for OSCON, and doing practically nothing else. Jacinta, you rock.

For those of you at OSCON, I'll be doing a short talk on autodie at the Perl lightning talks, including showing off some of the cool features like building your own language packs and exception systems.

18 Jul 2008

Fri, 18 Jul 2008 16:57:29 GMT

Journey to OSCON / Module releases
It's 4:30pm in Oregon, the jetlag is pretty bad, and I'm drinking yet another coffee to perk myself up. The thing is, I'm still in Australia, where it's stupid-o'clock in the morning. I figure getting the jetlag out of the way now and sleeping on the plane is going to be better than being awake during the plane and whacked in Portland.

At least, that's the plan.

I've spent all of today, and all of yesterday, and all the day before that working on slides. I'm giving 4.5 hours worth of presentations in tutorials and conference talks, and since my presentations tend to move fairly quickly, I have more than one thousand slides prepared. I'm still adding them, or at least I was until brain crashed.

So, as a "reward" for having worked on so many slides, I'm writing code. At 2:30 in the morning. I've pushed out a new release of IPC::System::Simple. It now has capturex() and systemx(), which are variants of capture() and system() that never ever ever use the shell, even if you use one argument. Thanks to ikegami for encouraging me to implement this.

In order to make sure my Perl Security tutorial matches reality, there's also a new release of Proc::UID making its way to the CPAN. It's mainly a tidy-up of the old code, with better documentation, tests, and build system.

What I haven't got out yet is the stable release of autodie. Yes, I know it's what everyone's waiting for. Before I can release it, I want to walk through my TODO list and figure out what really needs doing, and what can be put off. Unfortunately my spell-point meter is dangerously low from the jet-lag, and casting "comprehend project" is rather challenging right now. Instead there's a good chance I'll be making a release while over the Atlantic, and pushing that to the CPAN once I touch-down.

For those hoping to meet me at OSCON, I'll be landing Saturday, but I won't be very sociable until Monday afternoon, after the stress of my tutorial is over.

14 Jul 2008

Mon, 14 Jul 2008 02:50:59 GMT

See me talk at OSCON 2008
Next week is OSCON 2008, and I'll be presenting! Since I'm Australian, and I know Perl, you can expect my presentations to be awesome. ;) You can come see me at:

Perl Security, 1:30pm - 5:00pm, Monday 21st July.
An Illustrated History of Failure, 5:20pm - 6:05pm, Wednesday 23rd July.
General lightning talks, 1:45pm-2:30pm, Thursday 24th July.
Hacking Wetware for Fun and Profit (aka "Human Interfaces for Geeks"), 2:35pm-3:20pm, Thursday 24th July.
Perl lightning talks, 4:30pm-5:15pm, Thursday 24th July.

Of course the lightning talks will have other people presenting as well, and should be heaps of fun. Anthony Baxter runs the OSDC lightning talks, and is also running the general lightning talks at OSCON. OSDC has the best lightning talks ever.

On the topic of OSDC, you can see me presenting there as well (paper acceptance is not yet confirmed, actual results may vary), so come to Australia for OSDC from the 2nd-5th December!

4 Jul 2008

Fri, 4 Jul 2008 03:54:49 GMT

autodie 1.11_01 "Aristotle" released - Awesome inheritance
autodie version 1.11_01, codename "Aristotle", is now making its way through the CPAN. The new version contains quite a few exciting changes. You should be able to make and install the new version just like any other module, without having to muck around with @INC. Do be warned it will overpower your existing Fatal.pm, and while it should be completely backwards compatible, there's always the small risk of bugs that I've missed.

In this post, I want to show you why autodie is so cool, particularly with this new release.

Because autodie is smarter than Fatal, a whole bunch of things which are normally bugs start being correct if you're using autodie. As an example, take the following code:

if ( fork() ) {
   # This is the parent process.
} else {
   # This is the child process.
}

Normally, that code involving fork contains a bug, because fork could return an undefined value to indicate the fork failed. Since we're not checking for undef, our parent would act as a child process, and things are likely to go very badly from there.

However, with autodie we can write:

use autodie qw(fork);

if ( fork() ) {
   # This is the parent process.
} else {
   # This is the child process.
}

And now the code is correct! autodie knows that fork is allowed to return zero to the child, but returning undef is an error. This is much easier than checking the return values manually.

However in my opinion the best thing about the new release is that we can now cleanly subclass both autodie and autodie::exception, which means we now have a very easy way to slot in our own exceptions frameworks.

Let's start with a trivial example, and pretend we think the old name lethal was a better name for the module. We can just write inside a new lethal.pm:

package lethal;

use base qw(autodie);

1;

And now, we can use lethal the same way we would use autodie.

As a more complex example, let's say that we want to do a bit of localisation. I want an Australian version of autodie that caters to our strong cultural identity. I can write inside bludging.pm:

package bludging;

use base qw(autodie);

sub throw {
   my ($class, @args) = @_;

   return bludging::exception->new(@args);
}

package bludging::exception;

use base qw(autodie::exception);

# Mate, it's always a good time for a beer in Australia!
sub time_for_a_beer {
    return "Now's a good time for a beer.";
}

sub stringify {
    my ($this) = @_;

    my $original_string = $this->SUPER::stringify;

    return "$original_string\n" . $this->time_for_a_beer;
}

1;

I can now write:

use bludging qw(open);

open(my $fh, "<", "fair_dinkum.txt");

If fair_dinkum.txt doesn't exist, I get the Australian-friendly error message:

Can't open 'fair_dinkum.txt' for reading: "No such file or directory" at australia.pl line 1
Now's a good time for a beer.

Of course, one could instead extend the exceptions to use your favourite object framework, wake your sysadmins up in the wee hours of the morning, provide extra diagnostics and stack back-traces, or do anything else you consider worthwhile.

So, what are you waiting for? Grab yourself autodie 1.11_01 from the CPAN now, or (if your mirror is a little behind) you can download the release directly from my server.

29 Jun 2008

Sun, 29 Jun 2008 07:08:56 GMT

autodie release 1.10_07 - Codename ikegami
Don't know what autodie is? Check out the 5 minute video and find out.

It's Sunday, and that means autodie release day! The new version of autodie is codenamed "ikegami" in honour of the wonderful perlmonk who assisted me in solving one of the trickiest problems in getting autodie running under its new architecture.

In fact, the architecture is the big change for this release. In older versions of autodie, different code was used when running under Perl 5.8 than under Perl 5.10, and each code had its own set of bugs and own maintenance that was required. That meant twice as much work for me.

The new code employs a single unified architecture regardless of the version of Perl used. In fact, in the ikegami release the total number of lines of code dropped, rather than increased. That's a good thing for maintenance, and goes quite some way to paying off a lot of the technical debt I've been accumulating in the project.

There's also been the regular swag of bugfixes, improvements and tests. You can check out the changes file for full information.

You can help autodie!
I've still got a big list of things to complete in my TODO list. Some of them are large, and some of them are small. I also need a bunch more test cases, both working and failing.

If you do wish to help, then feel free to grab the code from CPAN, or take a copy of the autodie repository using git, and feel free to send me patches or even ask for a commit bit. I won't bite.

Also feel free to say "I want to help, but I don't know where to start", and optionally a bit about your skills. I'm sure I can put you to good use. ;)

Even if you don't want to help with the project per se, I am very interested in hearing about if you've been using autodie, are planning on using autodie once it's completely stable, or just think it's a great idea. Likewise, if you think autodie sucks (or needs improvement), I'm also interested in hearing from you, so I can make it suck less. Drop me a note at pjf@cpan.org.

23 Jun 2008

Mon, 23 Jun 2008 12:01:53 GMT

Be cool and join ohloh
Ohloh is a website that tracks open source projects. It looks at source code, prepares metrics, and draws lots of pretty graphs. It's great if you want to compare your favourite languages, or see how a codebase changes over time, or see how often you commit to various projects. Like anything web 2.0 these days, it has ways of making friends and rating people and projects.

However, like most things I write about, ohloh has a serious problem. Put simply, it has me listed as the seventh highest committer in the open source world for projects written in Perl this quarter.

This, of course, is complete bollocks. Sure, I write a lot of Perl, but only when I'm at work, travelling, at a Perl conference, at home, or waiting for a bus. There are lots of people out there who write way more code than I do, but they're not listed on ohloh.

So, how can you correct this terrible state of affairs? Well, firstly you can get yourself an ohloh account. Go poking around and claim all the commits you've made on various projects; you may be surprised how many you have, and instead of ohloh thinking of you has half-a-dozen cool people, it'll think of you as one amazing person. Once you've done that, you won't be happy with your score, so go and add any projects to which you've done anything at all to ohloh. Claim those commits. Rinse, repeat.

Before long, you'll have a massive kudos score, and you can show off to all the kids on #moose about how amazing you are. The Moose folk are really impressed by ohloh statistics; that's why so many Moose contributors are in the Perl top contributors list.

And yes, I've already got an account.

22 Jun 2008

Sun, 22 Jun 2008 12:26:20 GMT

autodie release 1.10_06 - Codename chocolateboy
I'm very pleased to say that the next release of autodie is making its way to CPAN. The release's codename is "chocolateboy", after the wonderful author of autobox who spent many hours discussing the inner workings of pragmas, provided thousands of words of advice, and who allowed me to use him as a sounding-board when I had far too many ideas and not enough implementation.

The new version provides massive improvements in Perl 5.8 support, including:

User subroutines can be lexicalised
Fatal and autodie can be used together
Fatal backwards compatibility mode fixed
autodie will no longer cause weird interactions with autobox
Better error messages
Lower memory overheads
Faster loading

I've still got a huge list of things left to do, but this release is a major stepping stone since it contains code that can lexicalise arbitrary subroutines, with many thanks to ikegami for help in debugging.

My next big tasks are:

Moving the Perl 5.10 implementation to use the Perl 5.8 code, which is actually faster and has less side-effects.
Writing a whole stack of documentation on how to use it, why you'd want to, and what bugs exist.
Having a really good think about the autodie::exception interface. I'm planning to bounce ideas off the Moose crowd for this one.

If you're interested in learning more about the project, you can read my previous blog posts, or track the project on github or ohloh. I also welcome any questions, feedback, and especially patches at pjf@cpan.org.

15 Jun 2008

Sun, 15 Jun 2008 11:48:08 GMT

autodie works under Perl 5.8
After applying a very different paradigm to the code, I have autodie working under Perl 5.8! For anyone who's missed my earlier posts on the subject, autodie allows Perl's built-ins (and your own code, if you like) to 'succeed-or-die' with lexical scope. This means you can write code like this:


if ($filename) {
    use autodie;  # Turns on all common built-ins by default.

    open(my $fh, '<', $filename);  # This opens or dies

    # Do things with my file.

    close($fh);                    # This closes or dies
}

# This open merely returns false on failure.
open(my $fh2, '<', $file2);

It gets even better, because unlike the old Fatal.pm, autodie also allows you to enable succeed-or-die semantics with system(), by hooking into IPC::System::Simple under the hood:


eval {
    use autodie qw(system);

    # Perform the commands below in order, but
    # if any fails, we automatically skip to
    # the end of the 'eval' block.

    system($mount_tape);
    system($check_tape_label);
    system($backup_files);
    system($unmount_tape);
    system($delete_old_files);
};

if (my $error = $@) {
    # Something went wrong.  Recover/handle it here.

    system($unmount_tape);  # autodie not in effect, this fails silently.

    wake_sysadmin_from_slumber();

    # $error / $@ stringifies into a helpful error message.  What
    # command failed, which script, which line, what did it return,
    # what signal name/number killed it, etc.

    die "Backup failed - $error";

}

If an autodying built-in fails, it doesn't just die with an ugly error (like Fatal does), it throws a well-formed exception object. You can catch that, inspect it to discover where the error occurred, what called the code that caused the error, what the arguments were, and almost all the things you'd want to discover during exception handling. If you use it as a string, it becomes a helpful error, which can depend upon the function that threw the exception. You can even register your own message handlers, making localisation easier.

Of course, the code isn't complete, I've got a big TODO list that's far from complete, but the hardest part of getting it working under 5.8 is done.

You can grab the latest version of autodie from the CPAN. I'd also like to say a special thank-you to all the people who have contributed so far, especially to Matt Trout for pointing me at namespace::clean, and Robert 'phaylon' Sedlacek for writing it; the heart of namespace::clean was twisted to my dark will to make autodie work under Perl 5.8.

If you want to play with the bleeding edge code, you can grab the code from git (or use the download button on that page for a tarball); let me know if you'd like a commit-bit. If you have bugs, comments, suggestions, praise or encouragement, feel free to e-mail me until the autodie bugtracker finds its feet.

12 Jun 2008

Thu, 12 Jun 2008 07:55:26 GMT

autodie 1.10 beta released - It's Fatal 2.0!
After much hacking, I'm very glad to say that I've got a version of Fatal/autodie that I'm willing to foist upon the world for beta testing. It's not a release candidate, but all the important things that should work, do work (I hope).

For those who haven't seen my previous discussions, you can think of autodie as a Fatal 2.0. It provides lexical scope, exception objects, and much nicer error messages. It even lets you make system() fatal[1].

You can find the distribution at:

http://perltraining.com.au/~pjf/autodie/

It's currently not on the CPAN because I don't want innocent bystanders replacing their Fatal.pm by accident.

Currently it only works on Perl 5.10 and above. Support for 5.8 is on my TODO list.

I'm specifically after feedback on the following points:

Do any tests fail on your system?
If you use the new Fatal.pm module, does any of your existing code break? (It should be 100% backwards compatible.)
If you s/Fatal/autodie/; in your code, does it do what you expect? Are the error messages nicer? Are there any gotchas I've missed?

If you really want to get your hands dirty, feel free to look at the TODO file, the DESIGN.pod file, or the source code in general. Suggestions and patches are very much appreciated. If you've got a github account, I'm happy to give you commit access, or you can just fork the repository.

If you want to see my five minute talk about what this is about, see the video in my blog.

If you want to track my repository of changes, you can find them at:

http://github.com/pfenwick/autodie/tree/master

I also want to say a special thank-you to Aristotle, who has provided invaluable feedback while I've been working on the project.

Any questions, feedback, criticisms, patches, or ideas are welcome.

Many thanks,

Paul

[1] To fatalise system() you'll also need to install IPC::System::Simple.

11 Jun 2008

Wed, 11 Jun 2008 04:24:46 GMT

brian d foy asked in his use.perl blog:

I haven't had time to figure out how to put the slides and audio together in one package. Has anyone done that before?

That would be me.

I've even had a good rant about how hard it is.

Slideshare
Put simply, if you're using slideshare, and your talk is short, and you move through your slides relatively slowly, and you have somewhere to host the audio, then using slideshare's "slidecasting" options is fine. I've got an example with one of my own talks on hiveminder.

If any of those conditions aren't true, then unless SlideShare's slidecasting software has become significantly better, avoid them. SlideShare is particularly bad if you have lots of fast slide transitions, because it only tries to cache "one frame ahead", and depending upon network conditions whoever is watching your slidecast may hit that frame before it's fully loaded, in which case it just gets dropped. I only really consider SlideShare suitable for death-by-powerpoint.

YouTube
These days I do videos, and upload them to youtube. The resolution sucks, and there's a 10 minute time limit, but everyone knows how it works, and it doesn't drop frames.

If you've gone to the effort of putting together a decent movie for youtube, then you can always place the full-resolution copy somewhere for people who care.

Video Production
So, how do you put together the video? For me, it's usually three steps:

1. Record the audio. If you've done this at a life presentation, great, having a real audience laugh at your jokes is fantastic. If not, then sit down with a mike and your slides, and pretend you have an audience. Give yourself a few seconds of complete silence at the start, you'll thank yourself when it comes to doing noise-removal later on.

If you flub while doing the recording, that's fine. Wait to get a few seconds of silence, then count back in with a "one, two, three". This makes it easy to see the flub when editing the soundtrack.

For sound editing, I recommend using audacity. It's free, open source, cross platform, and totally awesome. Edit out your flubs and any other sounds you don't want in your final cut. Do a noise removal and a normalisation on the whole soundtrack if it needs it.

2. Dump the slides as images. This can be really frustrating. I use OpenOffice.org (OOo), which has an "export as png/jpg/etc" feature. However it only exports the current slide, and my talks usually have hundreds. There are some OOo macros about that apparently do the job for you, but I haven't tried them. I don't know why "Export entire document as png/jpg/etc" isn't built into the software.

Instead of using OOo's image export, I use OOo's "Export as PDF" function. It works really well. I then convert the PDF into images, since there are lots of PDF->image converters out there. I personally use ghostscript for this job. Make sure all your images sort correctly in asciibetical order; so the images should be called slide-001.png, slide-002.png. If you just call your images slide-1.png and slide-2.png you'll hit sorting issues once you get to ten slides or more.

3. Make the movie. If you have decent movie-making software, this should be a matter of importing the slides, importing the audio, and moving the slides back and forth until they match the timing you want. This can take a lot of time if you have a lot of slides, audio, or both.

Production Software
If you're using a Mac, you probably have some awesome video editing software installed which does the job for you; Macs seem to be good at that. If you're using Linux, there seems to be a huge number of FOSS video editing solutions with great reviews.

If you're using Windows, then don't use Windows Movie Maker. You'll get about half way through your editing process, and it will die horribly. Really, it's awful.

I use CyberLink Power Director, because it came bundled with a camera I purchased a while ago. It's more suited to taking the video of your child riding a bike, adding some music and titles and burning onto DVD, but it does an okay job with talks production.

The export features on Power Director are awful, they all produce massively huge files (because that's what DVDs want), or crappy resolution files (designed for mobile devices), or produce audio artefacts when encoding(!), or want to use a widescreen aspect ratio (because you'll be playing your DVDs on your TV), or run incredibly slowly. With enough screwing around I found I could get it to use the xVid encoders which I probably installed from the Combined Community Codec Pack, which are fast and awesome and let me specify exactly what I want.

Now what?
Once your talk is exported, upload it to youtube, and publicise it. I recommend embedding it into one of your own pages, and then at the very least submitting that page to digg and stumbleupon. I recommend this over publicising the youtube page directly because it gives you more control over your content. It's much easier to provide a link to your other presentations, a download link, a list of further resources, or anything else when you control the page your viewers will be going to.

And that ends my not very brief write-up on how to put a talk on-line. If you want to see some that I've done myself, you can find an index on my talks page. My most popular so far (with over 100,000 views) has been fixing the web with greasemonkey.