[Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0

[David Cournapeau]

On Mon, Jun 22, 2009 at 10:15 AM, Bruce Southey<bsouthey at gmail.com> wrote:
>
>
> On Sun, Jun 21, 2009 at 4:01 AM, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp> wrote:
>>
>> (Continuing the discussion initiated in the neighborhood iterator thread)
>>
>> Hi,
>>
>>    I would like to gather people's opinion on what to target for numpy
>> 1.4.0.
>>    - Chuck suggested to drop python < 2.6 support from now on. I am
>> against it without a very strong and detailed rationale, because many OS
>> still don't have python 2.6 (RHEL, Ubuntu LTS).
>>    - Even if not many new features have been implemented since 1.3.0,
>> there were several changes which would be quite useful (using npy_math
>> from numpy for scipy.special, neighborhood iterator for scipy.signal).
>> So releasing 1.4.0 soon would be useful so that scipy 0.8.0 could depend
>> on it.
>>    - Fixing crashes on windows 64 bits: I have not made any progress on
>> this. I am out of ideas on how to debug the problem, to be honest.
>>
>
> I think this is an essential requirement for numpy.

Yes. Windows 64 bits is finally usable (enough drivers) for the end
users. And the (totally unusable) numpy 1.3 64 bits binaries have been
downloaded quite a bit, confirming the interest.

> I am prepared to attempt
> to try to help as I now have a 64-bit windows system I can use. Just that I
> do not like the windows environment for programming one bit.

Me neither. It is really awful unless you are in the IDE. Ideally, a
primarily windows developer would be in charge.

> So I would
> appreciate any pointers to get the necessary functional system for 64-bit
> windows.

To summarize the issue. We have two alternatives:
   - compiling with VS 2008 works more or less. There are a few bugs,
but those are solvable through the debugger I guess with enough
motivation.
   - compiling with mingw-w64 crashes randomly. Sometimes it crashes
at import, sometimes during the unit tests, sometimes even before
calling init_multirarray (the first numpy C extension). It also
depends on how you launch python (IDLE vs. cmd.exe).

The big problem with VS 2008 is that there is no free fortran compiler
compatible with VS 2008. I can not even compile a trivial fortran + C
project with the VS 2008-gfortran combination. A numpy only build
could still be useful (for matplotlib, for example), but I am
reluctant to do that if we later go the mingw route, since both built
would be more than likely ABI incompatible.

With mingw compilers, we get gfortran "for free" (I can compile scipy,
for example), but there is this very serious crash which happens
randomly. The debugger does not work (maybe some stack corruption),
and there is no valgrind on windows, so it is very difficult to track
down. Of course, mingw debugging symbols are not compatible with MS
compilers, so the MS debugger is no option either.

David