in reply to Re: Unexpected behaviour with PERL5OPT
in thread Unexpected behaviour with PERL5OPT

So, the answer is no ...

Yeah ... I was looking for a way of ensuring that whenever perl was run, then a specific module would be loaded before all other modules.
I was hoping that loading that module at the beginning of perl5opt would achieve that end, but now I see that alone is not guaranteed to work.

Actually, I was just wanting Test/Builder.pm to load Math/Ryu.pm (if Math::Ryu was installed).
The usual way to do that would be to have Builder.pm do eval{require Math::Ryu} but that causes t/Legacy/dont_overwrite_die_handler.t to fail a test (in the Test::Simple test suite) if Math::Ryu was not found.
Seems a funny thing to be causing a test to fail - but if they're testing for it, then one assumes it's important. (Shrug.)

So the next approach was to have Builder.pm check whether "Math/Ryu.pm" was in %INC ... and that's where it became important that Math::Ryu (if available) was loaded before Test::Builder.
Maybe that can be done simply enough ... but there's a few "what-ifs" to process when thinking through that.

And it's just an exercise that's not really going to lead anywhere.
Test::More can throw out some really stupid and irritating diagnostics like: 
>perl -MTest::More -le "cmp_ok(0.1 ** 2, '==', 0.01, 'T1'); done_testi
+ng();"
not ok 1 - T1
#   Failed test 'T1'
#   at -e line 1.
#          got: 0.01
#     expected: 0.01
1..1
# Looks like you failed 1 test of 1.

[download]
So I've patched Test/Builder.pm to be (eg) capable of providing: 
>perl -MMath::Ryu -MTest::More -le "cmp_ok(0.1 ** 2, '==', 0.01, 'T1')
+; done_testing();"
not ok 1 - T1
#   Failed test 'T1'
#   at -e line 1.
#          got: 0.010000000000000002
#     expected: 0.01
1..1
# Looks like you failed 1 test of 1.

[download]
I'll submit a PR when (if) I get the detail of involving Math::Ryu reliably sorted out.
But this irritating Test::More behaviour crops up only rarely, and no-one cares about it, anyway.

hippo, thanks for digging up the documentation.

Cheers,
Rob

Replies are listed 'Best First'.
Re^3: Unexpected behaviour with PERL5OPT
by choroba (Cardinal) on Oct 25, 2024 at 07:25 UTC
    If you compare floats in a test, you should compare for "close enough", not ==. See float in Test2::V0​.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
      If you compare floats in a test, you should compare for "close enough", not ==.

      If that's universally true, then Test::More should throw an exception whenever 2 NVs are compared for equivalence.
      Your assertion is not even generally true - though there are times when it may be deemed more appropriate to compare approximations.
      Anyway, I'm nearly a grown-up now, so I'll be the one who decides what and how I should and shouldn't compare.

      I've no objection that the following test fails: 
      >perl -MPOSIX -MTest::More -le "cmp_ok(1.4/10, '==', 0.14, 'division')
+; done_testing();"
not ok 1 - division
#   Failed test 'division'
#   at -e line 1.
#          got: 0.14
#     expected: 0.14
1..1
# Looks like you failed 1 test of 1.

      [download]
      In fact it should fail and I expect it to fail.
      But I object to being told that the 2 values are not equivalent because they're identical. WTF??
      That is never going to be helpful information.

      With my patched Builder.pm (and Math::Ryu installed), the above one-liner produces: 
      >perl -MPOSIX -MTest::More -le "cmp_ok(1.4/10, '==', 0.14, 'division')
+; done_testing();"
not ok 1 - division
#   Failed test 'division'
#   at -e line 1.
#          got: 0.13999999999999999
#     expected: 0.14
1..1
# Looks like you failed 1 test of 1.

      [download]
      which actually tells us what the 2 values were.
      It's a pretty rare scenario. The only recent example I have that turned up in the wild is from https://github.com/Perl/perl5/issues/22463: 
      not ok 40 - tan(1) == -tan(-1)
#   Failed test 'tan(1) == -tan(-1)'
#   at ext/POSIX/t/math.t line 52.
#          got: 1.55740772465490223050697480745836
#     expected: 1.55740772465490223050697480745836

      [download]
      Usual practice seems to be that "-tan(-1)" is mostly calculated as "tan(1)", and that would mean that the test should pass by tautology (as it usually does).
      It was surmised that a different process, which would allow for a small discrepancy, was being followed in this particular failure.
      Again, my objection is not that it failed, but that it's claimed that the 2 values were deemed non-equivalent yet identical.
      If the "surmising" was correct, then my patched approach would have presented: 
      not ok 40 - tan(1) == -tan(-1)
#   Failed test 'tan(1) == -tan(-1)'
#   at ext/POSIX/t/math.t line 52.
#          got: 1.55740772465490223050697480745836023
#     expected: 1.55740772465490223050697480745836081

      [download]
      I'll post again to this thread with a link to the Test::Simple PR once I've submitted it.

      Cheers,
      Rob
[reply]
[d/l]
[select]
        You are right (and in fact, I expected such an answer, especially from you).

        Interestingly, the error exists in Test2::V0​, too, where the output of failed tests is "more friendly": 

        perl -wE 'use Test2::V0; plan 1;cmp_ok 1.4/10, "==", 0.14, "same"'
# Seeded srand with seed '20241025' from local date.
1..1
not ok 1 - same
# Failed test 'same'
# at -e line 1.
# +------+----+-------+
# | GOT  | OP | CHECK |
# +------+----+-------+
# | 0.14 | == | 0.14  |
# +------+----+-------+

        [download]

        map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
[select]
[reply]

In Section Seekers of Perl Wisdom