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."
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...
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.
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:
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.
"
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.
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.
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.
