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

WIP: Fix 32bit appveyor failures #2188

Merged
merged 3 commits into from Jul 5, 2018

Conversation

Projects
None yet
2 participants
@krischer
Member

krischer commented Jul 2, 2018

There have been some 32bit appveyor failures. Just trying to figure out what they are remotely as I don't have access to a windows machine right now.

@krischer krischer added bug CI labels Jul 2, 2018

@krischer

This comment has been minimized.

Member

krischer commented Jul 2, 2018

Does anyone understand what is happening here? It only happens on Windows 32bit so its a bit tedious for me to debug.

I realize that comparing floating point numbers is dangerous, but here we are literally comparing

st1 = read(...)
st2 = read(...)

st1.simulate(...)
for tr in st2:
     tr.simulate(...)

assert st1 == st2

the Stream.simulate() method internally does nothing different so I don't see how this test could fail. Maybe one of the upstream packages like numpy, scipy, BLAS/LAPACK has some misbehaving cache here?

@barsch Is there any chance you could debug this locally? It takes forever to do over AppVeyor.

@barsch

This comment has been minimized.

Member

barsch commented Jul 2, 2018

@krischer no time today - will look into it Wednesday - which 32bit python version should I play with 2.7, 3.5 or 3.6?

@krischer

This comment has been minimized.

Member

krischer commented Jul 2, 2018

@barsch

This comment has been minimized.

Member

barsch commented Jul 4, 2018

my local environment works without issues - see https://gist.github.com/barsch/1b305aa1b6e4a67d2573f8e9ab0b1aca

will setup an anaconda environment and test again

@barsch

This comment has been minimized.

Member

barsch commented Jul 4, 2018

unfortunately same result: https://gist.github.com/barsch/7ccc2b96934287a604691bbda2e21c12

no exception in a new conda setup using the same installation order and packages as listed here: https://ci.appveyor.com/project/obspy/obspy/build/1.0.6110-maintenance_1.1.x/job/ib5le487t949gj5j

how should I proceed further?

@krischer

This comment has been minimized.

Member

krischer commented Jul 4, 2018

Hmm - I guess we could just weaken the test a bit and use np.testing.assert_allclose() for the data on 32 bit windows. Should be safe enough and we at least get rid of all the annoying appveyor failures.

krischer added some commits Jul 4, 2018

@krischer

This comment has been minimized.

Member

krischer commented Jul 5, 2018

Alright - a slightly silly "fix" but it seems to work.

@krischer krischer merged commit b4b8199 into maintenance_1.1.x Jul 5, 2018

5 of 6 checks passed

docker-testbot docker testbot results not available yet
ci/circleci Your tests passed on CircleCI!
Details
codecov/patch 100% of diff hit (target 90%)
Details
codecov/project 88.09% (+1.31%) compared to 747116e
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@QuLogic QuLogic deleted the debug-appveyor-32bit branch Jul 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment