Stories
Slash Boxes
Comments
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 ]

AndyArmstrong (7200)

AndyArmstrong
  (email not shown publicly)
http://hexten.net/
+ -

  Comment: I'd just... (Score 1) on 2009.10.06 13:01

by AndyArmstrong on 2009.10.06 13:01 (#70800)
Attached to: Finding Duplicate Files
...do a find in each directory and then diff the results. cd firstdir && find . -type f > ~/first cd seconddir && find . -type f > ~/second cd ~ && diff first second You can filter the output of the diff of course :)
Read More 8 comments
Comments: 8
+ -

  Comment: Go girl! (Score 1) on 2009.09.23 7:35

by AndyArmstrong on 2009.09.23 7:35 (#70657)
Attached to: Joining the TPF Board of Directors
Congratulations - I'm sure you'll be a brilliant addition to the board :)
Read More 3 comments
Comments: 3
+ -

  Comment: Well done (Score 1) on 2009.07.20 9:59

by AndyArmstrong on 2009.07.20 9:59 (#69549)
Attached to: Darwin award disqualification
Yippee! Well done. Bring her to YAPC::EU - Perl needs some young blood :)
Read More 8 comments
Comments: 8
+ -

  Comment: Re:Absolutely... (Score 1) on 2009.07.05 13:03

by AndyArmstrong on 2009.07.05 13:03 (#69280)
Attached to: Polite fiction and the elephant in the room
Indeed. I got carried away by my own analogy.
Read More 16 comments
Comments: 16
+ -

  Comment: Absolutely... (Score 1) on 2009.07.05 11:41

by AndyArmstrong on 2009.07.05 11:41 (#69274)
Attached to: Polite fiction and the elephant in the room

Yeah, I'm assuming there's a "not" missing there and, based on that assumption, I absolute agree.

I have trouble understanding the arguments against adopting a regular release schedule. The implication is that quality will suffer if releases are made based on the date rather than the readiness of the code - which would be true if the pumpking just bundled and shipped whatever was in the repo at that point in time - but that's not at all what's being proposed. And co-opting DarkPAN to endorse the current release policy just sounds like religion to me: "we're not sure what it is, how much of it there is or even if it exists but we'd better not piss it off."

Read More 16 comments
Comments: 16
+ -

  Comment: Re:Safari is not doing anything wrong (Score 1) on 2009.07.02 19:50

by AndyArmstrong on 2009.07.02 19:50 (#69232)
Attached to: Safari 4 likes clicking

If I thought Safari was doing anything wrong I'd have been nastier about it. The point was that it's doing something that browsers haven't done in the past and that's going to cause a bit of head scratching until people realise that Safari goes off on little jaunts through your favourites when it feels like it. It's pretty common IME for people to assume that if they're on a private network they don't need to worry about using GET with side effects.

Years ago I had a client who couldn't understand how pages from their wiki-style public consultation site kept getting deleted. Turned out that GoogleBot was visiting their hidden "delete page" links...

Read More 3 comments
Comments: 3
+ -

  Journal: Safari 4 likes clicking on 2009.07.02 5:24

Journal by AndyArmstrong on 2009.07.02 5:24
Apple

Installing Safari 4 had a pretty strange effect for me: Lights in the house switched on and off at random.

It turns out that Safari likes to visit your favourite pages periodically to update its Top Sites browser. Which is fine unless some of the lights in your house are controlled by a web interface which uses GET for the light switch buttons.

Read More 3 comments
Comments: 3
+ -

  Journal: Test::Harness on Github on 2009.06.17 8:03

Journal by AndyArmstrong on 2009.06.17 8:03
Perl News

For the last few years Test::Harness has lived in subversion. Over the last couple of weeks I've been moving my modules to Github and yesterday I moved Test::Harness. You can find it here:

http://github.com/AndyA/Test-Harness/

Read More 2 comments
Comments: 2
+ -

  Comment: Good luck (Score 1) on 2009.03.20 11:20

by AndyArmstrong on 2009.03.20 11:20 (#67881)
Attached to: A New Future
Join the club - I'm doing the same thing right now. Have fun with it :)
Read More 2 comments
Comments: 2
+ -

  Comment: Yay! (Score 1) on 2009.02.09 7:19

Splendid news - see you there :)
Read More 1 comments
Comments: 1
+ -

  Comment: Presumably... (Score 1) on 2009.01.28 8:13

by AndyArmstrong on 2009.01.28 8:13 (#67061)
Attached to: Dead Babies
...because that's god's will :|
Read More 21 comments
Comments: 21
+ -

  Perl debugger: stop at a specific test number on 2008.02.28 14:48 AndyArmstrong

Submitted by AndyArmstrong on 2008.02.28 14:48
Tools
AndyArmstrong writes "I like data driven tests. The general pattern is a big array of test cases and some driver code at the bottom that loops over the cases applying the same assertions to each of them.

That's all well and good until you want to use the Perl debugger to step through test #1967 of 2673. There's no good place to set a break point because the driver loop will execute many times before it hits the test you want to single step through. You can fake it like this:

if (Test::Builder->new->current_test >= 85) {
    $DB::single = 1;
}

Setting $DB::single to a true value makes the debugger break at the following line. It'd be much nicer though to be able to set a magic breakpoint in the debugger that'd stop at test #1967. Add the following code to your ~/.perldb and that's exactly what you'll be able to do.

my @opts = qw( windowSize=30 );

if ( $] >= 5.010000 ) {
    push @opts, "HistFile='" . glob( '~/.perldb_history' ) . "'";
}

parse_options( $_ ) for @opts;

@DB::testbreak = ();

# Monkeypatch cmd_b (set breakpoint)
my $cmd_b = \&DB::cmd_b;
*DB::cmd_b = sub {
    my ( $cmd, $line, $dbline ) = @_;
    if ( $line =~ /\s*#\s*(\d+(?:\s*,\s*\d+)*)$/ ) {
        my %seen;
        @DB::testbreak = grep { !$seen{$_}++ }
          sort { $a <=> $b } ( split( /\s*,\s*/, $1 ), @DB::testbreak );
    }
    else {
        $cmd_b->( @_ );
    }
};

sub afterinit {
    $trace |= 4;    # Enable watchfunction
}

sub watchfunction {
    if ( @DB::testbreak && exists $INC{'Test/Builder.pm'} ) {
        my $next = Test::Builder->new->current_test + 1;
        if ( $next >= $DB::testbreak[0] ) {
            shift @DB::testbreak
              while @DB::testbreak && $next >= $DB::testbreak[0];

            my $depth = 1;
            while ( 1 ) {
                my ( $package, $file, $line ) = caller $depth;
                last unless defined $package;
                last unless $package =~ /^Test::/;
                $depth++;
            }
            $DB::stack[ -$depth ] = 1;
        }
    }

    return;
}

It modifies the debugger's 'b' (breakpoint) command so that you can type:

  DB<1> b #1967
  DB<1> c

That'll run the tests until immediately after test #1966 and then stop, ready for the setup to the test you're interested in. Regular breakpoints still work as normal.

It's a little rough and ready. It decides which scope to stop in by unwinding the call stack skipping past any packages that are called Test::* - if your package naming doesn't work like that you'll have to hack it about a bit.

If you have any improvements please let me know.

"
Read More 0 comments

+ -

  Journal: Perl debugger: stop at a specific test number on 2008.02.28 14:48

Journal by AndyArmstrong on 2008.02.28 14:48
Tools

I like data driven tests. The general pattern is a big array of test cases and some driver code at the bottom that loops over the cases applying the same assertions to each of them.

That's all well and good until you want to use the Perl debugger to step through test #1967 of 2673. There's no good place to set a break point because the driver loop will execute many times before it hits the test you want to single step through. You can fake it like this:

if (Test::Builder->new->current_test >= 85) {
    $DB::single = 1;
}

Setting $DB::single to a true value makes the debugger break at the following line. It'd be much nicer though to be able to set a magic breakpoint in the debugger that'd stop at test #1967. Add the following code to your ~/.perldb and that's exactly what you'll be able to do.

my @opts = qw( windowSize=30 );

if ( $] >= 5.010000 ) {
    push @opts, "HistFile='" . glob( '~/.perldb_history' ) . "'";
}

parse_options( $_ ) for @opts;

@DB::testbreak = ();

# Monkeypatch cmd_b (set breakpoint)
my $cmd_b = \&DB::cmd_b;
*DB::cmd_b = sub {
    my ( $cmd, $line, $dbline ) = @_;
    if ( $line =~ /\s*#\s*(\d+(?:\s*,\s*\d+)*)$/ ) {
        my %seen;
        @DB::testbreak = grep { !$seen{$_}++ }
          sort { $a <=> $b } ( split( /\s*,\s*/, $1 ), @DB::testbreak );
    }
    else {
        $cmd_b->( @_ );
    }
};

sub afterinit {
    $trace |= 4;    # Enable watchfunction
}

sub watchfunction {
    if ( @DB::testbreak && exists $INC{'Test/Builder.pm'} ) {
        my $next = Test::Builder->new->current_test + 1;
        if ( $next >= $DB::testbreak[0] ) {
            shift @DB::testbreak
              while @DB::testbreak && $next >= $DB::testbreak[0];

            my $depth = 1;
            while ( 1 ) {
                my ( $package, $file, $line ) = caller $depth;
                last unless defined $package;
                last unless $package =~ /^Test::/;
                $depth++;
            }
            $DB::stack[ -$depth ] = 1;
        }
    }

    return;
}

It modifies the debugger's 'b' (breakpoint) command so that you can type:

  DB<1> b #1967
  DB<1> c

That'll run the tests until immediately after test #1966 and then stop, ready for the setup to the test you're interested in. Regular breakpoints still work as normal.

It's a little rough and ready. It decides which scope to stop in by unwinding the call stack skipping past any packages that are called Test::* - if your package naming doesn't work like that you'll have to hack it about a bit.

If you have any improvements please let me know.

Read More 3 comments
Comments: 3
+ -

  64 bit Fedora Core shell account? on 2008.02.23 13:39 AndyArmstrong

Submitted by AndyArmstrong on 2008.02.23 13:39
Linux
I'm currently attempting to resolve a problem that the Red Hat folks are having with IPC::ShareLite on 64 bit Fedora Core with Perl 5.10. It's quite important; in fact it's critical to getting 5.10 on FC.

Unfortunately I don't own a 64 bit box. It seems (thanks Nicholas) that it might be possible to reproduce the problem using a Perl built with 64 bit ints on a non-64 bit platform - but I've had no luck in that direction yet and, in any case, I'd like to test on a 64 bit machine just to be sure.

Is there anyone out there in Perl land who could provide me with a temporary shell account on a 64 bit Fedora Core machine? That'd have to be someone who didn't mind me burning enough CPU cycles to build Perl 5.10 from source.

If you can help with getting 5.10 into Fedora by providing access to a suitable box please drop me a line and earn the eternal gratitude of, well, everyone really.

Thanks.

Read More 0 comments

+ -

  Journal: 64 bit Fedora Core shell account? on 2008.02.23 13:38

Journal by AndyArmstrong on 2008.02.23 13:38
Linux

I'm currently attempting to resolve a problem that the Red Hat folks are having with IPC::ShareLite on 64 bit Fedora Core with Perl 5.10. It's quite important; in fact it's critical to getting 5.10 on FC.

Unfortunately I don't own a 64 bit box. It seems (thanks Nicholas) that it might be possible to reproduce the problem using a Perl built with 64 bit ints on a non-64 bit platform - but I've had no luck in that direction yet and, in any case, I'd like to test on a 64 bit machine just to be sure.

Is there anyone out there in Perl land who could provide me with a temporary shell account on a 64 bit Fedora Core machine? That'd have to be someone who didn't mind me burning enough CPU cycles to build Perl 5.10 from source.

If you can help with getting 5.10 into Fedora by providing access to a suitable box please drop me a line and earn the eternal gratitude of, well, everyone really.

Thanks.

Read More 13 comments
Comments: 13