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
[3.5.23] test failures: TypeError: Cannot cast array data from dtype('int64') to dtype('int32') according to the rule 'safe' #690
Comments
Oh interesting, thanks for the report! The second log makes me deeply suspicious of the GEOS/Shapely build on different architectures and I might punt on that one as "upstream." The |
I had a quick look, and at least on Fedora, all the shapely tests pass an all architectures. I don't know how exhaustive their tests are but this would indicate that it's built properly as far as upstream are concerned? If you could help me gather more information on the shapely issue, I'd be happy to file bugs with them too.
Ah, that's a known issue then. Great :) |
Saw another build fail with a lot of these again:
An initial look seems like builds on 32bit architectures fail. On 64 bits, the build seems fine. |
Unit tests fail on x86. Upstream issue: mikedh/trimesh#690
Unit tests fail on x86. Upstream issue: mikedh/trimesh#690
Unit tests fail on x86. Upstream issue: mikedh/trimesh#690
I am attaching an updated log of test failures that seem to be due to 32-bit architecture issues in 3.9.20. |
All of the failures are still due to:
The list of failing tests is:
|
Updated for 3.9.34, on a machine that is actually The aforementioned
Now there are a number of tests that produce a
Detailed log of test failures. On Fedora’s On the
There are also some additional errors (XML syntax error or |
I was missing some
Of these, All are still of the form
|
That particular list of failures went away when I tried again with 3.9.36 just now. It’s not clear if the change was in
Support for 32-bit ARM in Fedora will end after Fedora 36. 32-bit x86 builds will stick around for multilib on x86_64, although there is no full 32-bit x86 version of the distribution anymore. |
A new failure has appeared in 3.17.0, similar to the existing 32-bit failures:
|
One new failure:
|
I've ran into the same issues while introducing the module into Debian. My workaround so far is this patch: https://salsa.debian.org/3dprinting-team/trimesh/-/blob/master/debian/patches/02-array-index-32bit-architectures.patch I also reported potential issues with the documentation of the affected functions to the numpy developers: numpy/numpy#23552 |
According to feedback in the numpy PR, this patch will not be appropriate for 64-bit Windows, because the On Linux, it will work fine though, because Python According to the numpy devs, the "correct" type is |
In Fedora Linux, we haven’t had an We already retired 32-bit ARM, https://fedoraproject.org/wiki/Changes/RetireARMv7, and the last version of Fedora to support it has reached end-of-life. Accordingly, @sanjayankur31 and I won’t be reporting any more issues related to 32-bit architectures. Here’s an updated summary of what I see on 4.0.2. We have all of the optional dependencies packaged except
In previous versions, I saw In previous versions, Since |
While updating the Fedora package, I see quite a few tests failing with this error:
The failed "scratch build" is here: https://koji.fedoraproject.org/koji/taskinfo?taskID=40470914
Since the build will be trashed in a few days, I've attached the complete build logs here:
trimesh-3.5.14-build-fail.txt
trimesh-3.5.14-build-fail-state.txt
trimesh-3.5.14-build-fail-hw.txt
It seems to be arch specific. If I force the build to run on an x86_64 builder, I only get two failed tests:
The logs from this build are here: https://koji.fedoraproject.org/koji/taskinfo?taskID=40471476
trimesh-3.5.14-build-fail-2.txt
trimesh-3.5.14-build-fail-hw-2.txt
trimesh-3.5.14-build-fail-state-2.txt
Cheers,
The text was updated successfully, but these errors were encountered: