in reply to perl 5.12 BSD portability (CPAN test result)...print

I'm guessing that the test harness is calling print, but "print" in class IO::File

The error is being triggered by line 119 of lib/P.pm. That line is: 
$fh->print ($res . (!$ctx ? "\n" : "")  );

[download]
and apparently $fh is an IO::File object ... in other words, you've just called object method "print" on an IO::File object. Is that what you intended ?
Anyway ... hence tobyink's suggestion.

It all looks very weird to me - I can't see how $fh has come to be an IO::File object in the first place.
And it's rather odd for a test suite to be doing anything with lib/P.pm - normally the test suite would be using the P.pm that has been put into blib.

The module also fails to pass its test on Windows. I'm guessing you already know that (as that test suite does some things that simply won't work on Windows).

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: perl 5.12 BSD portability (CPAN test result)...print
by perl-diddler (Chaplain) on Mar 10, 2013 at 12:29 UTC
    Why only on BSD and only on P5.12?

    Windows...yeah...not interesting fail...missing utils, so some win-specific hack there.

    but the fail on 512/Bsd and not linux and not 514 or 516 -- previous report had many more fails on other clients... that only this one is causing probs -- what is diff about this combo? That's what's stumped me...

    Have no easy way to test this on a BSD5.12 system though and am not sure if a change like above wouldn't cause probs on other systems.

    . As for $fh... P takes 'globs'. or IO handles. Does that answer your Q?
    ----
    later

    If I added IO::Handle/IO::File... and if that worked, it would seem to indicated that IO::Handle doesn't have an @ISA relation with IO::Handle. How likely is that on 1 platform?

[reply]

      CPAN test reports are like money - 95% of it is controlled by just 5% of the population (or something like that).

      There are a small handful of individuals who submit a vast number of CPAN test reports. Check the failure reports you are getting - are they all from the same person? If so, perhaps their system is configured unusually.

      Otherwise, I'd personally just document the problem and then forget about it. Something like:

      =head1 BUGS

The test suite fails in Perl 5.12 on BSD operating systems.
Upgrading to Perl 5.14 or above should solve this problem.
Patches to fix the issue would be joyfully accepted.

      [download]

      PS: for a hint about why this bug doesn't affect 5.14 and above, see Unexpected behavior of function 'say'.

      package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
[reply]
[d/l]
[select]
        Funny you should mention that example.

        I was pokin' at the code and though, well, maybe I should try 

        print $fh [rest of print line]

        [download]
        It seems with 'say', the above form worked, while the 'preferred' (hmmm) "$fh->say" did not..?

        BTW, FWIW, I'd really hate to put in a BUGS section like that indicating that they'd have to upgrade just because of my module. If I did have to put in a section like that, I'd like to point them to a perlbug# specific for their version & platform -- but that still would beg the question, "why BSD and not linux"? On the level that I'm using perl, they should be identical. If the 5.12 version of perl on BSD was miscompiled, I'd think that would be fixable, no?

        For windows, am wondering if I should just skip those tests that won't work? The execute test on lib/P.pm... yeah, that would be skippable, but the other test is testing the ability to print directly *from* a file descriptor. I think that should work on windows if I write a tiny perl-prog to emulate the function(s) of cat & rev. I.e. its a corner case that's not really worth the effort, but it would probably be the "right thing to do"...;^/

[reply]
[d/l]

In Section Seekers of Perl Wisdom