[Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
Mon Jun 22 09:43:03 CDT 2009
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!!!
On Mon, Jun 22, 2009 at 2:39 AM, David Cournapeau <email@example.com>wrote:
> On Mon, Jun 22, 2009 at 10:15 AM, Bruce Southey<firstname.lastname@example.org> wrote:
> > On Sun, Jun 21, 2009 at 4:01 AM, David Cournapeau
> > <email@example.com> wrote:
> >> (Continuing the discussion initiated in the neighborhood iterator
> >> 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
> > 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
> - 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.
> Numpy-discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion