Vitja Makarov, 15.10.2011 11:26:
Recent commits to the master introduced pyregr regressions. You can
see it here, just sort by age:
https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/BACKEND=c,PYVERSION=py27/33/testReport/
I fixed the ones I had introduced, thanks for noting.
Here is one example:
======================================================================
ERROR: runTest (__main__.CythonPyregrTestCase)
compiling (c) and running test_pipes
----------------------------------------------------------------------
Traceback (most recent call last):
File "runtests.py", line 679, in run
self.runCompileTest()
File "runtests.py", line 491, in runCompileTest
self.test_directory, self.expect_errors, self.annotate)
File "runtests.py", line 656, in compile
self.assertEquals(None, unexpected_error)
AssertionError: None != u"39:14: Object of type '<unspecified>' has no
attribute 'open'"
Not sure where that comes from, looks like a type inference bug.
May be it's a good idea to check for pyregr regressions as well as for
regular tests failures before merging into master?
Well, sure. The problem is that it's much easier to see when a test turns
from blue to yellow or red, than it is to see that a test turns from yellow
to, well, yellow.
I agree that it's generally worth looking through the results after a push
and especially after a merge. Jenkins quite prominently complains about
additional test failures in the build history:
https://sage.math.washington.edu:8091/hudson/view/cython-devel/builds
Throwing an eye on that page after the build/test jobs have run should help
in spotting most regressions.
Stefan
_______________________________________________
cython-devel mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cython-devel
