Skip to content

Windows msvc14 has no useful find_msvcrt() method anymore. - #4792

Merged
eteq merged 3 commits into
astropy:masterfrom
MSeifert04:use_cdll_mscvrt_if_py35
Apr 19, 2016
Merged

Windows msvc14 has no useful find_msvcrt() method anymore.#4792
eteq merged 3 commits into
astropy:masterfrom
MSeifert04:use_cdll_mscvrt_if_py35

Conversation

@MSeifert04

@MSeifert04 MSeifert04 commented Apr 19, 2016

Copy link
Copy Markdown
Contributor

Also contained: Trying to pass appveyor python3.5

I hope this doesn't break anything and fixes something (on my computer at least it fixed 15 test failures for windows10 with python 3.5)

@MSeifert04
Windows msvc14 has no useful find_msvcrt() method anymore.
e0d294b 
Also contained: Trying to pass appveyor python3.5
@MSeifert04

MSeifert04 commented Apr 19, 2016

Copy link
Copy Markdown
Contributor Author

This should fix: #4342

@MSeifert04

MSeifert04 commented Apr 19, 2016

Copy link
Copy Markdown
Contributor Author

Does anyone know why this Error happenes in AppVeyor python 3.5:

Build started
git clone -q https://github.com/astropy/astropy.git C:\projects\astropy
git fetch -q origin +refs/pull/4792/merge:
git checkout -qf FETCH_HEAD
Running Install scripts
git clone git://github.com/astropy/ci-helpers.git
Cloning into 'ci-helpers'...
powershell ci-helpers/appveyor/install-miniconda.ps1
Installing miniconda latest for -x64 bit architecture to C:\conda 
Downloading Miniconda-latest-Windows-x86_64.exe from http://repo.continuum.io/miniconda/Miniconda-latest-Windows-x86_64.exe 
File saved at C:\projects\astropy\Miniconda-latest-Windows-x86_64.exe 
Installing C:\projects\astropy\Miniconda-latest-Windows-x86_64.exe to C:\conda 
C:\projects\astropy\Miniconda-latest-Windows-x86_64.exe /InstallationType=AllUsers /S /AddToPath=1 /RegisterPython=1 /D=C:\conda 
Start-Process : This command cannot be run due to the error: The specified 
executable is not a valid application for this OS platform..
At C:\projects\astropy\ci-helpers\appveyor\install-miniconda.ps1:61 char:5
+     Start-Process -FilePath $filepath -ArgumentList $args -Wait -Passthru
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOp 
   erationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.C 
   ommands.StartProcessCommand

Failed to install Python in C:\conda 
Command exited with code 1

Exactly the same build runs fine for python 2.7 and python 3.4. Do I need to include something else? I'm actually not very familiar with those test-builds and don't know if that's something I missed or if it's just disabled.

@pllim

pllim commented Apr 19, 2016

Copy link
Copy Markdown
Member

This is rebased against the latest master, right? Just want to make sure this is not already fixed somewhere else recently.

@MSeifert04

MSeifert04 commented Apr 19, 2016

Copy link
Copy Markdown
Contributor Author

@pllim I think so. git diff only shows this PR as difference between the latest astropy-master and this branch. I hope this answers your question, I'm not sure if that was what you wanted to know.

@pllim

pllim commented Apr 19, 2016

Copy link
Copy Markdown
Member

I don't know if git diff is a sure-fire way to check that. When do you this, do you see things happening on the terminal?

git fetch upstream master
git rebase upstream/master

@bsipocz

bsipocz commented Apr 19, 2016

Copy link
Copy Markdown
Member

@MSeifert04 - It looks like a transient and restarting (recommitting) usually solves it.

@bsipocz

bsipocz commented Apr 19, 2016

Copy link
Copy Markdown
Member

btw if this fixes all the 3.5 issues, I suggest to remove the allow failures section. And also remove the 3.4 testing from the matrix (as was planned in #4450).

@bsipocz bsipocz mentioned this pull request Apr 19, 2016
Merged
@eteq
eteq merged commit 5337729 into astropy:master Apr 19, 2016
@MSeifert04
MSeifert04 deleted the use_cdll_mscvrt_if_py35 branch April 19, 2016 21:21
@eteq eteq mentioned this pull request Apr 19, 2016
Closed
1 task done
@eteq eteq modified the milestone: v1.2.0 Apr 19, 2016
@eteq

eteq commented Apr 19, 2016

Copy link
Copy Markdown
Member

After some discussion on gitter the conclusion was that this isn't a bug fix per se but should just serve to suppress some unintended warnings (so doesn't need a changelog entry or backporting)

@MSeifert04

MSeifert04 commented Apr 19, 2016

Copy link
Copy Markdown
Contributor Author

maybe: cc @embray - You mentioned that fixing #4342 would need some refactoring. Could using ctypes.cdll.msvcrt lead to difficulties here?

@MSeifert04 MSeifert04 mentioned this pull request Apr 20, 2016
Merged
@embray embray added this to the v1.1.3 milestone Apr 20, 2016
@embray

embray commented Apr 20, 2016

Copy link
Copy Markdown
Member

I don't have strong feelings one way or the other about the changelog entry, but would still classify this as a bug fix and it should have some milestone--most appropriately the next 1.1.x patch release.

@astrofrog astrofrog mentioned this pull request May 17, 2016
Merged
2 tasks done
@astrofrog astrofrog modified the milestones: v1.2.0, v1.1.3 May 17, 2016
astrofrog added a commit that referenced this pull request Sep 29, 2016
@astrofrog
Merge pull request #4793 from MSeifert04/io_fits_append_mode
c8080dd 
current workaround #4792 for appveyor python 3.5 does not work correctly
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

Bug io.fits Manual Backport no-changelog-entry-needed testing unusual-merge-dealt-with Windows

Projects

None yet

Milestone

v1.2.0

Development

Successfully merging this pull request may close these issues.

6 participants

@MSeifert04 @pllim @bsipocz @eteq @embray @astrofrog