gridData.tests.test_ccp4.test_ccp4 test fails on big-endian arches #50
Labels
Milestone
Comments
orbeckst
added a commit
that referenced
this issue
Aug 15, 2018
- should help with debugging #50 - added test that checks that the test ccp4 file byteorder is properly detected
Merged
orbeckst
added a commit
that referenced
this issue
Aug 15, 2018
- should help with debugging #50 - added test that checks that the test ccp4 file byteorder is properly detected
orbeckst
added a commit
that referenced
this issue
Aug 16, 2018
- should help with debugging #50 - added test that checks that the test ccp4 file byteorder is properly detected
orbeckst
added a commit
that referenced
this issue
Aug 16, 2018
- should help with debugging #50 - added test that checks that the test ccp4 file byteorder is properly detected
|
Unfortunately it's still failing on big-endian. Ignore that it says 0.4.0, I patched it with code (c777d4e) from the |
|
To be honest, I didn't expect this patch to fix anything. I wanted to get a bit more fine-grained control. In particular, so unless I wrote my test wrong, it looks as if we at least correctly detect the endianness of the data file. |
|
Next things todo:
|
orbeckst
added a commit
that referenced
this issue
Apr 6, 2019
- should help with debugging #50 - added test that checks that the test ccp4 file byteorder is properly detected
|
I guess there hasn't been any progress here. 0.5.0 is failing as follows: |
|
Well, I don't understand what GridDataFormats/gridData/CCP4.py Lines 256 to 260 in 899bc74 So regardless of whether the host machine is little endian or big endian, if the bytes of 209-213 of the reading file is 209'M' 210'A' 211'P' 212' ', flag But then struct flag GridDataFormats/gridData/CCP4.py Line 304 in 899bc74 Note that if I change the line L256 to |
Closed
|
@orbeckst unfortunately mrcfile has issues on s390x as well, see ccpem/mrcfile#35 . |
|
That’s disappointing. But at least now if/when it gets fixed in mrcfile then it will benefit more people. |
|
So, mrcfile got fixed, but GridDataFormats-0.7.0 CCP4 tests are still failing on s390x: https://koji.fedoraproject.org/koji/taskinfo?taskID=86372084 . |
|
Thank you for the update. Given that we are removing the deprecated CCP4 module anyway, we might just make a new release with it gone. I’m very happy about the good news that mrcfile got fixed! |
Merged
orbeckst
added a commit
that referenced
this issue
May 12, 2022
* removed CCP4 module - fix #107 and #50 - removed CCP4.py and test_CCP4.py - updated docs - updated CHANGELOG * Update CHANGELOG Co-authored-by: Irfan Alibay <[email protected]> Co-authored-by: Irfan Alibay <[email protected]>
|
We removed the failing tests. In principle that should be enough to close this issue. If you have the time to try it and report back then that would be great. Otherwise I’ll just cut the 1.0 release and hope it will be fine. |
|
(We also removed the code that belonged to the failing tests, not just the tests… just wanted to be clear :-) ) |
|
The failing tests are not anymore present in the 1.0.0 release (#68 ). The functionality is provided by the new mrc module and the tests are not necessary anymore so I am closing the issue. |
|
The test suite passes on s390x with 1.0.1. Thanks! |
|
Thank you for the feedback.
Glad to hear that this is now working— thank you for raising the issue with mrcfile that ultimately lead to proper big-endian handling.
… Am 5/29/22 um 14:22 schrieb rathann ***@***.***>:
The test suite passes on s390x with 1.0.1. Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you modified the open/close state.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When running under Fedora rawhide on a big-endian machine (ppc64, s390x),
test_ccp4fails:python version is
Python 2.7.15.The text was updated successfully, but these errors were encountered: