Todd Rinaldo (t...@cpanel.net)

Do we have any documentation to this effect?

I'll start my reply by applauding who ever got site_lib put at the front of @INC. I'm glad to see this change.

I definitely think this is a game changer. Now the CPAN versions of dual core modules don't have to write to the same library tree that core installs to. This solves the packaging nightmare: overwriting files distributed with another package without conflicting with the other package.

I am however concerned that changing @INC is only half of the problem. We've got 100+ dual core modules that may need to change their Makefile.PL/Build.PL to cope with this change. And since there is no well known documentation on the topic, chances are even if we got them cleaned up, INSTALLDIRS => 'perl' is probably in other modules just out of ignorance. It occurs to me that with this change, there is no longer a good reason that someone generating an install running Build.PL or Makefile.PL without arguments should generate an install to core path. It seems like EUMM and M::B would do well to ignore INSTALLDIRS if $] >= 5.011. Both installers could flip a warning message if they intend to ignore INSTALLDIRS with some sort of "notify the author/here's how you override me if you insist on installing into perl core directories" message.

As insane as this idea might sound initially, I'd like to hear p5p's take on the idea.

A recent discussion has come up in the RT queue for Locale::Codes concerning what the install destination for dual core modules should be. If the module is not deprecated, is there any documentation on where CPAN installed dual core modules are supposed to install to?

If not, has there been any consistent policy and/or does cpan/cpanplus do any magic to make sure there is only one copy of dual core modules in the perl lib trees?

Thanks,
Todd

https://rt.cpan.org/Public/Bug/Display.html?id=54526=

Just a FYI, The following Dual core modules will install to the wrong place after 5.11 when installing them via CPAN.

This is a result of pulling them out of arch in core. I've submitted tickets to each author to suggest appropriate fixes. If anyone knows the authors, I'd appreciate them being nudged for a release.

B::Debug (COMPLETE) - https://rt.cpan.org/Public/Bug/Display.html?id=54455
B::Lint - https://rt.cpan.org/Public/Bug/Display.html?id=54453
Module::Pluggable - https://rt.cpan.org/Public/Bug/Display.html?id=54454
XSLoader - https://rt.cpan.org/Public/Bug/Display.html?id=54456

Thanks.
Todd=

--Apple-Mail-39--397705755
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii

I sent this to perlbugs 2 hours ago but there seems to be a problem. I thought I'd send it here in the mean time.


Test 24 is failing for me on some systems:

#   Failed test 'timestr ($diff, "noc")'
#   at lib/Benchmark.t line 123.
#                   ' 7 wallclock secs ( 7.03 usr +  0.04 sys =  7.07 CPU)'
# doesn't match '(?-xism:7 +wallclock secs? +\( *7.03 +usr +\+ +0.04 +sys += +7.08 +CPU\))'

The Test:
my $noc = timestr ($diff, 'noc');
like ($noc, qr/$wallclock +wallclock secs? +\( *$usr +usr +\+ +$sys +sys += +$cpu +CPU\)/, 'timestr ($diff, "noc")');

When I dig into this test, It appears that $cpu is generated from the regex by parsing the 'all' output:
my $all = timestr ($diff, 'all');
my ($wallclock, $usr, $sys, $cusr, $csys, $cpu) = $all =~ $All_Pattern;

This means that the expectation is that the CPU time for 'all' output will match the CPU time for 'noc' output.
CPU time is calculated...
for 'all': $tr->cpu_a
for' noc': $tr->cpu_p

The code to calculate the CPU for each of these is:
sub cpu_p { my($r,$pu,$ps,$cu,$cs) = @{$_[0]}; $pu+$ps         ; }
sub cpu_a { my($r,$pu,$ps,$cu,$cs) = @{$_[0]}; $pu+$ps+$cu+$cs ; }

What this means: The only way test 24 can succeed is if $cu and $cs are 0. In my case, extra diag messages show that $cu was 0.01 and this caused the test to fail.
Suggested Patch: There are no comments in the test file to indicate if we're validating formatting or the math on this. I'm inclined to go with formatting so I suggest the following patch for test 24, which will match what test 25 for 'nop' output is doing.

--- a/lib/Benchmark.t
+++ b/lib/Benchmark.t
@@ -114,7 +114,7 @@ is ($auto, $default, 'timestr ($diff, "auto") matches timestr ($diff)');
     is (timestr ($diff, 'none'), '', "none supresses output");

     my $noc = timestr ($diff, 'noc');
- like ($noc, qr/$wallclock +wallclock secs? +\( *$usr +usr +\+ +$sys +sys += +$cpu +CPU\)/, 'timestr ($diff, "noc")');
+ like ($noc, qr/$wallclock +wallclock secs? +\( *$usr +usr +\+ +$sys +sys += +\d+\.\d\d +CPU\)/, 'timestr ($diff, "noc")');

     my $nop = timestr ($diff, 'nop');
like ($nop, qr/$wallclock +wallclock secs? +\( *$cusr +cusr +\+ +$csys +csys += +\d+\.\d\d +CPU\)/, 'timestr ($diff, "nop")');



--Apple-Mail-39--397705755--