File-Rsync-Mirror-Recent
view release on metacpan or search on metacpan
path: id/J/JO/JOHND/CHECKSUMS
type: new
Dre-0:
epoch: 1237400807.97514
path: id/M/MI/MIYAGAWA/CHECKSUMS
type: new
Dre-1:
epoch: 1237400817.94363
path: id/X/XI/XINMING/Catalyst-Plugin-Compress.tar.gz
type: new
Eintervals:
-
- 900644040
- 900644040
- []
and it is reproducable.
Why does the mirrorer not fetch a newer Z file? It is 18 hours old while
pause has a fresh one.
FIXED, it was the third anded term in each of the ifs in the IV block in
_register_one: with that we make sure that we do not stamp on valuable
interval data.
2009-03-17 Andreas J. Koenig <andk@cpan.org>
* done: verified the existence of the floating point bug in bleadperl
and verified that switching from YAML::Syck to YAML::XS does not resolve
it.
BTW, the switch was doable with
perl -i~ -pe 's/Syck/XS/g' lib/**/*.pm t/*.t
and should be considered as a separate TODO
* todo: integrate a dirty update with two aggregate calls before
unlocking for frictionless dirtying DONE
* todo: start the second rsync daemon on pause DONE
* todo: move index files to .recent: this cannot simply be done by
setting filenameroot to .recent/RECENT. Other parts of the modules rely
on the fact that dirname(recentfile) is the root of the mirrored tree.
2009-03-16 Andreas J. Koenig <andk@cpan.org>
* What was the resolution of the mirror.pl delete hook bug? Do we call
the delete hook when pause removes a file from MUIR?
* Today on pause: Updating 2a13fba..29f284d and installing it for
/usr/local/perl-5.10.0{,-RC2}
TURUGINA/Set-Intersection-0.01.tar.gz was the last upload before this
action and G/GW/GWILLIAMS/RDF-Query-2.100_01.tar.gz the first after it
2009-03-15 Andreas J. Koenig <andk@cpan.org>
* currently recent_events has the side effect of setting dirtymark
because it forces a read on the file. That should be transparent, so
that the dirtymark call always forces a cache-able(?) read.
* The bug below is -- after a lot of trying -- not reproducible on a
small script, only in the large test script. The closest to the output
below was:
#!perl
use strict;
use Devel::Peek;
my $x = "01237123229.8814";
my($l,$r);
for ($l,$r) {
$_ = "x"x34;
}
($l,$r) = ($1,$2) if $x =~ /(.)(.+)/;
$r = int $r;
$l = "1237123231.22458";
$r = "1237123231.22458";
1 if $l/1.1;
Devel::Peek::Dump $l;
Devel::Peek::Dump $r;
Devel::Peek::Dump $x = $l <=> $r;
die "BROKE" if $x;
__END__
The checked in state at c404a85 fails the test with my
/usr/local/perl-5.10-uld/bin/perl on 64bit but curiously not with
/usr/local/perl-5.10-g/bin/perl. So it seems the behaviour is not even
in the test script always consistent.
* Todo: write a test that inserts a second dirty file with an already
existing timestamp. DONE
* Bug in perl 5.10 on my 64bit box:
DB<98> Devel::Peek::Dump $l
SV = PVMG(0x19e0450) at 0x142a550
REFCNT = 2
FLAGS = (PADMY,NOK,POK,pNOK,pPOK)
IV = 0
NV = 1237123231.22458
PV = 0x194ce70 "1237123231.22458"\0
CUR = 16
LEN = 40
DB<99> Devel::Peek::Dump $r
SV = PVMG(0x19e0240) at 0x142a3e8
REFCNT = 2
FLAGS = (PADMY,POK,pPOK)
IV = 1237123229
NV = 1237123229.8814
PV = 0x19ff900 "1237123231.22458"\0
CUR = 16
LEN = 40
DB<100> Devel::Peek::Dump $l <=> $r
SV = IV(0x19ea6e8) at 0x19ea6f0
REFCNT = 1
FLAGS = (PADTMP,IOK,pIOK)
IV = -1
( run in 0.826 second using v1.01-cache-2.11-cpan-c966e8aa7e8 )