[SciPy-Dev] request for testing: SciPy 0.7.2 RC1 + NumPy 1.4.1 RC1
josef.pktd at gmail.com
josef.pktd at gmail.com
Wed Apr 7 13:00:57 EDT 2010
On Wed, Apr 7, 2010 at 12:31 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Wed, Apr 7, 2010 at 11:04 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Wed, Apr 7, 2010 at 10:52 AM, Ralf Gommers
>> <ralf.gommers at googlemail.com> wrote:
>> >
>> >
>> > On Wed, Apr 7, 2010 at 4:03 AM, <josef.pktd at gmail.com> wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 3:44 PM, Bruce Southey <bsouthey at 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
More information about the SciPy-Dev
mailing list