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

josef.pktd@gmai... josef.pktd@gmai...
Wed Apr 7 12:00:57 CDT 2010


On Wed, Apr 7, 2010 at 12:31 PM, Ralf Gommers
<ralf.gommers@googlemail.com> wrote:
>
>
> 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?

It looks ok, but I don't think it is a good idea to backport changes
that are not really necessary. There is always a small chance that
there was a mistake or incompatibility in the changeset that got
changed later. I don't think that's the case, but I did several
followup removal of calls to the depreciated/removed stats functions.

At this stage, I would just release numpy and scipy (if they work) and
leave cleaning up noisy output and warnings for the next release. (I
don't have python 2.6, so I haven't tested it yet)

>>
>>
>> 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

I'm not sure about this. My impression is that the except part
result = not os.system(" ".join(cmd))

is doing the printing, not subprocess

>>> os.system("gcc2 -v")
'gcc2' is not recognized as an internal or external command,
operable program or batch file.
1

Josef


>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


More information about the SciPy-Dev mailing list