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 ]

drhyde (1683)

drhyde
  (email not shown publicly)
http://www.cantrell.org.uk/david

Journal of drhyde (1683)

Tuesday September 30, 2008
06:21 PM

CPANdeps can now ignore developer builds of perl

The CPAN-testers sometimes use developer releases of perl. This helps in two ways. First of all, it notifies authors of things that might be about to change in the next stable release of perl so that they can fix them before real users are effected. Second, it helps find freshly created bugs in bleadperl. But ordinary users don't care about that, as they only use stable releases. And so CPANdeps has grown a new feature. As well as filtering to only look at results for a particular version of perl, you can also filter to only look at stable releases. This is the default setting. If you want to include test results from developer releases of perl, you need to explicitly turn that on.

This is subtlely different from just selecting a version of perl. If you choose 5.8, for example, you would get test results from the unstable 5.8.9-to-be as well as the ones that you actually care about. If you choose 5.10.0, you would get test results for 5.10.0-patch-12345 which was very shortly before the stable release.

Also please note the new canonical hostname for CPANdeps, deps.cpantesters.org. This, and the fact that the source code is available, means that when I eventually lose interest, someone else can take over maintenance.

Wednesday September 10, 2008
10:43 AM

Bits of Bryar are going away

If anyone here is using the Bryar blogging tool, originally written by Simon Cozens and now maintained by me, and has any objection to me deleting the following components, please yell now!

  • mod_perl support
  • DBI support
  • Flatfile::Dated

I have decided to clear out a load of dead code. mod_perl support isn't maintained anyway. I have decided that DBI and Flatfile::Dated are dead because:

  • I don't use them
  • there are no tests for them

This is as part of a big clean-up which will also include making sure that there is adequate test coverage.

Thursday September 04, 2008
05:06 PM

Keeping things in perspective

There's been lots of kerfuffle recently about the CPAN-testers. Two people in particular have been complaining very loudly. A tiny number of other people have chimed in briefly alongside them.

Genuine problems have been identified, and either fixed quickly or at least a plan to fix them in the long term has been explained. And yet the loud complaints continue.

I wonder what those people expect. As far as I'm concerned, having half a dozen out of nearly 7000 "customers" complain demonstrates that the sky isn't falling in. Doubly so when you count the number of people who write to testers to thank them for their work. Why, I'd need to take my socks off to count all those who have told me that what I'm doing is useful and that they're grateful for it!

Given humans' tendency to only speak up when they don't like something and to keep schtum when they're happy (just look at any restaurant review site that lets the hoi polloi post!), I think that shows that we're both getting it right almost all the time, and providing a useful service.

Even so, let me reiterate here what I've said elsewhere - if any of you don't want me to send you reports, please email me to let me know.

Thursday July 24, 2008
11:36 AM

Segfault! Panic!

Oops, I made perl segfault. All I was trying to do was assign a closure (which in turn calls another closure, which ...) to a typeglob. It's especially irritating to me because this happens in 5.8.8 but not in 5.10.0, and happened right after I'd advised someone on IRC to avoid 5.10 until 5.10.1 came out* :-)

The only reason I needed to assign my code to a typeglob is because I need a subroutine name so I can use it to sort by. It would really help if sort would take a subroutine reference but it doesn't it takes a block or a subroutine name. Grump.

Interestingly, if I twiddle things around a little bit, (eg adding a completely unrelated Data::Dumper::Dumper call) the segfault is sometimes there sometimes not. Sometimes I get "panic: memory wrap", sometimes a segfault, sometimes both, and sometimes "Bizarre copy of ARRAY in aassign at .../Test/More.pm line 795". Yay Heisenbug!

* I've got no particular reason for that, other than the usual paranoia about .0 releases of any software

Tuesday July 22, 2008
10:07 AM

Come on VAX-herders!

Yesterday, GNU HURD overtook VMS in the CPAN-testers league table ...

> select count(*) c, os from cpanstats group by os order by c desc;
...
136,'OSF'
87,'AIX'
68,'Dragonfly BSD'
19,'BSD OS'
18,'OS/2'
10,'GNU Hurd'
8,'VMS'

So come on VAX-herders! Your honour is at stake! The OS/2 crowd had better watch out too. Loyal IBM corporate drones should be ashamed to be almost caught up by the smelly GNU hippies!

Friday July 18, 2008
08:47 AM

CPU::Z80::Assembler is all grown-up now

After I wrote CPU::Emulator::Z80, I needed an assembler so I could do anything with it. Rather than use any of the pre-existing ones, I thought it would be a good idea to write one in perl. So I did, and the ugly hack that was CPU::Z80::Assembler version 1 was the result. And boy is it ugly.

I wasn't really expecting anyone to use it other than myself, but Paulo Custodio did, and he found bugs, and he sent patches, with tests. He suggested some other improvements too, and I handed over maintenance to him. Version 2 gone done grown up, with a real lexer/parser, proper #include files and everything.

I'm very grateful.

Monday May 12, 2008
12:51 PM

CPANdeps can now highlight non-perl dependencies

At the user's request, CPANdeps has sprouted another tentacle. There's now a ticky box which, if enabled, makes it also fetch MANIFEST files for the entire dependency tree, and highlight any modules (actually distributions) that don't look like they're pure perl. The heuristic is simple. We assume that a distribution is pure perl unless it contains a file that ends in .xs, .c or .h, or it depends on Inline::*. But if there is any file in the distro whose name contains the string 'pureperl' (case-insensitive, naturally), then we assume that the distribution contains a pure perl version as well as the C-ish version.

If there's any other things I should look for, please use the "report bugs" link on the website.

Wednesday April 02, 2008
07:20 PM

CPANdeps downtime

My apologies for the recent downtime on CPANdeps - it's Yahoo's fault. Their web crawler suddenly stopped obeying robots.txt, and so tried to spider all of the CPAN's dependencies. And on top of that, they're making requests every few seconds instead of every few minutes like a good robot should. Given that it takes more than a few seconds to generate the dependency tree, things went pear-shaped. Arseholes.

They're now banned with a mod_rewrite rule, and just for good measure I've limited the number of concurrent webby requests.

Saturday February 23, 2008
10:16 AM

How useful closures are!

As some of you may be aware, I'm working on a pure-perl Z80 emulator. Why? <shrug> Why not! And we can't go letting the 6502 boys have all the fun!

It also makes a very good example of how useful closures can be. Here's just one example.

The Z80 is an 8 bit processor, with several 8 bit registers. But it also has some 16 bit "reigster pairs", which are made up of two 8 bit registers that can be treated as a single larger register. For example, the 8 bit register B and C can be combined to make a 16 bit register BC. Any operation that changes B or C also changes BC, and vice versa. Now, to implement them, I could have lots of hairy logic so that any instruction that operates on BC actually operates on both B and C. But that would lead to lots of duplication of code, for all the register pairs, and for all the instructions that operate on 'em.

I already have a ::Register8 class for an 8 bit register, and a Register16 class for real 16 bit registers such as the Program Counter (a register that points at the next instruction to execute) which store a value and have get() and set() methods. So, I thought, instead of putting lots of hairy logic in the instructions themselves, I could move it into the registers so I'd only have to write it once. The Register* classes already have a 'value' field for storing the register's current value. So I changed Register16 to have either a value field or a pair of 'get' and 'set' fields, depending on how the register was initialised in perl. If it has a value field, then get() and set() simply operate on that. But if instead it has get/set fields, then get() and set() call those code-refs instead.

So now, I can create a 16 bit register pair like this ...

my $BC = CPU::Emulator::Z80::Register16->new(
  get => sub {
    return 256 * $self->register('B')->get() +
                 $self->register('C')->get()
  },
  set => sub {
    my $value = shift;
    $self->register('B')->set($value >>8);
    $self->register('C')->set($value & 0xFF);
  }
);

and then as far as implementing the actual Z80 instructions goes, I can just get() and set() sixteen bit registers with a single method call, instead of doing all the multiplication, shifting, bitmasking and so on every time. Note that I use a variable $self inside the two anonymous subroutines without declaring it with my. This isn't a bug. That is the $self in the code that creates the anonysubs. It has nothing to do with whatever $self might be inside a Register16 class's get() or set() method.

But there are actually several register-pairs, so I went one step further. Instead of repeating that chunk of code several times, once for each pair, I did this:

$AF = _derive_register16($self, qw(A F));
$BC = _derive_register16($self, qw(B C));
$DE = _derive_register16($self, qw(D E));

...

sub _derive_register16 {
  my($self, $high, $low) = @_;
  return CPU::Emulator::Z80::Register16->new(
    get => sub {
      return 256 * $self->register($high)->get() +
                   $self->register($low)->get()
    },
    set => sub {
      my $value = shift;
      $self->register($high)->set($value >>8);
      $self->register($low)->set($value & 0xFF);
    },
  );
}

In this case, I pass $self and the names of two 8 bit registers to the _derive_register16 function. That function then creates and returns a Register16 now "closing over" 3 variables.

Closures rock. By combining objects and closures I have ended up writing a lot less code. And by reducing the amount of duplication in my code, when I inevitably find a bug, I'll have just one place to fix it, instead of having to remember all the hundred places where I twiddle register pairs. If you ever find yourself writing the same code over and over again just with minimally different data, this is a useful technique.

You can see what I'm up to on this project by looking at the CVS repository.

Friday January 18, 2008
06:34 AM

What I want in 5.12

I want Lchown to go into the core.

Unfortunately, I can't justify it. Well, I can. It would help to get rid of one of the more commonly asked questions on the rsnapshot-discuss mailing list. But really, that's not reason enough to bloat the core even more.