Issue 1:
At the moment we have a single major blocker to compiling scipy on Windows:

Python.org Windows binaries are compiled against an MS Visual C++ runtime, which differs with different Python versions: see https://matthew-brett.github.io/pydagogue/python_msvc.html

It is dangerous and error-prone to pass objects (such as file-handles) that are created using one run-time, into code linked against another run-time;

There is currently Fortran compiler with a BSD-compatible run-time license that can link against all the MSVC runtimes we need to support. In particular mingw-w64 cannot currently link against MSVC 2015 runtimes, used by Pythons 3.5 and 3.6.

Here we are exploring another option, which is to compile the Fortran code to link against the generic MSVCRT runtime, on the basis that the Fortran code does not use any of the objects (such as file-handles) that get created by the Python (and Numpy) linked MSVC run-times. The plan is therefore:

Compile scipy C code with the MSVC compiler matching the version of Python;

Compile scipy Fortran code with gfortran linking against the generic MSVCRT runtime;

Hope for the best.

There's some discussion of this over at #7551 - starting at #7551 (comment).

Appveyor scripting at https://github.com/matthew-brett/build-scipy . Builds at https://ci.appveyor.com/project/matthew-brett/build-scipy

The procedure so far is the following (see: https://github.com/matthew-brett/build-scipy/blob/master/appveyor.yml):

Download and install mingwpy into Python 2.7 matching the bitness (32 or 64) of the Python we're building in;

Patch mingwpy to link to the the default msvcrt.dll rather than the specific MSVC 9 runtime;

Unpack built OpenBLAS, and point scipy install to that build;

Patch numpy distutils to avoid linking to some mingw-specific libraries;

Build scipy.

Current errors are for missing math symbols such as _sinf - see this report and Pauli's suggestion.

Current participants @matthew-brett @rgommers @pv @carlkl .

Issue 2:
Original ticket http://projects.scipy.org/scipy/ticket/1665 on 2012-05-30 by @endolith, assigned to @cournape.

The window functions in scipy.signal have a sym option for producing symmetric windows or periodic windows, but if you create a periodic window of an odd size, it gives identical output to a symmetric window. This is in the code, but is it right? It doesn't match Matlab's behavior, as described [https://ccrma.stanford.edu/~jos/sasp/Matlab_Hamming_Window.html here].

If it's right, it should be documented why it works this way

>> hamming(3) % same in Matlab and Octave
ans =
0.0800
1.0000
0.0800
>> hamming(3,'symmetric') % Matlab only
ans =
0.0800
1.0000
0.0800
>> hamming(3,'periodic') % Matlab only
ans =
0.0800
0.7700
0.7700
>> hamming(4) % same in Matlab and Octave
ans =
0.0800
0.7700
0.7700
0.0800

SciPy:

In [2]: hamming(3)
Out[2]: array([ 0.08, 1. , 0.08])

In [3]: hamming(3,sym=True)
Out[3]: array([ 0.08, 1. , 0.08])

In [4]: hamming(3,sym=False)
Out[4]: array([ 0.08, 1. , 0.08])

In [5]: hamming(4)
Out[5]: array([ 0.08, 0.77, 0.77, 0.08])

In [6]: hamming(4, sym=True)
Out[6]: array([ 0.08, 0.77, 0.77, 0.08])

In [7]: hamming(4, sym=False)
Out[7]: array([ 0.08, 0.54, 1. , 0.54])