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
It would really help if sort would take a subroutine reference but it doesn't it takes a block or a subroutine name. Grump.
Thankfully, you're wrong. sort is happy to take a code ref.
@x = 1
.. 20;
$bynumdesc = sub { return $b <=> $a };
$\ = "\n";
print for sort $bynumdesc @x;
That definitely would appear to work, correctly printing the numbers from 1 to 20 in reversed order, on any perl I throw it at, from 5.6.1 to 5.10.0.
Re:sort with code ref
drhyde on 2008-07-25T12:16:37
Hmmm, interesting. It takes a coderef if that coderef is stored in a variable, but not just a plain old code-ref, or one returned directly from a function. I suppose it's not entirely unreasonable for the parser to get a bit confused in that case.Re:sort with code ref
Aristotle on 2008-07-25T14:38:13
Yeah, the
sortfunction has a bunch of terrible, horrible, awful special cases in place that are supposed to DWIM but end up surprising me much of the time I usesortotherwise than by passing an explicit, inline comparator block.
