I was surprised by my test results on Travis-CI, where my module failed on 5.16, 5.18, and 5.20, but not on the versions above or below those.

Doing some digging, it's because of the way that stat works on an in-memory filehandle: on most versions, it gives a warning in the unopened subcategory of the io warnings category, so I set up my module to trap on that warning, and die with a more meaningful message to the end-user, which should help them avoid the problem. But when it ran on multiple versions on Travis-CI, I found that 5.16-5.20 apparently do not give that (or any) warning, but still result in the empty list for the in-memory filehandle.

The issue can be simply replicated with the one-liner SSCCE (shown in both windows/berrybrew and linux/perlbrew) in the spoiler below.

I found a workaround (see second spoiler below), but I was curious, so I skimmed the perldelta for 5.16 and 5.22, but couldn't find a mention of the unopened-filehandle warning changing in either of those versions. So I guess the wisdom I am seeking: does anyone have insight as to why the warning disappeared in 5.16, but came back in 5.22? Was it intentional (and if so, why try removing it, and why re-instate it)? Or was it an accidental bug (if so, why wasn't it mentioned, or did I just not notice)?

*workaround =

And thank you: while working on the earlier issues -- figuring out that in-memory filehandle's don't stat right, but give the misleading "unopened filehandle" warning, even though Scalar::Util::openhandle() shows it as open; and trying to get the __WARN__ handler correct -- I thought I was going to need to SoPW, but developing a SSCCE showed me the problem. So thanks for the Rubber duck that you didn't even know you provided, too. :-)

SUMMARY:

I had difficulty trying to install WWW::Mechanize::Chrome on Windows Strawberry Perl. In the end, running the code from the synopsis seems to work, so I think it's been sufficiently installed. However, with the difficulties I encountered, I had some questions or discussion points to bring up:

1. Do others have this much difficulty installing it on Windows?
2. Is there a sequence that works to reliably install it on Windows (preferrably with cpanm) without resorting to multiple attempts, and --force? Does my detailed description below provide enough to give hints, if I'm just doing something wrong
3. Does corion know that the cpantesters results "lie" about a successful windows install, due to not finding chrome.exe? Is there a way to make chrome.exe a prereq, so that cpantesters reports will be more useful
4. is the failure i found in t/51-mech-links.t real, or an artifact of my problematic install? If it's real, is it a bug in the test suite, or a bug in the module itself?
5. If my failures end up being invalid, is there a way to delete/override the failing reports to cpantesters? (added)

TL;DR:

My first attempt to install WWW::Mechanize::Chrome (using cpanm) failed bunches of pre-reqs. Multiple attempts on the prereqs got most working. In the end, the only two pre-req failures were AnyEvent and Log::Log4perl. The latter was a known issue (https://rt.cpan.org/Public/Bug/Display.html?id=120926), so I forced that install, because it's not a module-functionality issue

AnyEvent only fails t/81_hosts.t -- it seems to not be doing what was expected with the PERL_ANYEVENT_HOSTS temporary hosts file; I verified the temp file was created correctly, and populated as t/81_hosts.t implies it should... so I'm not sure whether there's a bug there, or what. I did a --force (for now), because I wasn't sure whether WWW::Mechanize::Chrome would depend on that feature or not. My cpantesters report is at http://www.cpantesters.org/cpan/report/500da4bb-75df-1014-a202-c39384fafcb3

After that, cpanm WWW::Mechanize::Chrome still failed, and I propagated that report to cpantesters: http://www.cpantesters.org/cpan/report/72e85fc1-75e8-1014-b1ad-07b284fafcb3. As the report shows, I'm on Windows with strawberry perl 5.28.1 (x64), with chrome.exe v71.0.3578.98. It's failing t/51-mech-links.t -- finding 3 links instead of expected 2

I was surprised I had so much difficulty, because the http://fast-matrix.cpantesters.org/?dist=WWW-Mechanize-Chrome%200.27 showed all passes under Windows (until my report, which was the first 5.28.1 on windows)... but when I dug into them, it's because none of them had chrome.exe

After I did a --force install, I was able to run the synopsis:

    #!/usr/bin/env perl
    use 5.012;
    use warnings;

    use Log::Log4perl qw(:easy);
    use WWW::Mechanize::Chrome;

    Log::Log4perl->easy_init($ERROR);  # Set priority of root logger t
+o ERROR
    my $mech = WWW::Mechanize::Chrome->new();
    $mech->get('https://google.com');

    $mech->eval_in_page('alert("Hello Chrome")');
    my $png= $mech->content_as_png();
[download]

so for the t/51-mech-links.t, I don't know whether that's a bug in the test suite, or in the actual module itself (or whether my earlier difficulties during the install process made something unstable for that test)

edit 1: fix typo in title

edit 2: add the fifth question in the SUMMARY

Given the pretty CPAN Testers Christmas Tree, especially in the *BSD columns, I learned that not all 32-bit perls are created equal. After some more debug, I was able to show that it was those 32-bit perls with $Config{ivsize}==4 (32bit integers; aka perl -V:ivsize) that were failing, but those with $Config{ivsize}==8 (64bit integers in 32bit perl) would pass.

I had assumed (without looking) that the default ivsize on the 32bit perl was 4 bytes (32 bits), so thought that I had already tested and verified my IV weren't overflowing (or, if they were, they were promoting to NV). After seeing the problem, I discovered that when using left-shift, it would go from IV to NV... but it didn't. However, *=2 did promote the way I expected:

Conclusion: when doing a testing suite across versions, it's not always enough to just have a "32bit perl"; especially if you are dependent on integer sizes, also check that your test suite includes multiple ivsize values.

I am playing around with DBD::mysql (MySQL v5.6) and perl, experimenting with stored procedures and functions, which I've never used before. I see that there is the ability to make an OUT parameter to the procedure. How do I access that from perl?

Is this possible? Or will I have to use other methods (like a stored function return-value, or a procedure with multiple result sets)?

Regarding the executable-test -x, perlport says:

-x (or -X) determine if a file ends in one of the executable suffixes. -S is meaningless. (Win32)

Where are the "executable suffixes" defined for Win32 perl (strawberry, in my case)? If anything, I would have expected $ENV{PATHEXT}, because that's the closest related idea to "executable" on windows (or possibly the assoc and ftype and their underlying registry entries -- though that's more complicated). However, I've got ".pl" in my PATHEXT variable and properly associated in the registry, but -x "$0" results in a false value (undef). I also tried with a .js file, which is in the Windows-default PATHEXT, but it shows up as non-executable as well. I've experimentally found that .com, .exe, .bat, and .cmd all show up as executable... but none of the others in the default PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

--

context: after reading Re^2: how do i run a shell command without waiting for the output, I looked at Proc::Background, and saw that commands were "checked by appending `.exe' to the name in case the name was passed without the `.exe' suffix". Since ".exe" isn't the only extension dropped on Win32 (PATHEXT defines the extension-omission properties for Win32, and .bat is frequently untyped as well), I wanted to suggest a bugfix to allow any extension from PATHEXT: change the hardcoded push(@extensions, '.exe'); to push @extensions, split(/;/, $ENV{PATHEXT} || '.exe');. However, while testing my change against various extensions (explicit or omitted-but-implied), I found that Proc::Background wasn't getting as far as using the @extensions array, since -x was failing. I found the quoted perlport description that Win32 -x has a list of extensions, but I haven't found the official documentation for what that list is (and really, if there's any hardcoded list embedded in the perl ports to Win32, I disagree with them on the same grounds that I disagree with Proc::Background)

edit: add <readmore> tags...

how do you set binmode for the input and output of a perl -pi script.pl *.file in-place edit? I had hoped by doing binmode ${^LAST_FH}; binmode STDOUT;, that would cover it...

I've gotten the input as close to binmode as I can, in that for the sample input above, the sum of the lengths of $_ totals 61, which matches that example input. But putting binmode STDOUT in either the BEGIN, the main, or both, does not seem to help the output file be the same length. I tried perl -C0 -pi... (from perlrun), hoping to make it all :raw equivalent, but with no change. I looked thru perlvar to try to find an output-equivalent of ${^LAST_FH}, but didn't see anything.

In the end, I'll probably just stop trying the magic perl -pi and make a manual in-place loop, where I open the ARGV input and output handles myself, so I have full control. But after this much investigation, I'd really like to find out if it's possible to make the whole in-place pipeline binmode.

ps: No, converting 'w' to 'v' is not my end goal :-). I just used that as a SCCE to show the basic problem binmode issue: I want to be able to do all my working (where my actual manipulations will preserve byte-length) without changing the EOL-like characters for this binary file.

So, I started playing around with threads, using Re: buffering zipped pipes as an example. I got something working on my Windows machine, then tried it out on the ancient linux box (perl 5.8.5)... and got the dreaded "A thread exited while 2 threads were running."

I double-checked to make sure that the linux box's perldoc threads claimed support for ->detach, and the WARNINGS section suggested joining to remove the error. I thought ->detach was supposed to make it automatically clean up such stuff.

I tried no warnings 'threads'; or even no warnings;, just to see if I could make the warning go away, but it stuck around.

Given the details (below), how can I get around this warning? Can I install a new local version of threads on the linux machine (I have cpan set up for local library installs), or is threads too core to be able to update with cpan? Or should I just switch to not using ->detach, and do manual cleanup using ->join?

tl;dr details follow...

How do you go about debugging failures from CPAN Testers when your own configurations are not failing? I'd like advice, both in general, and anything you see in my specific examples below.

For example, this test matrix has a bunch of failures -- but when I test on my machines, I cannot replicate the errors they are getting.

Before releasing, I tested on a couple of different versions I have access to (strawberry perl 5.24.0_64 on Win7 and an ancient CentOS 4.6 linux 2.6.9-55 with perl 5.8.5), and neither failed my test suite. And since I've seen the CPAN Testers failures, I've started increasing my berrybrew installations to improve version coverage -- but so far, they've all passed, even when they've been on Perl versions that failed in the linux column.

After I've exhausted available Strawberry installations, I will probably grab one of my linux virtual machines and start increasing perlbrew installations, and run through as many as I can there (I cannot install perlbrew or other local perls on the CentOS machine I noted, due to disk restrictions). But even with trying a new slew of versions, I cannot guarantee that I'll see the same failures that CPAN Testers is showing me.

I know where I'll be looking for the specific errors: my expected values are wrong; the expected values were being generated by functions I thought were fully tested earlier in my test suite, so I'll have to look into that some more, and also see if maybe I should independently generate the expected values.

But if I cannot replicate the exact failures from CPAN Testers, it's going to be harder to know I've solved the problem. When doing my last release to add features, I ended up submitting beta versions to CPAN, with extra debug printing, and waiting overnight while the CPAN Testers ran, then basing my fixes on changes in those results. But that's a rather slow debug process... and I noticed that every submission, I was getting fewer results from TESTERS: I think some of those auto-testers have some sort of submission limits, or otherwise remember that a particular module fails and stops testing new versions.

Any advice, generic or specific, would be welcome.

Harkening back to my experiments to make an Expand.pm to interpret IEEE754 doubles, I found when making my tests that as I converted a signaling NaN bit string into a double then back to the bit string, it became a quiet NaN. At first I thought I just had a bug in my conversion, so then I tried BrowserUK's code from Re^2: Exploring IEEE754 floating point bit patterns., along with a new function to convert it back.

outputs

... ie, it fails on just the signaling NaN, appearing like a quiet NaN bitstring.

I tried under an ancient CentOS 4.6 perl 5.8.5, and under a recent Strawberry 5.22.1 32bit, and get the same quieting of the sNaN. Am I doing something wrong, or does perl just automatically quiet signalling NaN values?

Fellow Monks, when I released Games::Literati 0.032, I discovered the hard way (thanks, CPAN Testers) that in-memory files are not compatible with Perl 5.6. The module itself doesn't use in-memory files, but part of my test suite did. So I reworked the test suite to not use in-memory files. I then found Perl::MinimumVersion 1.38, and ran perlver on my module and test files, and all claimed to be Perl 5.6.0 compatible. However, when I released Games::Literati 0.040, I was surprised to see CPAN Testers flag me for failure when tested under Perl 5.6.2. :-(

tl;dr summary

1. What Perl version introduced open() using '<&'? I know that by 5.8.5, it works, and apparently it doesn't in 5.6.2.
2. Should I consider it a bug in Perl::MinimumVersion 1.38 that perlver claimed my test suite was compatible with 5.6.0?
3. Should I just skip the portions of my test suite that require the '<&'? Or should I try to find an alternate?
4. Easy way to get 5.6.0 on Windows? (Alternately, pre-made virtual machine with 5.6.0?)

tl;dr details