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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Those who don't take reality into account make up laws instead and then kick people in the head for not following them
    • I'll put you on the "pro" side of literal tabs in Makefiles then, and five years of completely broken Scalar::Util in ActivePerl.

      • How is Scalar::Util broken in ActivePerl it is (at least supposed to be) the same as in core Perl.
        • As I understand it, it doesn't include (all of?) the XS components of the module, making reftype() unavailable for the ActivePerl 5.8.x releases.

          The explanation I heard (and I don't remember where, though I'm pretty sure it wasn't from you) is that one goal of the ActivePerl releases for 5.8.x was to maintain binary compatibility back to 5.8.0, and thus there would be no reftype() available for Scalar::Util.

          When I last looked at which of my distributions failed in the AS build and test farm, most of the

          • You might have heard it from me, although I'm not sure it was (only) reftype()... might also have been weaken().

            ActivePerl on Windows maintains binary compatibility, and it does so for business reasons.

            As a result Scalar::Util, and hence all interesting packages (as in like 40% of all CPAN modules) are broken on ActivePerl, and can't be fixed for business reasons.

            This is why I never got to demo PPI on my own laptop at the Perl Conference the year I want, which triggered off a year-long attempt to get them to fix it, at the end of which (when they said they intentionally wouldn't be fixing it for business reasons flat out) I gave up on ActivePerl and started the process that resulted in Strawberry Perl as a replacement for it.

            But yes, I agree to some extent with chromatic on this one.

            That said, I think you sometimes go too far in the other direction as well. It can be very tempting to say, "Screw the entire userbase, we're changing the way this works".

            When the userbase is 12, who cares, when it's 12,000 or 12,000,000 that's an entirely different matter.
            • If you’re building something important, 12,000 is still not very big.

              Of course it’s hard to assess ahead of time whether 12,000 is small or big in one’s particular case…

            • When the userbase is 12, who cares, when it's 12,000 or 12,000,000 that's an entirely different matter.

              My objection is when the best (and sometimes only) argument is "We can't change because people are already using it!" That argument was rubbish back when make had 12 users, and it's rubbish now when the proposed change improves the lives of many times more users.

              In ten years, see if fervent adherence to backwards compatibility killed Perl 5 in 2002.

            • 12,000 is the number of downloads of ActivePerl for Windows every 2-3 days (downloads for other platforms are significantly lower). Which is why breaking backwards compatibility in the PPM repository is a big deal.

              Of course all of these issues are really just pointing out faults in the original setup of the PPM and build farm infrastructure. Unfortunately it is a lot of work to get it cleaned up. We are currently testing adding additional repositories that are built with 5.8.8. We have already changed t