TST: Add testing on Python 3.5 on Appveyor.

[arokem]

Feel free to ignore this. I am trying to understand the failures I am seeing over here: conda-forge/staged-recipes#284

[coveralls]

Coverage remained the same at 95.72% when pulling 65dd001 on arokem:appveyor-3.5 into 83d3249 on nipy:master.

[arokem]

OK - please ignore the license to ignore. I have a question: any particular reason the Appveyor thing is running under @Eric89GXL's Appveyor account (rather than an org account)?

[larsoner]

No real reason. Apparently I added AppVeyor support a while back. Let me know if I need to do anything to switch it over.

[coveralls]

Coverage remained the same at 95.72% when pulling 2b2f438 on arokem:appveyor-3.5 into 83d3249 on nipy:master.

[codecov-io]

Current coverage is 94.22%

Merging #446 into master will not change coverage

@@             master       #446   diff @@
==========================================
  Files           160        160          
  Lines         21185      21185          
  Methods           0          0          
  Messages          0          0          
  Branches       2265       2265          
==========================================
  Hits          19961      19961          
  Misses          803        803          
  Partials        421        421          

Powered by Codecov. Last updated by 2a9e96f...63c8a49

[arokem]

Huh. It passed (after a few re-pushes). Feel free to merge this, if you think it's a good idea (Appveyor is admittedly a bit of a pain in the neck...)

[lesteve]

Looking at https://ci.appveyor.com/project/Eric89GXL/nibabel/build/1.0.694/job/ntqqoxkcha3ywiji#L84, it looks like the python 3.5 AppVeyor build actually uses python 2.7.

[effigies]

Did something change on the conda end between pushes? From what I've seen, passing is somewhat random, these days, and the errors are usually checksum failures. Maybe a package server that was/is out of sync?

[arokem]

@lesteve : good catch! That's wild. Will investigate
@effigies : no change, as far as I can tell. The failures are probably due to random download failures on Appveyor (see discussion here: ContinuumIO/anaconda-issues#71)

[coveralls]

Coverage remained the same at 95.72% when pulling cb87d89 on arokem:appveyor-3.5 into 83d3249 on nipy:master.

[coveralls]

Coverage remained the same at 95.72% when pulling 26ecf0c on arokem:appveyor-3.5 into 83d3249 on nipy:master.

[coveralls]

Coverage remained the same at 95.72% when pulling 3c40992 on arokem:appveyor-3.5 into 83d3249 on nipy:master.

[matthew-brett]

Hmm - that's weird - the buildbots have been testing Python 3.5 with Christoph Gohlke's wheels for a while without (these) problems :

http://nipy.bic.berkeley.edu/builders/nibabel-bdist32-35

[arokem]

Yes. It is weird. Any thoughts?

This might be obvious, but a lot of these look like overflow errors to me.
Something about the machine this is running on? Or Anaconda versions of
libraries being weird?

On Tue, Apr 19, 2016 at 10:15 AM, Matthew Brett [email protected]
wrote:

Hmm - that's weird - the buildbots have been testing Python 3.5 with
Christoph Gohlke's wheels for a while without (these) problems :

http://nipy.bic.berkeley.edu/builders/nibabel-bdist32-35

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#446 (comment)

[matthew-brett]

It's difficult to imagine the precision differences would be due to the machine.

Do you know - does numpy pass its own test suite on this setup?

[arokem]

It seems that it does. For example: https://ci.appveyor.com/project/numpy/numpy/build/1.0.281/job/htein9lmbbgn116y

[matthew-brett]

I've given you an account on the BIDS windows testing box, called "carly", I've sent details via email.

The way I use the machine is via remote desktop. So I install the Microsoft Remote Desktop app on OSX, then forward the relevant port to my machine with:

ssh -L3389:localhost:3389 myuser@address-of-carly

and start remote desktop pointing with a session pointed to localhost:3389 . You'll need your password to log in though.

The least obtrusive way to get going is to work on a powershell command line inside a Windows docker container, like this:

docker run --rm -ti windowsservercore powershell

This gives you a fresh throwaway container to play in, for which you have admin permissions. See: http://matthew-brett.github.io/pydagogue/windows_containers.html#example-of-installing-into-a-container

[arokem]

OK - I've managed to install Anaconda in there (although not inside the docker container - instead I have installed it only for my user - I apologize if that's more intrusive than necessary), and I manage to replicate the same failures on Carly as the ones we see on Appveyor. It's quite hard for me to make any sense of them, though. The most I can make out is that a lot of them seem to have to do with nan's getting cast into the wrong values (for example, they're supposed to cast to 0, and end up in -128 instead, or they are supposed to cast to 0 and end up in some floating point value (~1.0039) instead. Especially on round-trips, things seem to go wrong (with overflow also happening - 0's going to np.iinfo(np.int64).min instead). Does this ring any bells?

[matthew-brett]

Yes, sadly it does. We had this kind of problem for an MSVC bug:

#367

numpy/numpy#6685

The tests are - I think - differences from the expected numbers when working with int max values and doing array scaling.

It was extremely hard to track the previous error down, partly because the tests are a little opaque. You can see Ben C struggling manfully with the code in the first PR.

I ended up spending a lot of time taking the test input for working and not working versions (with and without MKL in that case) and comparing the inputs and outputs. Ugh.

[matthew-brett]

Ariel - any progress here?

[arokem]

No progress. I haven't had time to look into this more.

On Tue, May 3, 2016 at 11:10 AM, Matthew Brett [email protected]
wrote:

Ariel - any progress here?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#446 (comment)

[lesteve]

I tracked down one of the failing test (test_nan2zero_scaling) to a numpy clip issue, which for some reason seems to be happening only on Windows with Python 3.5, see numpy/numpy#7601.

[lesteve]

Good news, with the numpy fix from the PR numpy/numpy#7678, I can run the nibabel tests without any failure on my VM. So maybe there is no Python 3.5 specific problem within nibabel. If someone could double-check that would be great.

In the medium term, not sure whether there is an easy way to run the tests with AppVeyor using numpy from master. Alternatively you could wait for a numpy version with the fix to be relased before using Python 3.5 for continuous integration.

[arokem]

I am +1 for waiting on a numpy release with the fix, before proceeding with this PR.

[lesteve]

FYI the numpy fix is going to be in 1.11.1. The numpy release candidate has been announced a few hours ago so it may not be that long before a numpy release with the fix.

[lesteve]

numpy 1.11.1 is available through conda now, so in principle it is just a matter of relaunching the CI tests to make sure the AppVeyor tests pass on Python 3.5 before this PR can be merged.

[arokem]

Thanks for the alert. I just rebased this on top of current master and pushed, which should trigger the CI.

[coveralls]

Coverage remained the same at 95.72% when pulling 65dd001 on arokem:appveyor-3.5 into 83d3249 on nipy:master.

[arokem]

Yep. Looks like everything is coming up green.

I noticed that there is no Python 2/64 bot on Appveyor. Is there any reason for that, or should I add it?

[larsoner]

I think it was just for testing time, AppVeyor processes serially.

FYI a better solution is probably to use ci-helpers to get Anaconda up on AppVeyor, but that could be another PR when someone gets motivated.

[lesteve]

@matthew-brett I reckon this one should be merged.

[matthew-brett]

Thanks for doing this - merging.