test failures on 32bit linux

There are a 11 test failures when I test the master on an old 32bit system.

Some of the fails seem genuine, e.g.

we don't say in the docs which scipy version is required, or check for the version in the test, and obviously 0.10.0 is not enough for the coordinates module
error of TypeError: data type "float128" not understood
TypeError: 'buffer' does not have the buffer interface at several places in relation with io.fits

Full log: https://gist.github.com/bsipocz/38a4d6bf5041d837a2f8

Hmm. It's too late to do this for v1.0 I think. But maybe for v2.0 we should consider dropping support for 32-bit altogether? Would that even be feasible? In the meantime these should be fixed or worked around...

I'm fixing the first one as it's not related to 32bit or 64bit, but how we handle it if only an old version is available from scipy.

However I run into weird stuff with the testing environment which may end up in another issue if I can't figure out how to make it work.

I'll take a look at the FITS and modeling failures (the latter is probably just a precision issue).

@embray

@embray - a bit unrelated question: If I run test on the modul level with --package=coordinates, they run even though decorated with @pytest.mark.skipif(str('not HAS_SCIPY')) where HAS_SCIPY is False. However they got skipped when I run them individually with -t.
Does the decorator have a memory from previously run test files?

try:
    import scipy
    if version.LooseVersion(scipy.__version__) > version.LooseVersion('0.12.0'):
        HAS_SCIPY = True
    else:
        HAS_SCIPY = False
except ImportError:
    HAS_SCIPY = False

Could you please point me where I do it wrong? I remember a similar issue a few month ago when the -t behaved differently, but can't find it now.

@bsipocz

@bsipocz - what if you do:

python setup.py test -P coordinates

? We don't really support running tests with py.test directly.

Yes, that's what I'm doing.
python setup.py test --package=coordinates

Would it be the case that the decorator acts as a lazyproperty, thus doesn't get updated? Anyway, now I think it's cleaner to define a new separate OLD_SCIPY and decorate the tests with that one, too.

We run astropy on 32-bit systems (used in Chandra flight ops) so my vote is to maintain support for as long as practical.

As reported in astropy#3380 this test was failing on 32-bit systems--…

Well, #3397 should address the one modeling failure. But weirdly I can't reproduce the FITS failures. Going to investigate a bit more...

Oh, nevermind. I see what it is. It's not a 32-bit issue, it's because you have Python 2.7.3. This was a bug in 2.7.3 that was fixed in 2.7.4. I don't know if I brought this up with anyone else last time I encountered it, or if I just unilaterally decided we wouldn't support 2.7.3. Hmm.... might be worth having a workaround for?

I found just one error and three failures on i386:

TypeError: data type "float128" not understood (as above) (also on armel, armhf, mipsel)
test_eloc_attributes (also on arm64, see 1.0rc1&2: test_eloc_attributes() fail on i386 #3496)
test_identity (also on arm64, powerpc, pp64el, s390x, see 1.0rc1&2: test_identity fails on i386, arm64, powerpc, ppc64el, s390x #3486)
[doctest] astropy.wcs.wcs.WCS.all_world2pix (also on arm64, powerpc, ppc64el, s390x, ):

1944         ...
1945         NoConvergence: 'WCS.all_world2pix' failed to converge to the
1946         requested accuracy. After 3 iterations, the solution is
1947         diverging at least for one input point.
1948 
1949         >>> # Now try to use some diverging data:
1950         >>> divradec = w.all_pix2world([[1.0, 1.0],
1951         ...                             [10000.0, 50000.0],
1952         ...                             [3.0, 1.0]], 1)
1953         >>> print(divradec)
Expected:
    [ 0.99999996  0.99999997  0.99999997]
Got:
    [ 0.99999997  0.99999997  0.99999997]

astropy/wcs/wcs.py:1953: DocTestFailure

which all looks not really complicated. They seem all not 32-bit related (except the errors), but appear on different 64-bit platforms as well.

Some platforms have more failures; I'll open new issues for them.
All build logs here

I think the float128 issues was fixed in aa4fed2 (after 1.0rc1)

@embray

I've tried to fix the wcs doctest fails (the listed one is only the first, basically all the print statements are failing), but somehow the +FLOAT_CMP didn't work well with the lines that print out an array.
@embray - is FLOAT_CMP supposed to work with arrays of (3, 2) shape?

@astrofrog

@astrofrog With aa4fed2 the float128 issue goes away (just tested on Debian Hurd); the other problems remain ofcourse.

The TypeError: 'buffer' does not have the buffer interface error is still occurring, but I don't see any other failures, when testing on Ubuntu 12.04 32-bit.

I have a suggested fix for the buffer error: #5078

Now that #5078 is merged, can we close this?

I just tested with 1.3rc1, and can confirm that this is OK now, including the WCS.all_world2pix doctest.

@olebole

@olebole -thanks for testing! I'll close this now it is confirmed to work.

Navigation Menu

Repository navigation

test failures on 32bit linux #3380

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

test failures on 32bit linux #3380

Description

Activity

embray commented on Jan 28, 2015

bsipocz commented on Jan 28, 2015

embray commented on Jan 28, 2015

bsipocz commented on Jan 28, 2015

astrofrog commented on Jan 28, 2015

bsipocz commented on Jan 28, 2015

taldcroft commented on Jan 28, 2015

1 remaining item

embray commented on Jan 29, 2015

embray commented on Jan 29, 2015

olebole commented on Jan 31, 2015

astrofrog commented on Jan 31, 2015

bsipocz commented on Jan 31, 2015

olebole commented on Feb 2, 2015

astrofrog commented on Jun 12, 2016

astrofrog commented on Jun 12, 2016

pllim commented on Sep 3, 2016

olebole commented on Dec 13, 2016

mhvk commented on Dec 13, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions