On Fri, Nov 15, 2013 at 7:39 PM, Frédéric Bastien <no...@nouiz.org> wrote:
> If it don't change, currently it mean that each process that use > Theano and use BLAS will have that printed: > > Found executable /usr/bin/gfortran > ATLAS version 3.8.3 built by mockbuild on Wed Jul 28 02:12:34 UTC 2010: > UNAME : Linux x86-15.phx2.fedoraproject.org 2.6.32-44.el6.x86_64 > #1 SMP Wed Jul 7 15:47:50 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux > INSTFLG : -1 0 -a 1 > ARCHDEFS : -DATL_OS_Linux -DATL_ARCH_Corei7 -DATL_CPUMHZ=1596 > -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664 > F2CDEFS : -DAdd_ -DF77_INTEGER=int -DStringSunStyle > CACHEEDGE: 524288 > F77 : gfortran, version GNU Fortran (GCC) 4.5.0 20100716 (Red > Hat 4.5.0-3) > F77FLAGS : -O -g -Wa,--noexecstack -fPIC -m64 > SMC : gcc, version gcc (GCC) 4.5.0 20100716 (Red Hat 4.5.0-3) > SMCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 > -fno-schedule-insns2 -g -Wa,--noexecstack -fPIC -m64 > SKC : gcc, version gcc (GCC) 4.5.0 20100716 (Red Hat 4.5.0-3) > SKCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 > -fno-schedule-insns2 -g -Wa,--noexecstack -fPIC -m64 > > Not very nice. > > As told, in Theano we do that and it work on Mac, Linux and Windows in > 32 and 64 bits. Yes, we have our own wrapper around it to handle > windows. But as it is already done and tested in those cases, I think > it is a good idea to do it. > > Do you think that it should be tested in other environment? > I don't worry much about unix-like environments, windows with 'native' compilers is my main worry. Currently, building scipy with VS 2008 and ifort causes weird issues because scipy recently gained lots of files to be compiled, and sometimes, for some reason, the compilers crash. See: http://mail.scipy.org/pipermail/scipy-dev/2013-August/019169.html Now, if using subprocess fixes those, that alone would be a big +1 from me in its favor. Do you have the patch somewhere I can look at for testing ? David > > thanks > > Frédéric > > p.s. There is also warning printed, but I can hide them without change in > NumPy. > p.p.s The first line isn't yet removed in my local tests, so maybe > more is needed. > > On Fri, Nov 15, 2013 at 2:28 PM, David Cournapeau <courn...@gmail.com> > wrote: > > > > > > > > On Fri, Nov 15, 2013 at 6:21 PM, Charles R Harris > > <charlesr.har...@gmail.com> wrote: > >> > >> > >> > >> > >> On Fri, Nov 15, 2013 at 11:05 AM, Frédéric Bastien <no...@nouiz.org> > >> wrote: > >>> > >>> I found a line like this in the file: > >>> > >>> numpy/distutils/fcompiler/__init__.py > >>> > >>> I changed the -2 to 2, but it didn't change anything. In fact, this > >>> line wasn't called. > >>> > >>> The fct set_verbosity() is called only once, with the value of 0. The > >>> default value set at import. If I change that to 2 or -2, it do not > >>> change anything. > >>> > >>> I think that the problem is related to the exec_command as you told. > >>> It seam it call it in a way that don't take the stdout/stderr set in > >>> Python. So I can't redirect it. The problem is that is use os.system() > >>> and we can't redirect its stdout/stderr. > >>> > >>> What about replacing the os.system call to subprocess.Popen? This > >>> would allow us to catch the stdout/stderr. We use this call in Theano > >>> and it is compatible with python 2.4. > >>> > >> > >> Numpy 1.8 doesn't support python 2.4 in any case, so that isn't a > problem > >> ;) > >> > >> Sure, give it a shot. Looks like subprocess.Popen was intended to > replace > >> os.system in any case. > > > > > > Except that output is not 'real time' with straight Popen, and doing so > > reliably on every platform (cough - windows - cough) is not completely > > trivial. You also have to handle buffered output, etc... That code is > very > > fragile, so this would be quite a lot of testing to change, and I am not > > sure it worths it. > > > > David > > > > _______________________________________________ > > 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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
