Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday October 06, 2006
03:20 AM

SmallTalk in Perl (More exception handling)

[ #31234 ]

One of the things SmallTalk proponents like to brag about his how they can change their source code while it's running. That's pretty cool and I want it for Perl. As a follow-up to yesterday's post on better exception handling, imagine the following scenario.

Your batch process takes four hours to run. Three hours into the run, it throws an exception. An email is sent to the ops team who call you. You log in from home to discover that the program has not terminated. Instead, it's put you in an interactive mode "FIXIT" mode. After a bit of debugging, taking advantage of FIXIT's use of PadWalker to examine other variables and even (shudder) change their values, you realize that the problem is in your Customer::frobnicate method. It's forgotten an edge case that's easily handled.

So at your request, FIXIT fires up an editor with the appropriate source code and you make the necessary changes. You save and are presented with a diff and the ability to reedit the code. Once satisfied, FIXIT installs the subroutine or method and you can ask it to resume execution of the code, rather than starting your four hour run from the top.

Nothing in that scenario is particularly hard, but there are a lot of fiddly bits which wouldn't look quite right (and deparsed coderefs for the editor look just ugly, but they would work).

Update: In yesterday's post, both Joshua ben Jore and Salvador Fandiño both point to tools which can handle this (one being 5.9 specific). If this can be done so trivially, why aren't more people using it? I'm confused.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Just like people never seeing OO or declarative solutions to problems if all they've ever used is FP.

    If you've come from a background where you take source files, compile them, and get running code out the other side then making that mental leap of going in the other direction is hard.
    • The potentially fatal flaw in the plan:

      #!/usr/bin/perl -l

      use strict;
      use warnings;


      sub a {
          print 'whoops!';

      sub b {
          no warnings 'redefine';
          *a = sub {
              print "hi there!";

      This is obvious in retrospect. I can't imagine this would be easy to get around.

  • Although I know there are people out there writing large, long-running apps in Perl, I think a lot Perl programs are simply not well-suited to this style of development. For example, I do a lot of data munging and interpretation in Perl, i.e. small, separate transformations on large piles of text. From within Emacs, I can interact with Perl through either an inferior shell or an interactive interpreter (via Sepia). Even when I have both open, I usually find myself testing snippets in Sepia, but doing mos