slice.t failures on i386
Closed this issue · 8 comments
The Debian package build for PDL 2.086 failed to the test failures on i386:
# Failed test 'col=0'
# at t/slice.t line 386.
# got=[40304.223832962 -58824.066795614 -39106.2238340502 60022.0667967021]
# Failed test 'col=1'
# at t/slice.t line 387.
# got=[60122.0667963341 40404.2238338057 -58724.0667967926 -39006.2238333472]
# Looks like you failed 2 tests of 602.
Full buildlog: https://salsa.debian.org/perl-team/modules/packages/pdl/-/jobs/5528286
This issue affects all 32-bit architectures, see:
http://www.cpantesters.org/cpan/report/26821c66-f085-11ee-80b5-171869899e9e on i686-linux gets similar to yours, but different numbers:
# Failed test 'col=0'
# at t/slice.t line 386.
# got=[-179.437743848642 261.844797897898 -99.7684073347682 2413.36135328551]
# Failed test 'col=1'
# at t/slice.t line 387.
# got=[110.89635677454 -504.81363589562 2336.3446476522 853.572631468881]
# Looks like you failed 2 tests of 602.
There is another problem that may be connected.
https://www.cpantesters.org/cpan/report/43b58a7e-f03b-11ee-be38-1f116e8775ea, on amd64-freebsd, shows:
# Failed test 'as_native'
# at t/complex.t line 66.
# got: '[1 3]'
# expected: '[1+1.69883998968099e-313i 3+1.69883998968099e-313i]'
# Failed test at t/complex.t line 249.
# '44'
# doesn't match '(?^:44.*3)'
# got:44
# Failed test 'sf.net bug #1176614'
# at t/complex.t line 318.
# '
# [
# [9.1234+1.6992392419555e-313i]
# ]
# '
# doesn't match '(?^:9.123\S*4.123)'
http://www.cpantesters.org/cpan/report/4c1c59c2-f03b-11ee-be38-1f116e8775ea (on same) shows similar but without the middle failure.
Do you want to keep supporting 32bit architectures?
If not, we'll just remove the packages from those architectures.
I do want to keep supporting it for the present time. Analysing this particular problem has already revealed a pretty long-standing bug, so I don't want that sort of thing masked!
I believe that last commit's test captures that this is fixed; it now passes (along with t/slice.t) on my 32-bit VM here.
What was going on was that when I added the large negative numbers to get polyroots to test a core feature, those were being detected (but only on 32-bit, probably a compiler bug) as being == in C to an unsigned long long before it got to a signed long long. By changing it to try all signed integer types first, that has fixed it.
I'll release a new PDL once I've fixed another issue identified: the code to turn an SV into a single value got missed in adding native-complex support, so one can set a complex ndarray's badvalue by giving it a 1-value ndarray, but not yet by giving it a Math::Complex object (which is how PDL deals with Perl scalars that are complex numbers).
Do you have a capability to test that you agree the immediate issue is fixed, or will that have to wait until I've released the new PDL?
Do you have a capability to test that you agree the immediate issue is fixed, or will that have to wait until I've released the new PDL?
I could cherry-pick the commits in question and add them as patches to the package, but packaging a new upstream release is easier. If the new release is going to take several days, then adding patches would be quicker.
Unfortunately the patches don't apply due to other changes not cherry-picked, so waiting for the new release seems like a better idea than adding a massive patch with all changes since 2.086.
I've just released 2.087, which I believe fixes the known problems. Please let me know if anything shows up as wrong?
Confirmed fixed on i386, see:
https://salsa.debian.org/perl-team/modules/packages/pdl/-/pipelines/661929
I did have to update the clean target to also remove the generated Makefiles,
with those changes Salsa CI doesn't fail any more:
https://salsa.debian.org/perl-team/modules/packages/pdl/-/pipelines/661944
The package builds on the other 32bit architectures are looking good too:
Thank you for everything!