Re: [Numpy-discussion] Installation info
Hi Robert,
Attached is the complete output, below is what I believe is the relevant
area of interest:
compiling C sources
creating build\temp.win-amd64-2.6\Release\build
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy
creating build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core
creating
build\temp.win-amd64-2.6\Release\build\src.win-amd64-2.6\numpy\core\src
C:\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 -Inumpy\core\src
-Inumpy\core\include -IC:\Python26\include -IC:\Python26\PC
-IC:\Python26\include -IC:\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(1645) : warning C4244: '=' : conversion from
'npy_intp' to 'int', possible loss of data
numpy\core\src\ufuncobject.c(2346) : warning C4244: '=' : conversion from
'npy_intp' to 'int', possible loss of data
What I find odd is that the instruction:
> #ifndef HAVE_FREXPF
should not produce the error (at least that's what I would have thought)
i.e. if it isn't recognised the compiler should simply be using the
alternate definition of the frexpf function defined, although I suspect it
is a little less efficient than the float one from the libs.
Hanni
2008/6/3 Robert Kern <[EMAIL PROTECTED]>:
> On Tue, Jun 3, 2008 at 3:21 AM, Hanni Ali <[EMAIL PROTECTED]> wrote:
> > Hi David,
> >
> > I compiled numpy with MSVC 9.0 (vs 2008), I am just using the inbuilt LA
> > libs to minimise complexity.
> >
> > Although I have hacked it such that I can compile and all but one of the
> > regression tests passed:
> >
> > ==
> > ERROR: Tests reading from a text file.
> > --
> > Traceback (most recent call last):
> > File "C:\Python26\lib\site-packages\numpy\ma\tests\test_mrecords.py",
> line
> > 363
> > , in test_fromtextfile
> > fname = 'tmp%s' % datetime.now().strftime("%y%m%d%H%M%S%s")
> > ValueError: Invalid format string
> > --
> > Ran 1267 tests in 1.141s
> > FAILED (errors=1)
> >
> >
> > This appears to be a problem with the strftime function in
> test_mrecords.py
> >
> > The error seems to be created by the millisecond formatting argument %s,
> > removing this caused the test to pass.
>
> Well, this should be using tempfile anyways.
>
> > So I think it's all ok really, however in order to get numpy to compile I
> > have commented out a small part which was causing compilation to fail:
> >
> > numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type'
> > numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'
> >
> > This relates to this section of code:
> >
> > #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
> >
> > The compiler directives HAVE_FREXPF and HAVE_LDEXPF do not appear to be
> > recognised by msvc 9 would you agree with that assessment?
> >
> > And a redefinition of a function present in the stdc library is
> occurring.
> >
> > What do you think? By just commenting out this piece of code numpy
> compiles
> > and appears to function.
>
> The presence of these functions should have been detected by the
> configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have
> been #define'd if we had detected them correctly. It is possible that
> our configuration process for this does not work correctly with VS
> 2008. From a clean checkout, can you please do the build again and
> copy-and-paste everything printed to the terminal?
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> -- Umberto Eco
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
output.tar.gz
Description: GNU Zip compressed data
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
I have used the trail of Visual Studio 2008 (on full Server 2003) it copmiles and runs well if you comment out the lines meantioned earlier on in this thread. I am planning to spend some time with the intel fortran compiler to try to compile blas/lapack in the next few weeks. It is part of my current project, so I will report back, Intel are usually very friendly to open source and if that means you offer intel optimised binaries they should hopefully be willing. Hanni (P.S. I sent an output from the compile in an earlier thread, but I think it was filtered I will re-post it and try to compress it a bit) 2008/6/9 David Cournapeau <[EMAIL PROTECTED]>: > Gael Varoquaux wrote: > > > > I was just wondering, could we ask Microsoft for some help here. A build > > bot, or a Windows 64 license... They are helping porting the SAGE project > > to windows, so they do have interest in getting open source scientific > > software working on windows. > > > > Windows 64 is actually the easiest problem: you can find free trial > license for Windows server 2008 on MS website. > > The main problem is the compiler and BLAS/LAPACK: mingw cannot target 64 > bits yet (there is a mingw-w64 project, but after some digging, I found > out that it was legally dubious, hence not integrated yet in the 'real' > mingw project). Now, you could think about using MS compiler, but I > don't like the idea very much, and there is the problem of blas/lapack. > cygwin, already slow, is dog slow on windows 64 (because it runs in 32 > bits, I guess ?), and is needed to build atlas (blas and lapack too, but > it is at least theoretically possible to build them without makefiles; > atlas build system is so complicated that it makes autotools feel > extremely enjoyable). > > cheers, > > David > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Gael Varoquaux wrote: > > I was just wondering, could we ask Microsoft for some help here. A build > bot, or a Windows 64 license... They are helping porting the SAGE project > to windows, so they do have interest in getting open source scientific > software working on windows. > Windows 64 is actually the easiest problem: you can find free trial license for Windows server 2008 on MS website. The main problem is the compiler and BLAS/LAPACK: mingw cannot target 64 bits yet (there is a mingw-w64 project, but after some digging, I found out that it was legally dubious, hence not integrated yet in the 'real' mingw project). Now, you could think about using MS compiler, but I don't like the idea very much, and there is the problem of blas/lapack. cygwin, already slow, is dog slow on windows 64 (because it runs in 32 bits, I guess ?), and is needed to build atlas (blas and lapack too, but it is at least theoretically possible to build them without makefiles; atlas build system is so complicated that it makes autotools feel extremely enjoyable). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
On Sat, May 31, 2008 at 12:01:10PM +0900, David Cournapeau wrote: > On Fri, May 30, 2008 at 8:35 PM, Hanni Ali <[EMAIL PROTECTED]> wrote: > > I would also like to see a 64bit build for windows as well if possible. > Unfortunately, this is difficult: windows 64 is not commonly available > (I don't have any access to it personally, for example), and mingw is > not available yet for windows 64 either. I was just wondering, could we ask Microsoft for some help here. A build bot, or a Windows 64 license... They are helping porting the SAGE project to windows, so they do have interest in getting open source scientific software working on windows. My 2 cents, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Charles R Harris wrote: > > It probably just grew to fix problems as they arose. It should be > possible to test for every function and fall back to the double > versions that are more reliably present. It would be nicer if all > compilers tried to conform to recent standards, i.e., be less than 9 > years out of date, but that is a bit much to ask for. Most compilers are not compatible (none of them supports C99 at 100 %; the better question is which subset is powerfull and implemented thouroughly). I had some surprising problems with numscons and mingw, and obviously MS compilers/runtime (each version has a different configuration for the part of the code we are talking about). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Robert Kern wrote: > > > There are a lot of them. Feel free to add any additional tests you > think are necessary, and we'll see how painful it is at build-time. > What would be acceptable ? I quickly tested on my macbook, on mac os X: it takes ~ 2 seconds / 25 functions tests. If speed really is a problem, than we can first test them as a group, and then one by one for the platforms where it does not work (something like AC_CHECK_FUNCS_ONCE, if you are familiar with autotools) ? It should not be too complicated to add this to distutils, and I believe it would make the configuration more robust, cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
On Tue, Jun 3, 2008 at 8:49 PM, David Cournapeau < [EMAIL PROTECTED]> wrote: > Robert Kern wrote: > > > > The presence of these functions should have been detected by the > > configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have > > been #define'd if we had detected them correctly. It is possible that > > our configuration process for this does not work correctly with VS > > 2008. From a clean checkout, can you please do the build again and > > copy-and-paste everything printed to the terminal? > > > > As an aside, I don't understand how the configuration is supposed to > work there: why do we define HAVE_LONGDOUBLE, etc... for a serie of > functions ? I don't understand why for example testing for expf is > supposed to be enough to guarantee the presence of the whole float > functions (HAVE_FLOAT_FUNCS). What is the rationale for that ? Why not > testing for every function we are using ? > It probably just grew to fix problems as they arose. It should be possible to test for every function and fall back to the double versions that are more reliably present. It would be nicer if all compilers tried to conform to recent standards, i.e., be less than 9 years out of date, but that is a bit much to ask for. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
On Tue, Jun 3, 2008 at 9:49 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Robert Kern wrote: >> >> The presence of these functions should have been detected by the >> configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have >> been #define'd if we had detected them correctly. It is possible that >> our configuration process for this does not work correctly with VS >> 2008. From a clean checkout, can you please do the build again and >> copy-and-paste everything printed to the terminal? > > As an aside, I don't understand how the configuration is supposed to > work there: why do we define HAVE_LONGDOUBLE, etc... for a serie of > functions ? I don't understand why for example testing for expf is > supposed to be enough to guarantee the presence of the whole float > functions (HAVE_FLOAT_FUNCS). What is the rationale for that ? Someone thought that it was a sufficient condition. If it is not, then it should be fixed. > Why not > testing for every function we are using ? There are a lot of them. Feel free to add any additional tests you think are necessary, and we'll see how painful it is at build-time. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Robert Kern wrote: > > The presence of these functions should have been detected by the > configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have > been #define'd if we had detected them correctly. It is possible that > our configuration process for this does not work correctly with VS > 2008. From a clean checkout, can you please do the build again and > copy-and-paste everything printed to the terminal? > As an aside, I don't understand how the configuration is supposed to work there: why do we define HAVE_LONGDOUBLE, etc... for a serie of functions ? I don't understand why for example testing for expf is supposed to be enough to guarantee the presence of the whole float functions (HAVE_FLOAT_FUNCS). What is the rationale for that ? Why not testing for every function we are using ? David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
On Tue, Jun 3, 2008 at 3:21 AM, Hanni Ali <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> I compiled numpy with MSVC 9.0 (vs 2008), I am just using the inbuilt LA
> libs to minimise complexity.
>
> Although I have hacked it such that I can compile and all but one of the
> regression tests passed:
>
> ==
> ERROR: Tests reading from a text file.
> --
> Traceback (most recent call last):
> File "C:\Python26\lib\site-packages\numpy\ma\tests\test_mrecords.py", line
> 363
> , in test_fromtextfile
> fname = 'tmp%s' % datetime.now().strftime("%y%m%d%H%M%S%s")
> ValueError: Invalid format string
> --
> Ran 1267 tests in 1.141s
> FAILED (errors=1)
>
>
> This appears to be a problem with the strftime function in test_mrecords.py
>
> The error seems to be created by the millisecond formatting argument %s,
> removing this caused the test to pass.
Well, this should be using tempfile anyways.
> So I think it's all ok really, however in order to get numpy to compile I
> have commented out a small part which was causing compilation to fail:
>
> numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type'
> numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'
>
> This relates to this section of code:
>
> #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
>
> The compiler directives HAVE_FREXPF and HAVE_LDEXPF do not appear to be
> recognised by msvc 9 would you agree with that assessment?
>
> And a redefinition of a function present in the stdc library is occurring.
>
> What do you think? By just commenting out this piece of code numpy compiles
> and appears to function.
The presence of these functions should have been detected by the
configuration process of numpy. HAVE_FREXPF and HAVE_LDEXPF would have
been #define'd if we had detected them correctly. It is possible that
our configuration process for this does not work correctly with VS
2008. From a clean checkout, can you please do the build again and
copy-and-paste everything printed to the terminal?
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Hi David,
I compiled numpy with MSVC 9.0 (vs 2008), I am just using the inbuilt LA
libs to minimise complexity.
Although I have hacked it such that I can compile and all but one of the
regression tests passed:
==
ERROR: Tests reading from a text file.
--
Traceback (most recent call last):
File "C:\Python26\lib\site-packages\numpy\ma\tests\test_mrecords.py", line
363
, in test_fromtextfile
fname = 'tmp%s' % datetime.now().strftime("%y%m%d%H%M%S%s")
ValueError: Invalid format string
--
Ran 1267 tests in 1.141s
FAILED (errors=1)
This appears to be a problem with the strftime function in test_mrecords.py
The error seems to be created by the millisecond formatting argument %s,
removing this caused the test to pass.
So I think it's all ok really, however in order to get numpy to compile I
have commented out a small part which was causing compilation to fail:
numpy\core\src\umathmodule.c.src(64) : error C2059: syntax error : 'type'
numpy\core\src\umathmodule.c.src(70) : error C2059: syntax error : 'type'
This relates to this section of code:
#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
The compiler directives HAVE_FREXPF and HAVE_LDEXPF do not appear to be
recognised by msvc 9 would you agree with that assessment?
And a redefinition of a function present in the stdc library is occurring.
What do you think? By just commenting out this piece of code numpy compiles
and appears to function.
Hanni
2008/6/2 Hanni Ali <[EMAIL PROTECTED]>:
> Excellenm, thanks for clearing all that up.
>
> How about numpy with 2.6, any issues?
>
> Hanni
>
> 2008/6/2 David Cournapeau <[EMAIL PROTECTED]>:
>
> Hanni Ali wrote:
>> >
>> > Yes I had used the internal versions in the mean time, but I do want
>> > to try to use the intel fortran compiler in all likelyhood.
>>
>> Yes, people can try to build as they want, that's the beauty of open
>> source :) But for official distribution, I don't want to depend on non
>> free software (outside windows, obviously). I need a process to build
>> numpy in a reproducible and in a hassle way (well, as much as possible,
>> at least).
>>
>> >
>> > Python 2.6 is compiled with vs 2008 is is important that numpy is also
>> > compiled with the same compiler or not. The fact that a fortran
>> > compiler is necessary makes me think no?
>>
>> This has nothing to do with fortran per se, but with the fact that MS
>> keeps breaking the standard C runtime. Hopefully, with python 3, this
>> may not be an issue anymore (python on windows won't use the standard C
>> API, but windows API instead, because MS guarantees ABI in this case, at
>> least that's what I understood).
>>
>> The fortran compiler has to be the same to build everything, but python
>> does not use any fortran, so you can choose whatever you want as long as
>> you use it for everything (BLAS, LAPACK and numpy).
>>
>> >
>> > It looks like I'm going to look at 2.6 now due to dependencies on
>> > pywin32 as well.
>> >
>> > Also is it important that BLAS/LAPACK are compiled with the same
>> > compiler as python or not?
>>
>> BLAS/LAPACK is built with fortran, and python with C compiler, so no :)
>> What may be important is the C++ compiler to build (more exactly to
>> link) python if you build python by yourself, but I don't know how this
>> works on windows. I just build softwares for windows, I don't use it.
>>
>> cheers,
>>
>> David
>> ___
>> Numpy-discussion mailing list
>> Numpy-discussion@scipy.org
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Excellenm, thanks for clearing all that up. How about numpy with 2.6, any issues? Hanni 2008/6/2 David Cournapeau <[EMAIL PROTECTED]>: > Hanni Ali wrote: > > > > Yes I had used the internal versions in the mean time, but I do want > > to try to use the intel fortran compiler in all likelyhood. > > Yes, people can try to build as they want, that's the beauty of open > source :) But for official distribution, I don't want to depend on non > free software (outside windows, obviously). I need a process to build > numpy in a reproducible and in a hassle way (well, as much as possible, > at least). > > > > > Python 2.6 is compiled with vs 2008 is is important that numpy is also > > compiled with the same compiler or not. The fact that a fortran > > compiler is necessary makes me think no? > > This has nothing to do with fortran per se, but with the fact that MS > keeps breaking the standard C runtime. Hopefully, with python 3, this > may not be an issue anymore (python on windows won't use the standard C > API, but windows API instead, because MS guarantees ABI in this case, at > least that's what I understood). > > The fortran compiler has to be the same to build everything, but python > does not use any fortran, so you can choose whatever you want as long as > you use it for everything (BLAS, LAPACK and numpy). > > > > > It looks like I'm going to look at 2.6 now due to dependencies on > > pywin32 as well. > > > > Also is it important that BLAS/LAPACK are compiled with the same > > compiler as python or not? > > BLAS/LAPACK is built with fortran, and python with C compiler, so no :) > What may be important is the C++ compiler to build (more exactly to > link) python if you build python by yourself, but I don't know how this > works on windows. I just build softwares for windows, I don't use it. > > cheers, > > David > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Hanni Ali wrote: > > Yes I had used the internal versions in the mean time, but I do want > to try to use the intel fortran compiler in all likelyhood. Yes, people can try to build as they want, that's the beauty of open source :) But for official distribution, I don't want to depend on non free software (outside windows, obviously). I need a process to build numpy in a reproducible and in a hassle way (well, as much as possible, at least). > > Python 2.6 is compiled with vs 2008 is is important that numpy is also > compiled with the same compiler or not. The fact that a fortran > compiler is necessary makes me think no? This has nothing to do with fortran per se, but with the fact that MS keeps breaking the standard C runtime. Hopefully, with python 3, this may not be an issue anymore (python on windows won't use the standard C API, but windows API instead, because MS guarantees ABI in this case, at least that's what I understood). The fortran compiler has to be the same to build everything, but python does not use any fortran, so you can choose whatever you want as long as you use it for everything (BLAS, LAPACK and numpy). > > It looks like I'm going to look at 2.6 now due to dependencies on > pywin32 as well. > > Also is it important that BLAS/LAPACK are compiled with the same > compiler as python or not? BLAS/LAPACK is built with fortran, and python with C compiler, so no :) What may be important is the C++ compiler to build (more exactly to link) python if you build python by yourself, but I don't know how this works on windows. I just build softwares for windows, I don't use it. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Hi David, > I can't build official binaries with VS: I don't have VS. Also, there is > the problem of building the fortran dependencies (BLAS/LAPACK). I don't > know if it is even possible to build ATLAS on windows x64. Even assuming > we only use netlib BLAS/LAPACK, I still need a fortran compiler (gfortran). > Yes I had used the internal versions in the mean time, but I do want to try to use the intel fortran compiler in all likelyhood. Python 2.6 is compiled with vs 2008 is is important that numpy is also compiled with the same compiler or not. The fact that a fortran compiler is necessary makes me think no? > > > however it had failed one of the regression tests. I will try > > numpy-1.1.0, has anyone used vs 2008 to compile it for 64 bit windows? > It looks like I'm going to look at 2.6 now due to dependencies on pywin32 as well. Also is it important that BLAS/LAPACK are compiled with the same compiler as python or not? (Obviously just the C++ parts) Thanks, Hanni ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Hanni Ali wrote: > > I had managed to compile and install 1.04 with vs 2005 64 bit with a > bit of hacking, I can't build official binaries with VS: I don't have VS. Also, there is the problem of building the fortran dependencies (BLAS/LAPACK). I don't know if it is even possible to build ATLAS on windows x64. Even assuming we only use netlib BLAS/LAPACK, I still need a fortran compiler (gfortran). > however it had failed one of the regression tests. I will try > numpy-1.1.0, has anyone used vs 2008 to compile it for 64 bit windows? You need to use the same VS as python: this means VS 2003 for official python 2.5 (you can build python yourself with VS 2005 or 2008, though, but for distribution, this is not useful). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
Hi David, > Unfortunately, this is difficult: windows 64 is not commonly available > (I don't have any access to it personally, for example), and mingw is > not available yet for windows 64 either. I had managed to compile and install 1.04 with vs 2005 64 bit with a bit of hacking, however it had failed one of the regression tests. I will try numpy-1.1.0, has anyone used vs 2008 to compile it for 64 bit windows? Cheers, Hanni ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
On Fri, May 30, 2008 at 8:35 PM, Hanni Ali <[EMAIL PROTECTED]> wrote: > I would also like to see a 64bit build for windows as well if possible. > > Unfortunately, this is difficult: windows 64 is not commonly available (I don't have any access to it personally, for example), and mingw is not available yet for windows 64 either. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
I would also like to see a 64bit build for windows as well if possible. Hanni 2008/5/30 Peter Creasey <[EMAIL PROTECTED]>: > 2008/5/30 Peter Creasey <[EMAIL PROTECTED]>: > > Is numpy v1.1 going to come out in egg format? > > > > Oops, I didn't mean to mail with an entire numpy digest in the body. > > sorry, > Peter > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > -- E-mail: [EMAIL PROTECTED] Mobile: +44 (0) 7985580147 My Blog: http://ainkaboot.co.uk/blogs/hanni/ Website: http://ainkaboot.co.uk http://drqueue.org ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation info
2008/5/30 Peter Creasey <[EMAIL PROTECTED]>: > Is numpy v1.1 going to come out in egg format? > Oops, I didn't mean to mail with an entire numpy digest in the body. sorry, Peter ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Installation info
Is numpy v1.1 going to come out in egg format?
I ask because I only see the superpack installers on the sourceforge
page, and we have users who we are delivering to via egg - requires.
thanks,
Peter
2008/5/23 <[EMAIL PROTECTED]>:
> Send Numpy-discussion mailing list submissions to
>numpy-discussion@scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>http://projects.scipy.org/mailman/listinfo/numpy-discussion
> or, via email, send a message with subject or body 'help' to
>[EMAIL PROTECTED]
>
> You can reach the person managing the list at
>[EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Numpy-discussion digest..."
>
>
> Today's Topics:
>
> 1. Re: f2py errors: any help interpreting? (Mark Miller)
> 2. Re: f2py errors: any help interpreting? (Robert Kern)
> 3. Re: f2py errors: any help interpreting? (Mark Miller)
> 4. Re: f2py errors: any help interpreting? (Robert Kern)
> 5. Re: f2py errors: any help interpreting? (Mark Miller)
> 6. Re: f2py errors: any help interpreting? (Mark Miller)
>
>
> --
>
> Message: 1
> Date: Fri, 23 May 2008 14:48:47 -0700
> From: "Mark Miller" <[EMAIL PROTECTED]>
> Subject: Re: [Numpy-discussion] f2py errors: any help interpreting?
> To: "Discussion of Numerical Python"
> Message-ID:
><[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Super...I'll give it a try. Or should I just wait for the numpy 1.1
> release?
>
> thanks,
>
> -Mark
>
> On Fri, May 23, 2008 at 2:45 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>> On Fri, May 23, 2008 at 4:00 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
>>
>> > File "C:\Python25\lib\site-packages\numpy\f2py\rules.py", line 1222, in
>> > buildmodule
>> > for l in '\n\n'.join(funcwrappers2)+'\n'.split('\n'):
>> > TypeError: cannot concatenate 'str' and 'list' objects
>> >
>> >
>> > Any thoughts? Please let me know if more information is needed to
>> > troubleshoot.
>>
>> This is a bug that was fixed in SVN r4335.
>>
>> http://projects.scipy.org/scipy/numpy/changeset/4335
>>
>> --
>> Robert Kern
>>
>> "I have come to believe that the whole world is an enigma, a harmless
>> enigma that is made terrible by our own mad attempt to interpret it as
>> though it had an underlying truth."
>> -- Umberto Eco
>> ___
>> Numpy-discussion mailing list
>> Numpy-discussion@scipy.org
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080523/750a2e8e/attachment-0001.html
>
> --
>
> Message: 2
> Date: Fri, 23 May 2008 17:01:04 -0500
> From: "Robert Kern" <[EMAIL PROTECTED]>
> Subject: Re: [Numpy-discussion] f2py errors: any help interpreting?
> To: "Discussion of Numerical Python"
> Message-ID:
><[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, May 23, 2008 at 4:48 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
>> Super...I'll give it a try. Or should I just wait for the numpy 1.1
>> release?
>
> Probably. You can get a binary installer for the release candidate here:
>
> http://www.ar.media.kyoto-u.ac.jp/members/david/archives/numpy-1.1.0rc1-win32-superpack-python2.5.exe
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> -- Umberto Eco
>
>
> --
>
> Message: 3
> Date: Fri, 23 May 2008 15:48:02 -0700
> From: "Mark Miller" <[EMAIL PROTECTED]>
> Subject: Re: [Numpy-discussion] f2py errors: any help interpreting?
> To: "Discussion of Numerical Python"
> Message-ID:
><[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thank you...getting much closer now.
>
> My current issue is this message:
>
> running build_ext
> error: don't know how to compile C/C++ code on platform 'nt' with 'g95'
> compiler.
>
> Any help?
>
> Again, sorry to pester. I'm just pretty unfamiliar with these things. Once
> I get environmental variables set up, I rarely need to fiddle with them
> again. So I don't have a specific feel for what might be happening here.
>
> thanks,
>
> -Mark
>
>
>
>
> On Fri, May 23, 2008 at 3:01 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>> On Fri, May 23, 2008 at 4:48 PM, Mark Miller <[EMAIL PROTECTED]>
>> wrote:
>> > Super...I'll give it a try. Or should I just wait for the numpy 1.1
>> > release?
>>
>> Probably. You can get a binary installer for the release candidate here:
>>
>>
>> http://www.ar.media.kyoto-u.ac.jp/members/david/archives/numpy-1.1.0rc1-win32-superpack-python2.5.exe
>>
>> --
>> Robert Kern
>>
>> "I have come to believe that the whol
