gmane.comp.python.numeric.general

headers Paul Lucek | 7 Oct 19:40

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Paul Lucek wrote:
>
> I get the following errors in umathmodule.c.src:
>
>  
>
> D:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe
> /c /nolog
>
> o /Ox /MD /W3 /GS- /DNDEBUG -Ibuild\src.win-amd64-2.6\numpy\core\src
> -Inumpy\cor
>
> e\include -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy
> -Inumpy\core\src -I
>
> numpy\core\include -Id:\python26\include -Id:\python26\PC
> /Tcbuild\src.win-amd64
>
> -2.6\numpy\core\src\umathmodule.c
> /Fobuild\temp.win-amd64-2.6\Release\build\src.
>
> win-amd64-2.6\numpy\core\src\umathmodule.obj
>
> umathmodule.c
>
> numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type'
>
> numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'
>
> numpy\core\src\ufuncobject.c(1701) : warning C4244: '=' : conversion
> from 'npy_i
>
> ntp' to 'int', possible loss of data
>
> numpy\core\src\ufuncobject.c(2422) : warning C4244: '=' : conversion
> from 'npy_i
>
> ntp' to 'int', possible loss of data
>
> error: Command "D:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\BIN\amd64\
>
> cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG
> -Ibuild\src.win-amd64-2.6\numpy\core
>
> \src -Inumpy\core\include
> -Ibuild\src.win-amd64-2.6\numpy\core\include/numpy -In
>
> umpy\core\src -Inumpy\core\include -Id:\python26\include
> -Id:\python26\PC /Tcbui
>
> ld\src.win-amd64-2.6\numpy\core\src\umathmodule.c
> /Fobuild\temp.win-amd64-2.6\Re
>
> lease\build\src.win-amd64-2.6\numpy\core\src\umathmodule.obj" failed
> with exit s
>
> tatus 2
>
>  
>

Note that 1.2.0 does not officially support python 2.6, specially on
windows. Because python 2.6 uses a new toolchain (VS 2008 by default
instead of 2003), it requires some non trivial changes. I hope that all
those changes will be in place for numpy 1.3,

cheers,

David

On Wednesday 08 October 2008 03:39:32 David Cournapeau wrote:
> Note that 1.2.0 does not officially support python 2.6, specially on
> windows. Because python 2.6 uses a new toolchain (VS 2008 by default
> instead of 2003), it requires some non trivial changes.

How extensive are these non-trivial changes? I could help test any changes. My 
problem is one that should be familiar to most people working in a large 
organization. I am trying to sneak in python+scipy as a replacement for 
Matlab, mostly by ensuring that python is used as the embedded scripting 
language for a signal processing simulation platform. (The ability to embed 
python, especially with seamless interoperability between numpy arrays and 
boost ublas vectors/matrices, is something Matlab cannot match.) 

The majority of my colleagues work on Windows and are very resistant to 
toolset changes. Hence, from my perspective, whenever a new project starts, it 
is very important to start with the latest version of any software packages 
used. Usually, over the typical 3-4 year lifetime of a project, the tools are 
never updated unless there is an absolutely critical bug fix. We are still on 
python 2.2 for a couple of currently active projects (neither of which uses 
numpy). For the next project, I was hoping to use Python 2.6 + numpy 1.2 as 
the base versions, but that seems unworkable now.

> I hope that all those changes will be in place for numpy 1.3,

Is there an idea of the timeframe for numpy 1.3?

Regards,
Ravi

On Wed, Oct 8, 2008 at 2:41 PM, Ravi <lists_ravi <at> lavabit.com> wrote:
> The majority of my colleagues work on Windows and are very resistant to
> toolset changes. Hence, from my perspective, whenever a new project starts, it
> is very important to start with the latest version of any software packages
> used. Usually, over the typical 3-4 year lifetime of a project, the tools are
> never updated unless there is an absolutely critical bug fix. We are still on
> python 2.2 for a couple of currently active projects (neither of which uses
> numpy). For the next project, I was hoping to use Python 2.6 + numpy 1.2 as
> the base versions, but that seems unworkable now.

How about python 2.5 and numpy 1.2 instead?  Python 2.6 makes some
important changes to python 2.5 (in preparation for Python 3.0), so
you may find several other packages will take a couple of months to
work 100% with python 2.6 - so check this out if you do plan to use
more than just numpy.  There are sometimes drawbacks to using brand
new releases ;)

Peter

Peter wrote:
>
> How about python 2.5 and numpy 1.2 instead?  Python 2.6 makes some
> important changes to python 2.5 (in preparation for Python 3.0), so
> you may find several other packages will take a couple of months to
> work 100% with python 2.6 - so check this out if you do plan to use
> more than just numpy.  There are sometimes drawbacks to using brand
> new releases ;)

If I understand Ravi right, one problem with 2.5 is that it relies on an
old toolset (VS 2003, not available anymore). OTOH, 2.6 depends on the
most recent toolset, which is also available for free in a limited
version (VS 2008 express). If you think about supporting things for a
couple of years, relying on VS 2008 sounds safer than 2003.

cheers,

David

On Wednesday 08 October 2008 09:40:58 David Cournapeau wrote:
> > How about python 2.5 and numpy 1.2 instead?  Python 2.6 makes some
> > important changes to python 2.5 (in preparation for Python 3.0), so
> > you may find several other packages will take a couple of months to
> > work 100% with python 2.6 - so check this out if you do plan to use
> > more than just numpy.  There are sometimes drawbacks to using brand
> > new releases ;)
>
> If I understand Ravi right, one problem with 2.5 is that it relies on an
> old toolset (VS 2003, not available anymore). OTOH, 2.6 depends on the
> most recent toolset, which is also available for free in a limited
> version (VS 2008 express). If you think about supporting things for a
> couple of years, relying on VS 2008 sounds safer than 2003.

Absolutely correct. VS 2003 is one of the biggest problems. I know C++ is not 
a favored language in these parts, but a lot of our code relies on Boost, for 
platform neutrality (like filesystem, threading, stdint) and for many other 
utilities (like ublas, wave, tuples, bind). VS 2003 requires too many 
workarounds in my code and support for it may be dropped in Boost some time 
soon: VS 7.0 is already scheduled for to be dropped and VS 7.1 (a.k.a. VS 
2003) is not likely to be supported for much longer. In fact python 2.5.x's 
requirement of VS 2003 is probably the main reason that this compiler is still 
used in a lot of places.

The only python packages that I use are numpy/scipy, matplotlib, pyhdf5, and 
an interprocess communication link with VisIt. To the best of my knowledge, 
all of these work today (in some fashion) with python 2.6 on Linux. Therefore, 
any changes required to make them build on Windows are likely to be compiler-
specific rather than to fix inherent problems related to python 2.6.

Regards,
Ravi

Ravi wrote:
> On Wednesday 08 October 2008 03:39:32 David Cournapeau wrote:
>   
>> Note that 1.2.0 does not officially support python 2.6, specially on
>> windows. Because python 2.6 uses a new toolchain (VS 2008 by default
>> instead of 2003), it requires some non trivial changes.
>>     
>
> How extensive are these non-trivial changes? I could help test any changes. 

For one, the manifest madness introduced with VS 2005 may be painful to
handle, since it severly lacks any serious documentation. I am still
unsure whether we will need to care at all, though.

Another problem is that python headers are not "clean", they pollute the
namespace quite heavily; a new version of python means new names added:
those should be trivial, though.

Other things are the usual: brokenness of MS tools with respect to
standards (basic C99 functions not available, etc...). Every version of
MS tool is broken, but in a different way.

cheers,

David

On Wednesday 08 October 2008 09:44:25 David Cournapeau wrote:
> For one, the manifest madness introduced with VS 2005 may be painful to
> handle, since it severly lacks any serious documentation. I am still
> unsure whether we will need to care at all, though.
>
> Another problem is that python headers are not "clean", they pollute the
> namespace quite heavily; a new version of python means new names added:
> those should be trivial, though.
>
> Other things are the usual: brokenness of MS tools with respect to
> standards (basic C99 functions not available, etc...). Every version of
> MS tool is broken, but in a different way.

The reasons above are why I don't try to do anything on Windows unless there 
is support from some external source, e.g., CMake taking care of build issues. 
The reasons above are also why I admire your heroic efforts at making Windows 
binaries available. But, then, I sometimes wonder about the motivation for an 
unpaid volunteer to take on an utterly thankless job in which help is never 
forthcoming from users; for any of my code out in the wild, the only help, bug 
fixes and improvements I have ever received have been from Linux and Solris 
users.

Thank for taking on this arduous task.

Regards,
Ravi

Ravi wrote:
>
> The reasons above are why I don't try to do anything on Windows unless there 
> is support from some external source, e.g., CMake taking care of build issues. 
> The reasons above are also why I admire your heroic efforts at making Windows 
> binaries available. But, then, I sometimes wonder about the motivation for an 
> unpaid volunteer to take on an utterly thankless job in which help is never 
> forthcoming from users;

I think numpy and scipy have a wonderful potential, and that currently,
installation is the biggest hurdle. I can show some awesome things in
numpy/scipy and co that people used to matlab would only dream of. But
if it takes more than 2 minutes and a few clicks to install, it is of no
use. I have some people who ask me how to install numpy/scipy, and I
have no simple answer: I think this is by far the biggest barrier of
entry for numpy and scipy ATM. That's why I am interested in making
numpy and scipy installation easy.

>
> Thank for taking on this arduous task.

Just want to mention I am certainly not the only one involved here for
windows binaries. This is really a collective work,

cheers,

David

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

On Wednesday 08 October 2008 10:56:02 Hanni Ali wrote:
> We discussed errors you are encountering a few months ago, they are related
> to the compiler directives.
>
> > #ifndef HAVE_FREXPF
> > static float frexpf(float x, int * i)
> > {
> >     return (float)frexp((double)(x), i);
> > }
> > #endif
> > #ifndef HAVE_LDEXPF
> > static float ldexpf(float x, int i)
> > {
> >     return (float)ldexp((double)(x), i);
> > }
> > #endif
>
> Commenting out this section at line 64 allow compilation and has no ill
> effects.

Given that commenting out the section above allows numpy to compile without 
any apparent side effects, is there any chance we could get "experimental" 
binaries of numpy 1.2.0 for python 2.6? I do understand that a negative answer 
is very likely and the reasons therefor.

Regards,
Ravi

Ravi wrote:
>
>
> Given that commenting out the section above allows numpy to compile without 
> any apparent side effects, is there any chance we could get "experimental" 
> binaries of numpy 1.2.0 for python 2.6? I do understand that a negative answer 
> is very likely and the reasons therefor.
>   

I started a wiki page on the issues related to windows, 64 bits and
python 2.6 (those issues are somewhat related at some level):

http://scipy.org/scipy/numpy/wiki/MicrosoftToolchainSupport

If you want to help, you can try solving one problem. In particular, if
you know how to build ATLAS with Visual studio (for 64 bits support), it
would be really helpful,

cheers,

David

David Cournapeau wrote:

Hi David,

> 
> I started a wiki page on the issues related to windows, 64 bits and
> python 2.6 (those issues are somewhat related at some level):
> 
> http://scipy.org/scipy/numpy/wiki/MicrosoftToolchainSupport

Cool.

> If you want to help, you can try solving one problem. In particular, if
> you know how to build ATLAS with Visual studio (for 64 bits support), it
> would be really helpful,

The problem with 64 bit ATLAS support for MSVC is that as is that ATLAS 
uses (AFAIK) assembly code that is not compilable with the MSVC 
toolchain. Since the official MinGW cannot create 64 bit code (there is 
some experimental support I have not tried yet) the only hope at the 
moment (without converting the assembly) to use the Intel toolchain. I 
have not tried that yet.

The current ATLAS code even requires Cygwin, but there was recent 
activity on the ATLAS mailing list to support MinGW only. There are also 
issues with threading support with MinGW to winpthread, so there is some 
work ahead to fully support ATLAS with MSVC.

Clint Whaley is supposed to speak at Sage Days 11 in Austin in about a 
month and I had planned to investigate the possibilities of native 64 
bit ATLAS support for VC9. I had planned to spend some days after SD 11 
at Enthought and work on MSVC build issues as well as 64 bit OSX stuff 
for example, but I need to make plans shortly since I need to buy my 
plane ticket soon

> cheers,
> 
> David

Cheers,

Michael

> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
> 

On Friday 10 October 2008 03:06:26 David Cournapeau wrote:
> > Given that commenting out the section above allows numpy to compile
> > without any apparent side effects, is there any chance we could get
> > "experimental" binaries of numpy 1.2.0 for python 2.6? I do understand
> > that a negative answer is very likely and the reasons therefor.
> >  
>
> I started a wiki page on the issues related to windows, 64 bits and
> python 2.6 (those issues are somewhat related at some level):
>
> http://scipy.org/scipy/numpy/wiki/MicrosoftToolchainSupport
>
> If you want to help, you can try solving one problem. In particular, if
> you know how to build ATLAS with Visual studio (for 64 bits support), it
> would be really helpful,

Michael Abshoff already responded to the ATLAS question. I don't have access 
to a 64-bit Windows. Given the volume of legacy 32-bit applications where I 
work, there is no chance of 64-bit Windows access for me for at least 2 years.

VS2008 with 32-bit windows should not have any problems (as you mentioned on 
the Wiki page referenced above). What needs to be done to figure out msvc9 
support on mingw and how can I help? I am a Windows n00b (mostly by choice) 
when it comes to platform-specific issues.

Regards,
Ravi

Ravi wrote:
>
> Michael Abshoff already responded to the ATLAS question. I don't have access 
> to a 64-bit Windows. Given the volume of legacy 32-bit applications where I 
> work, there is no chance of 64-bit Windows access for me for at least 2 years.

Windows 64 actually has a very nice feature: WoW (windows on windows).
It can executes any 32 bits software, AFAIK (which does not run in ring
0 of course).

>
> VS2008 with 32-bit windows should not have any problems (as you mentioned on 
> the Wiki page referenced above).

I wish it were true :) I can't build numpy with mingw ATM, because of
bugs in mingw. Things like:

http://bugs.python.org/issue3308

>  What needs to be done to figure out msvc9 
> support on mingw and how can I help? I am a Windows n00b (mostly by choice) 
> when it comes to platform-specific issues.

Then, I am afraid you won't be of much help, ufortunately.

cheers,

David

David Cournapeau wrote:
> Ravi wrote:

Hi,

>> Michael Abshoff already responded to the ATLAS question. I don't have access 
>> to a 64-bit Windows. Given the volume of legacy 32-bit applications where I 
>> work, there is no chance of 64-bit Windows access for me for at least 2 years.
> 
> Windows 64 actually has a very nice feature: WoW (windows on windows).
> It can executes any 32 bits software, AFAIK (which does not run in ring
> 0 of course).

Well, I think that having a 64 bit native build of numpy/scipy using an 
efficient and non-commercial licensed BLAS/Lapack (i.e. not Intel MKL) 
can't be a bad thing :)

>> VS2008 with 32-bit windows should not have any problems (as you mentioned on 
>> the Wiki page referenced above).
> 
> I wish it were true :) I can't build numpy with mingw ATM, because of
> bugs in mingw. Things like:
> 
> http://bugs.python.org/issue3308

It might be possible to build python [2.5|2.6|3.0] with MinGW itself to 
avoid the runtime issue. At least Python 2.4 had problems when building 
it with MinGW and I never investigated if 2.5.x had fixed those issues.

>>  What needs to be done to figure out msvc9 
>> support on mingw and how can I help? I am a Windows n00b (mostly by choice) 
>> when it comes to platform-specific issues.
> 
> Then, I am afraid you won't be of much help, ufortunately.
> 
> cheers,
> 
> David

Cheers,

Michael

> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
> 

Michael Abshoff wrote:
>
> Well, I think that having a 64 bit native build of numpy/scipy using an 
> efficient and non-commercial licensed BLAS/Lapack (i.e. not Intel MKL) 
> can't be a bad thing :)

Yes, of course. But it is useful to be able to use a 32 bits toolchain
to produce 64 bits software.

>
> It might be possible to build python [2.5|2.6|3.0] with MinGW itself to 
> avoid the runtime issue. At least Python 2.4 had problems when building 
> it with MinGW and I never investigated if 2.5.x had fixed those issues.

Not being ABI compatible with Python from python.org is not an option,
and building it with mingw would make it ABI incompatible for sure. I
certainly wished they used an open source compiler to build the official
python binary, but that's not the case.

cheers,

David

David Cournapeau wrote:

Hi David,

> Michael Abshoff wrote:
>> Well, I think that having a 64 bit native build of numpy/scipy using an 
>> efficient and non-commercial licensed BLAS/Lapack (i.e. not Intel MKL) 
>> can't be a bad thing :)
> 
> Yes, of course. But it is useful to be able to use a 32 bits toolchain
> to produce 64 bits software.

Sure, but there isn't even a 32 bit gcc out there that can produce 64 
bit PE binaries (aside from the MinGW fork that AFAIK does not work 
particularly well and allegedly has issues with the cleanliness of some 
of the code which is allegedly the reason that the official MinGW people 
will not touch the code base) . It has been rumored for a while that 
there is a new version of SFU by Microsoft in the works based on gcc 
4.2.x that will be able create 64 bit PE binaries, but I have not 
actually talked to anybody who has access, so it could be just a rumor.

>> It might be possible to build python [2.5|2.6|3.0] with MinGW itself to 
>> avoid the runtime issue. At least Python 2.4 had problems when building 
>> it with MinGW and I never investigated if 2.5.x had fixed those issues.
> 
> Not being ABI compatible with Python from python.org is not an option,
> and building it with mingw would make it ABI incompatible for sure. I
> certainly wished they used an open source compiler to build the official
> python binary, but that's not the case.

Ok, that is a concern I usually do not have since I tend to build my own 
Python :).

I am pretty sure that building Python with MinGW will break ABI 
compatibility with Python 2.6. As has been discussed on this list more 
than once not even Python 2.5 build with MSVC 2003 is really compatible 
with C++ extensions build with MinGW.

> cheers,
> 
> David

Cheers,

Michael

> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
> 

Michael Abshoff wrote:
>
> Sure, but there isn't even a 32 bit gcc out there that can produce 64 
> bit PE binaries (aside from the MinGW fork that AFAIK does not work 
> particularly well and allegedly has issues with the cleanliness of some 
> of the code which is allegedly the reason that the official MinGW people 
> will not touch the code base) .

The biggest problem is that officially, there is still no gcc 4 release
for mingw. I saw a gcc 4 section in cygwin, though, so maybe it is about
to be released. There is no support at all for 64 bits PE in the 3 serie.

I think binutils officially support 64 bits PE (I can build a linux
hosted binutils for 64 bits PE with x86_64-pc-mingw32 as a target, and
it seems to work: disassembling and co). gcc 4 can work, too (you can
build a bootstrap C compiler which targets windows 64 bits IICR). The
biggest problem AFAICS is the runtime (mingw64, which is indeed legally
murky).

>
> Ok, that is a concern I usually do not have since I tend to build my own 
> Python :).

I would say that if you can build python by yourself on windows, you can
certainly build numpy by yourself :) It took me quite a time to be able
to build python on windows by myself from scratch.

cheers,

David

David Cournapeau wrote:

> Michael Abshoff wrote:

Hi David,

>> Sure, but there isn't even a 32 bit gcc out there that can produce 64 
>> bit PE binaries (aside from the MinGW fork that AFAIK does not work 
>> particularly well and allegedly has issues with the cleanliness of some 
>> of the code which is allegedly the reason that the official MinGW people 
>> will not touch the code base) .
> 
> The biggest problem is that officially, there is still no gcc 4 release
> for mingw. I saw a gcc 4 section in cygwin, though, so maybe it is about
> to be released. There is no support at all for 64 bits PE in the 3 serie.

Yes, you are correct and I was wrong. I just checked out the mingw-64 
project and there has been a lot of activity the last couple month, 
including a patch to build pthread-win32 in 64 bit mode.

> I think binutils officially support 64 bits PE (I can build a linux
> hosted binutils for 64 bits PE with x86_64-pc-mingw32 as a target, and
> it seems to work: disassembling and co). gcc 4 can work, too (you can
> build a bootstrap C compiler which targets windows 64 bits IICR). The
> biggest problem AFAICS is the runtime (mingw64, which is indeed legally
> murky).

I would really like to find the actual reason *why* the legal status of 
the 64 bit MinGW port is murky (To my knowledge it has to do with taking 
code from the MS Platform toolkit - but that is conjecture), so I guess 
I will do the obvious thing and ask on the MinGW list :)

>> Ok, that is a concern I usually do not have since I tend to build my own 
>> Python :).
> 
> I would say that if you can build python by yourself on windows, you can
> certainly build numpy by yourself :) It took me quite a time to be able
> to build python on windows by myself from scratch.

Sure, I do see your point.

Accidentally someone posted about

    http://debian-interix.net/

on the sage-windows list today. It offers a gcc 4.2 toolchain and AFAIK 
there is at least a patch set for ATLAS to make it work on Interix.

> cheers,
> 
> David

Cheers,

Michael

> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
> 

On 10/8/2008 10:29 AM Ravi apparently wrote:
> I sometimes wonder about the motivation for an 
> unpaid volunteer to take on an utterly thankless job in which help is never 
> forthcoming from users  ...
> Thank for taking on this arduous task.

See, it is not entirely thankless.  
I would like to add my thanks as well,
and those of my students who are mostly
Windows users who rely on these binaries.
Alan Isaac

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

Re: can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9

can't build numpy 1.2.0 under python 2.6 (windows-amd64) using VS9