[SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1

Ralf Gommers ralf.gommers@googlemail....
Wed Apr 7 11:31:05 CDT 2010


On Wed, Apr 7, 2010 at 11:04 PM, <josef.pktd@gmail.com> wrote:

> On Wed, Apr 7, 2010 at 10:52 AM, Ralf Gommers
> <ralf.gommers@googlemail.com> wrote:
> >
> >
> > On Wed, Apr 7, 2010 at 4:03 AM, <josef.pktd@gmail.com> wrote:
> >>
> >> On Tue, Apr 6, 2010 at 3:44 PM, Bruce Southey <bsouthey@gmail.com>
> wrote:
> >> >
> >> > Hi,
> >> > What scipy svn version was the release candidate obtained?
> >> >
> >> > The reason is that I tracked down the warning messages for some of the
> >> > stats
> >> > tests that were addressed 15 months ago by changeset 5396 (time stamp
> of
> >> > '01/08/09 06:38:03'):
> >> > http://projects.scipy.org/scipy/changeset/5396
> >
> >
> > Thanks for tracking that down, I'll backport those changes.
>
> don't backport the *raising* of the DepreciationWarning, it's supposed
> to be a warning and not an exception in 0.7   It hasn't been
> backported intentionally.
>

OK. Everything else is okay though right?

>
>
> according to python help subprocess raises an exception when the
> command fails, which needs to be caught by the user, i.e.
>
> name='gcc2'
> cmd=[str(name), '-v']
>
> try:
>    ret = subprocess.call(cmd)
>    print ret
> except OSError:
>    print 'call failed', name
>
> Yes, and the function tries that. I missed the fact that Bruce's example
doesn't however. This still leaves the annoying warnings and the broken
function itself.

I found that specifying shell=True:
>>> subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
does not raise a WindowsError, so I suspect it will also fix the warnings.
This breaks things on OS X however:
>>> subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
...         stderr=subprocess.STDOUT).stdout.read()
'i686-apple-darwin10-gcc-4.2.1: no input files\n'
>>> subprocess.Popen(cmd, shell=False, stdout=subprocess.PIPE,
...         stderr=subprocess.STDOUT).stdout.read()
'Using built-in specs.\nTarget: i686-apple-darwin10\nConfigured with:
/var/tmp/gcc/gcc-5646~6
<snip>

So to fix the warnings, we can use shell=True on Windows and shell=False on
other platforms. Ugly, I know, but does anyone mind?

To fix the function, comparing str_result with 'spec' instead of 'Reading
specs' fixes the issue for me and should work on windows as well.

Cheers,
Ralf


Current code:

def gcc_exists(name = 'gcc'):
    """ Test to make sure gcc is found

        Does this return correct value on win98???
    """
    result = 0
    cmd = [str(name), '-v']
    try:
        p = subprocess.Popen(cmd, True, stdout=subprocess.PIPE,
                stderr=subprocess.STDOUT)
        str_result = p.stdout.read()
        #print str_result
        if 'Reading specs' in str_result:
            result = 1
    except:
        # This was needed because the msvc compiler messes with
        # the path variable. and will occasionlly mess things up
        # so much that gcc is lost in the path. (Occurs in test
        # scripts)
        result = not os.system(" ".join(cmd))
    return result


Fixed:

def gcc_exists(name='gcc'):
    """ Test to make sure gcc is found."""
    result = 0
    cmd = [str(name), '-v']
    try:
        if sys.platform == 'win32':
            p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,
                                 stderr=subprocess.STDOUT)
        else:
            p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
                                 stderr=subprocess.STDOUT)
        str_result = p.stdout.read()
        if 'specs' in str_result:
            result = 1
    except:
        # This was needed because the msvc compiler messes with
        # the path variable. and will occasionlly mess things up
        # so much that gcc is lost in the path. (Occurs in test
        # scripts)
        result = not os.system(" ".join(cmd))
    return result
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20100408/4049d81b/attachment.html 


More information about the SciPy-Dev mailing list