Since there was opposition to just removing the output all the time, I've added a new parameter, 'verbosity' that can be set to 0 to hide the output. This unfortunately requires a bit of code churn and changes the interface to get_info() (but in a backwards-compatible way).
I came up with another option, which is to reuse system_info.verbosity to control whether that output is shown/hidden. It is already documented as doing so even if that is mostly ignored in the code. I've made another PR https://github.com/numpy/numpy/pull/4387 to show what I mean. This would supersede #4081 if accepted. 2013-11-27 13:44 GMT-05:00 Frédéric Bastien <no...@nouiz.org>: > Hi, > > After more investigation, I found that there already exist a way to > suppress those message on posix system. So I reused it in the PR. That > way, it was faster, but prevent change in that area. So there is less > change of breaking other syste: > > https://github.com/numpy/numpy/pull/4081 > > > But it remove the stdout when we run this command: > > numpy.distutils.system_info.get_info("blas_opt") > > But during compilation, we still have the info about what is found: > > atlas_blas_threads_info: > Setting PTATLAS=ATLAS > Setting PTATLAS=ATLAS > customize Gnu95FCompiler > Found executable /usr/bin/gfortran > customize Gnu95FCompiler > customize Gnu95FCompiler using config > compiling '_configtest.c': > > /* This file is generated from numpy/distutils/system_info.py */ > void ATL_buildinfo(void); > int main(void) { > ATL_buildinfo(); > return 0; > } > > C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -fPIC > > compile options: '-c' > gcc: _configtest.c > gcc -pthread _configtest.o -L/usr/lib64/atlas -lptf77blas -lptcblas > -latlas -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > Setting PTATLAS=ATLAS > FOUND: > libraries = ['ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > language = c > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > include_dirs = ['/usr/include'] > > FOUND: > libraries = ['ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > language = c > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > include_dirs = ['/usr/include'] > > non-existing path in 'numpy/lib': 'benchmarks' > lapack_opt_info: > lapack_mkl_info: > mkl_info: > libraries mkl,vml,guide not found in > ['/opt/lisa/os_v2/common/Canopy_64bit/User/lib', '/usr/local/lib64', > '/usr/local/lib', '/usr/lib64', '/usr/lib'] > NOT AVAILABLE > > NOT AVAILABLE > > atlas_threads_info: > Setting PTATLAS=ATLAS > libraries ptf77blas,ptcblas,atlas not found in > /opt/lisa/os_v2/common/Canopy_64bit/User/lib > libraries lapack_atlas not found in > /opt/lisa/os_v2/common/Canopy_64bit/User/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib64 > libraries lapack_atlas not found in /usr/local/lib64 > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/lib64/atlas > numpy.distutils.system_info.atlas_threads_info > Setting PTATLAS=ATLAS > Setting PTATLAS=ATLAS > FOUND: > libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > language = f77 > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > include_dirs = ['/usr/include'] > > FOUND: > libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > language = f77 > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > include_dirs = ['/usr/include'] > > Frédéric > > On Fri, Nov 22, 2013 at 4:26 PM, Frédéric Bastien <no...@nouiz.org> wrote: > > I didn't forgot this, but I got side tracked. Here is the Theano code > > I would like to try to use to replace os.system: > > > > https://github.com/Theano/Theano/blob/master/theano/misc/windows.py > > > > But I won't be able to try this before next week. > > > > Fred > > > > On Fri, Nov 15, 2013 at 5:49 PM, David Cournapeau <courn...@gmail.com> > wrote: > >> > >> > >> > >> On Fri, Nov 15, 2013 at 7:41 PM, Robert Kern <robert.k...@gmail.com> > wrote: > >>> > >>> On Fri, Nov 15, 2013 at 7: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: > >>> > >>> >> 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. > >>> > >>> It doesn't have to be "real time". Just use .communicate() and print > out > >>> the stdout and stderr to their appropriate streams after the subprocess > >>> finishes. > >> > >> > >> Indeed, it does not have to be, but that's useful for debugging > compilation > >> issues (not so much for numpy itself, but for some packages which have > files > >> that takes a very long time to build, like scipy.sparsetools or > bottleneck). > >> > >> That's a minor point compared to the potential issues when building on > >> windows, though. > >> > >> 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
