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

[william ratcliff]

I haven't used it, but you might try Rational Purify from IBM as a valgrind
alternative on Windows.  They used to have a free trial.  Btw.  Are there
any docs that I can read on the issues involved in fortran-c-python
bindings?  Anything related to gfortran (fortran 95/2003) and python in
particular would be much appreciated!!!


Cheers,
William

On Mon, Jun 22, 2009 at 2:39 AM, David Cournapeau <cournape at gmail.com>wrote:

> 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
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090622/f4e9fae1/attachment.html>