Re: [Numpy-discussion] [PATCH] gfortran under macports
On 3. des. 2010, at 16.24, Fabian Pedregosa wrote: Hi all. Macports installs gfortran as part of the gcc package, but names it gfortran-mp-$version, without providing a symbolic link to a default gcfortran executable, and thus numpy.distutils is unable to find the right executable. The attached patch very simple, it just extends possible_executables with those names, but makes the build of scipy work without having to restore to obscure fc_config flags. Fabian. 0001-FIX-recognize-macports-gfortran-compiler.patch___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Correct me if I am wrong here: If you run (sudo) gcc_select gfortran-mp-XY, where XY are the version numbers (e.g. 45 for gfortran 4.5), you should get symbolic links for the selected gcc/gfortran version. I believe that macports should probably make this clearer, and perhaps automatically when you do a port install gccXY, but I am not sure if this needs any patching? Again, I might be wrong on this. Cheers Paul. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [PATCH] gfortran under macports
Correct me if I am wrong here: If you run (sudo) gcc_select gfortran-mp-XY, where XY are the version numbers (e.g. 45 for gfortran 4.5), you should get symbolic links for the selected gcc/gfortran version. I believe that macports should probably make this clearer, and perhaps automatically when you do a port install gccXY, but I am not sure if this needs any patching? Again, I might be wrong on this. Thanks! I didn't know about gcc_select. The correct command is sudo gcc_select mp-gcc45 which effectively does all the symbolic links for you and works like a charm, so please ignore my previous patch. Cheers, fabian ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [PATCH] gfortran under macports
On Sat, Dec 04, 2010 at 10:25:52AM +0100, Fabian Pedregosa wrote: The correct command is sudo gcc_select mp-gcc45 which effectively does all the symbolic links for you and works like a charm, so please ignore my previous patch. I am not a mac user, so I guess that my opinion is not very educated, but isn't your patch still useful: test if 'gcc' exists, and if not fallback to your patch, so that it still works for the clueless user? My 2 cents, Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [PATCH] gfortran under macports
On Sat, Dec 4, 2010 at 10:29 AM, Gael Varoquaux gael.varoqu...@normalesup.org wrote: On Sat, Dec 04, 2010 at 10:25:52AM +0100, Fabian Pedregosa wrote: The correct command is sudo gcc_select mp-gcc45 which effectively does all the symbolic links for you and works like a charm, so please ignore my previous patch. I am not a mac user, so I guess that my opinion is not very educated, but isn't your patch still useful: test if 'gcc' exists, and if not fallback to your patch, so that it still works for the clueless user? Indeed, having scipy build out of the box would be nice, but it's not for me to decide if numpy.distutils should overcome these limitations in macports ... On the other hand, as installing on macports is not that trivial, I strongly feel that a subsection 'Macports' should be added to scipy's INSTALL.txt file, where it details needed packages, the gcc_select trick and options needed in site.cfg for umfpack. I'll gladly provide a patch for that if people are OK. Fabian. My 2 cents, Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [PATCH] gfortran under macports
On Sat, Dec 4, 2010 at 9:47 PM, Fabian Pedregosa fabian.pedreg...@inria.frwrote: On Sat, Dec 4, 2010 at 10:29 AM, Gael Varoquaux gael.varoqu...@normalesup.org wrote: On Sat, Dec 04, 2010 at 10:25:52AM +0100, Fabian Pedregosa wrote: The correct command is sudo gcc_select mp-gcc45 which effectively does all the symbolic links for you and works like a charm, so please ignore my previous patch. I am not a mac user, so I guess that my opinion is not very educated, but isn't your patch still useful: test if 'gcc' exists, and if not fallback to your patch, so that it still works for the clueless user? Indeed, having scipy build out of the box would be nice, but it's not for me to decide if numpy.distutils should overcome these limitations in macports ... I would prefer to just document the gcc_select solution, since it solves the problem at hand. On the other hand, as installing on macports is not that trivial, I strongly feel that a subsection 'Macports' should be added to scipy's INSTALL.txt file, where it details needed packages, the gcc_select trick and options needed in site.cfg for umfpack. I'll gladly provide a patch for that if people are OK. The most up-to-date instructions are at http://www.scipy.org/Installing_SciPy/Mac_OS_X, so those should be updated as well. That said, if a Macports section is added there should be a strong disclaimer that it is *not* the recommended way to install numpy/scipy. A good portion of the build problems reported on these lists are related to Fortran on OS X, and a specific gfortran build at http://r.research.att.com/tools/ is recommended for a reason. If a user really wants to use Macports some notes in the docs may help, but let's not give the impression that it's a good/default option for a new user. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Refactor fork uses the ./configure, make, make install process.
Hi Jason, Just wondering if this is temporary or the intention is to change the build process? I also note that the *.h files in libndarray are not complete and a *lot* of trailing whitespace has crept into the files. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Faster than ndindex?
Hi guys, I would like to know if there is any way to make the following operation faster. def test(): shape=(200,200,200,3) refinds = np.ndindex(shape[:3]) reftmp=np.zeros(shape) for ijk_t in refinds: i,j,k = ijk_t reftmp[i,j,k,0]=i reftmp[i,j,k,1]=j reftmp[i,j,k,2]=k %timeit test() 1 loops, best of 3: 19.5 s per loop I am using ndindex and then a for loop. Is there a better/faster way? Thank you, Eleftherios ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.
On Sat, Dec 4, 2010 at 12:59 PM, Ilan Schnell ischn...@enthought.comwrote: Yes, numpy-refactor builds of top of libndarray. The whole point was that the libndarray is independent of the interface, i.e. the CPython or the IronPython interface, and possibly other (Jython) in the future. Looking at different building/packaging solutions for libndarray, autoconf make things very easy, it's a well established pattern, I'm sure David C. will agree. I know he has expressed reservations about it on non-posix platforms and some large projects have moved away from it. I'm not saying it isn't the best short term solution so you folks can get on with the job, but it may be that long term we will want to look elsewhere. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.
On Sat, Dec 4, 2010 at 12:52 PM, Pauli Virtanen p...@iki.fi wrote: On Sat, 04 Dec 2010 12:21:15 -0700, Charles R Harris wrote: [clip] So does numpy currently build on top of libndarray or is that something for the future also? [clip] It does. If you look how it works, most of the heavy lifting has been moved there, leaving the multiarray module mostly as Python-specific wrappers. Would it unreasonable to move the libndarray stuff to the current master branch of numpy while leaving the rest of things intact? The needed changes to the current core/src could be brought in later. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.
I'm not sure how reasonable it would be to move only libndarray into the master, because I've been working on EPD for the last couple of week. But Jason will know how complete libndarray is. - Ilan On Sat, Dec 4, 2010 at 2:19 PM, Charles R Harris charlesr.har...@gmail.com wrote: Would it unreasonable to move the libndarray stuff to the current master branch of numpy while leaving the rest of things intact? The needed changes to the current core/src could be brought in later. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.
On Sat, 04 Dec 2010 14:24:49 -0600, Ilan Schnell wrote: I'm not sure how reasonable it would be to move only libndarray into the master, because I've been working on EPD for the last couple of week. But Jason will know how complete libndarray is. The main question is whether moving it will make things easier or more difficult, I think. It's one tree more to keep track of. In any case, it would be a first part in the merge, and it would split the hunk of changes into two parts. *** Technically, the move could be done like this, so that merge tracking still works: refactor--- new-refactor // /libndarray--x / \ start-- master- new-master -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.
On 12/04/2010 09:11 PM, Charles R Harris wrote: On Sat, Dec 4, 2010 at 12:59 PM, Ilan Schnell ischn...@enthought.com mailto:ischn...@enthought.com wrote: Yes, numpy-refactor builds of top of libndarray. The whole point was that the libndarray is independent of the interface, i.e. the CPython or the IronPython interface, and possibly other (Jython) in the future. Looking at different building/packaging solutions for libndarray, autoconf make things very easy, it's a well established pattern, I'm sure David C. will agree. I know he has expressed reservations about it on non-posix platforms and some large projects have moved away from it. I'm not saying it isn't the best short term solution so you folks can get on with the job, but it may be that long term we will want to look elsewhere. Such as perhaps waf for building libndarray, which seems like it will be much easier to make work nicely with Bento etc. than autoconf (again, speaking long-term). Also, it'd be good to avoid a seperate build system for Windows (problem of keeping changes sync-ed with Visual Studio projects etc. etc.). Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.
On Sat, Dec 4, 2010 at 1:45 PM, Pauli Virtanen p...@iki.fi wrote: On Sat, 04 Dec 2010 14:24:49 -0600, Ilan Schnell wrote: I'm not sure how reasonable it would be to move only libndarray into the master, because I've been working on EPD for the last couple of week. But Jason will know how complete libndarray is. The main question is whether moving it will make things easier or more difficult, I think. It's one tree more to keep track of. In any case, it would be a first part in the merge, and it would split the hunk of changes into two parts. That would be a good thing IMHO. It would also bring a bit more numpy reality to the refactor and since we are implicitly relying on it for the next release sometime next spring the closer to reality it gets the better. *** Technically, the move could be done like this, so that merge tracking still works: refactor--- new-refactor // /libndarray--x / \ start-- master- new-master Looks good to me. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.
On Sat, Dec 4, 2010 at 12:45 PM, Pauli Virtanen p...@iki.fi wrote: Technically, the move could be done like this, so that merge tracking still works: refactor--- new-refactor // /libndarray--x / \ start-- master- new-master Switching to use libndarray is a big ABI+API change, right? If there's an idea to release an ABI-compatible 1.6, wouldn't this end up being more difficult? Maybe I'm misunderstanding this idea. I looked a little bit at the 1.4.0 ABI issue, and if the only blocking problem was the cast[] array in ArrFuncs, I think that can be worked around without too much difficulty. Would people want an ABI-compatible 1.6 release adding date-time and float16? -Mark ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [PATCH] gfortran under macports
Mabe I am wrong somehow, but in my experience the easiest install of scipy is 'port install py26-scipy'. For new users, I do not see why one would recommend to build manually from source? Macports can do it for you, automagically... Paul 4. des.. 2010 15.04 Ralf Gommers ralf.gomm...@googlemail.com: On Sat, Dec 4, 2010 at 9:47 PM, Fabian Pedregosa fabian.pedreg...@inria.fr wrote: On Sat, Dec ... I would prefer to just document the gcc_select solution, since it solves the problem at hand. On the other hand, as installing on macports is not that trivial, I strongly feel that a sub... The most up-to-date instructions are at http://www.scipy.org/Installing_SciPy/Mac_OS_X, so those should be updated as well. That said, if a Macports section is added there should be a strong disclaimer that it is *not* the recommended way to install numpy/scipy. A good portion of the build problems reported on these lists are related to Fortran on OS X, and a specific gfortran build at http://r.research.att.com/tools/ is recommended for a reason. If a user really wants to use Macports some notes in the docs may help, but let's not give the impression that it's a good/default option for a new user. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
