Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

slice.t failures on i386 #469

Closed
sebastic opened this issue Apr 1, 2024 · 8 comments
Closed

slice.t failures on i386 #469

sebastic opened this issue Apr 1, 2024 · 8 comments

Comments

@sebastic
Copy link
Contributor

sebastic commented Apr 1, 2024

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:

https://buildd.debian.org/status/package.php?p=pdl

@mohawk2
Copy link
Member

mohawk2 commented Apr 2, 2024

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.

@sebastic
Copy link
Contributor Author

sebastic commented Apr 3, 2024

Do you want to keep supporting 32bit architectures?

If not, we'll just remove the packages from those architectures.

@mohawk2
Copy link
Member

mohawk2 commented Apr 3, 2024

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!

@mohawk2
Copy link
Member

mohawk2 commented Apr 4, 2024

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?

@sebastic
Copy link
Contributor Author

sebastic commented Apr 5, 2024

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.

@mohawk2
Copy link
Member

mohawk2 commented Apr 5, 2024

I've just released 2.087, which I believe fixes the known problems. Please let me know if anything shows up as wrong?

@sebastic
Copy link
Contributor Author

sebastic commented Apr 6, 2024

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:

https://buildd.debian.org/status/package.php?p=pdl

@sebastic sebastic closed this as completed Apr 6, 2024
@mohawk2
Copy link
Member

mohawk2 commented Apr 6, 2024

Thank you for everything!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants