Robert Bradshaw <robertwb-g7kksM1vlZHtJv9D6sJWnpVzexx5G...@public.gmane.org> writes: > See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only > release, we hope to get it out shortly.
0.15 compiles cleanly here, but 0.15.1rc0 says:
====================================================================== ERROR: compiling (cpp) and running tupleunpack_T712 ---------------------------------------------------------------------- Traceback (most recent call last): File "runtests.py", line 678, in run self.runCompileTest() File "runtests.py", line 490, in runCompileTest self.test_directory, self.expect_errors, self.annotate) File "runtests.py", line 665, in compile self.run_distutils(test_directory, module, workdir, incdir) File "runtests.py", line 625, in run_distutils build_extension.run() File "/usr/lib/python2.6/distutils/command/build_ext.py", line 340, in run self.build_extensions() File "/usr/lib/python2.6/distutils/command/build_ext.py", line 449, in build_extensions self.build_extension(ext) File "runtests.py", line 257, in build_extension _build_ext.build_extension(self, ext) File "/usr/lib/python2.6/distutils/command/build_ext.py", line 499, in build_extension depends=ext.depends) File "/usr/lib/python2.6/distutils/ccompiler.py", line 621, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/usr/lib/python2.6/distutils/unixccompiler.py", line 180, in _compile raise CompileError, msg CompileError: command 'gcc' failed with exit status 1
---------------------------------------------------------------------- Ran 5555 tests in 841.410s
FAILED (errors=1) ALL DONE
Best,
-Nikolaus
-- »Time flies like an arrow, fruit flies like a Banana.«
Stefan Behnel <stefan...@behnel.de> writes: > Nikolaus Rath, 17.09.2011 01:10: >> Robert Bradshaw writes: >>> See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only >>> release, we hope to get it out shortly.
>> 0.15 compiles cleanly here, but 0.15.1rc0 says:
>> ====================================================================== >> ERROR: compiling (cpp) and running tupleunpack_T712 >> ---------------------------------------------------------------------- >> Ran 5555 tests in 841.410s
>> FAILED (errors=1) >> ALL DONE
> Right, thanks. That was a forgotten cherry-pick for the release > branch, it's already fixed and will be in 0.15.1 final.
Could we get an updated rc1 tarball for testing?
Thanks,
-Nikolaus
-- »Time flies like an arrow, fruit flies like a Banana.«
> Stefan Behnel writes: >> Nikolaus Rath, 17.09.2011 01:10: >>> Robert Bradshaw writes: >>>> See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only >>>> release, we hope to get it out shortly.
>>> 0.15 compiles cleanly here, but 0.15.1rc0 says:
>>> ====================================================================== >>> ERROR: compiling (cpp) and running tupleunpack_T712 >>> ---------------------------------------------------------------------- >>> Ran 5555 tests in 841.410s
>>> FAILED (errors=1) >>> ALL DONE
>> Right, thanks. That was a forgotten cherry-pick for the release >> branch, it's already fixed and will be in 0.15.1 final.
> Could we get an updated rc1 tarball for testing?
You can try this one, which was built from the fixed release branch:
For what it's worth, attached are results of runtests.py on Windows 7 64-bit running 32-bit Python 2.7: "Ran 2299 tests in 671.472s FAILED (failures=2, errors=840)". Despite the numerous test failures, the doctests in my own code are working as well as ever with this latest version of Cython.
By the way, would it be possible to make Git tags for the release candidates too? Currently there's a 0.15rc0, 0.15rc1, 0.15rc2, and 0.15, but no "0.15.1rc..." as far as I can see. That would make it convenient to "git checkout" different versions, run runtests.py and diff the output.
============================= Found executable C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe Python 2.7.2 |EPD 7.1-1 (32-bit)| (default, Jul 3 2011, 15:13:59) [MSC v.1500 32 bit (Intel)] Running tests against Cython 0.15+ f81c0b0b2cf49bd07dafb1890f78a420b2791758 [...] ---------------------------------------------------------------------- Ran 2299 tests in 671.472s FAILED (failures=2, errors=840) Following tests excluded because of missing dependencies on your system: compile.posix_pxds run.posix_test ============================= (gcc.exe crashes once during the tests.)
> For what it's worth, attached are results of runtests.py on Windows 7 > 64-bit running 32-bit Python 2.7: "Ran 2299 tests in 671.472s > FAILED (failures=2, errors=840)". Despite the numerous test failures, > the doctests in my own code are working as well as ever with this > latest version of Cython.
> By the way, would it be possible to make Git tags for the release > candidates too? Currently there's a 0.15rc0, 0.15rc1, 0.15rc2, and > 0.15, but no "0.15.1rc..." as far as I can see. That would make it > convenient to "git checkout" different versions, run runtests.py and > diff the output.
On Sep 18, 12:48 pm, mark florisson <markflorisso...@gmail.com> wrote:
> > Ran 2299 tests in 671.472s
> > FAILED (failures=2, errors=840)
> Hm, for some reason all your tests are failing with "OSError: [Errno
> 24] Too many open files". Did you change any rlimits?
I'd be delighted if you could help me figure this out. Having googled
rlimits, I'm not sure such resource limits are configurable on
Windows. In this thread there is mention of a limit of 512 files (509
+ stdin, stdout, stderr), which I can confirm on my system (session
quoted below).
Does runtests.py really intend to open more than 509 files?
... while True:
... L.append(open("c:/temp/test{}".format(len(L)), "w"))
... finally:
... print "Number of open files:", len(L)
... for f in L:
... f.close()
...
Number of open files: 509
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
IOError: [Errno 24] Too many open files: 'c:/temp/test509'
> On Sep 18, 12:48 pm, mark florisson <markflorisso...@gmail.com> wrote: >> > Ran 2299 tests in 671.472s >> > FAILED (failures=2, errors=840)
>> Hm, for some reason all your tests are failing with "OSError: [Errno >> 24] Too many open files". Did you change any rlimits?
> I'd be delighted if you could help me figure this out. Having googled > rlimits, I'm not sure such resource limits are configurable on > Windows. In this thread there is mention of a limit of 512 files (509 > + stdin, stdout, stderr), which I can confirm on my system (session > quoted below).
> Does runtests.py really intend to open more than 509 files?
> Jon Olav
No that's way too many. I assume that something is up with the test runner and that it's not closing tempfiles properly or something like that. I'll try running it on my OSX machine (which has an even lower limit).
>>>> L = [] >>>> try: > ... while True: > ... L.append(open("c:/temp/test{}".format(len(L)), "w")) > ... finally: > ... print "Number of open files:", len(L) > ... for f in L: > ... f.close() > ... > Number of open files: 509 > Traceback (most recent call last): > File "<stdin>", line 3, in <module> > IOError: [Errno 24] Too many open files: 'c:/temp/test509'
> On 18 September 2011 12:22, Jon Olav Vik <jono...@gmail.com> wrote: >> On Sep 18, 12:48 pm, mark florisson <markflorisso...@gmail.com> wrote: >>> > Ran 2299 tests in 671.472s >>> > FAILED (failures=2, errors=840)
>>> Hm, for some reason all your tests are failing with "OSError: [Errno >>> 24] Too many open files". Did you change any rlimits?
>> I'd be delighted if you could help me figure this out. Having googled >> rlimits, I'm not sure such resource limits are configurable on >> Windows. In this thread there is mention of a limit of 512 files (509 >> + stdin, stdout, stderr), which I can confirm on my system (session >> quoted below).
>> Does runtests.py really intend to open more than 509 files?
>> Jon Olav
> No that's way too many. I assume that something is up with the test > runner and that it's not closing tempfiles properly or something like > that. I'll try running it on my OSX machine (which has an even lower > limit).
>>>>> L = [] >>>>> try: >> ... while True: >> ... L.append(open("c:/temp/test{}".format(len(L)), "w")) >> ... finally: >> ... print "Number of open files:", len(L) >> ... for f in L: >> ... f.close() >> ... >> Number of open files: 509 >> Traceback (most recent call last): >> File "<stdin>", line 3, in <module> >> IOError: [Errno 24] Too many open files: 'c:/temp/test509'
It runs fine for me so far, perhaps you could run runtests with -vv to see at which point the tests start failing. Other than that I have no clue, I don't use windows, sorry.
On Sep 18, 1:47 pm, mark florisson <markflorisso...@gmail.com> wrote:
> >>> > Ran 2299 tests in 671.472s > >>> > FAILED (failures=2, errors=840)
> >>> Hm, for some reason all your tests are failing with "OSError: [Errno > >>> 24] Too many open files". [...] > > I assume that something is up with the test
> > runner and that it's not closing tempfiles properly or something like > > that. I'll try running it on my OSX machine (which has an even lower > > limit).
> It runs fine for me so far, perhaps you could run runtests with -vv to > see at which point the tests start failing. Other than that I have no > clue, I don't use windows, sorry.
I attach the output of python runtests.py --compiler=mingw32 --no-refnanny -vv > vv.txt 2>&1
> On Sep 18, 1:47 pm, mark florisson <markflorisso...@gmail.com> wrote: >> >>> > Ran 2299 tests in 671.472s >> >>> > FAILED (failures=2, errors=840)
>> >>> Hm, for some reason all your tests are failing with "OSError: [Errno >> >>> 24] Too many open files". > [...] >> > I assume that something is up with the test > > > runner and that it's not closing tempfiles properly or something like > > > that. I'll try running it on my OSX machine (which has an even lower > > > limit).
>> It runs fine for me so far, perhaps you could run runtests with -vv to >> see at which point the tests start failing. Other than that I have no >> clue, I don't use windows, sorry.
> I attach the output of > python runtests.py --compiler=mingw32 --no-refnanny -vv > vv.txt 2>&1
> I'm afraid I don't know where to look for clues.
> Jon Olav
Thanks. My uninformed guess would be that each doctest that's run somehow leaves it's file (or module) open, but looking at the source the modules should be purged immediately from sys.modules. Stefan and Robert wrote most of the testrunner, maybe they will have better ideas.
> From my POV, this build looks good enough for a release.
> Stefan
I found a num_threads bug for prange, I'd like to include a fix for that. How do I get it in both master and release? Can I add it to release and then merge release in master?
>> From my POV, this build looks good enough for a release.
>> Stefan
> I found a num_threads bug for prange, I'd like to include a fix for > that. How do I get it in both master and release? Can I add it to > release and then merge release in master?
I didn't actually look at it, but I saw Stefan mention he cherry-picked commits over. If so, one can not merge release into master (at least without a lot of hassle or commits showing up twice). You should commit to master and then cherry-pick to release.
After the release, the 'release' branch should be discarded (or just renamed 0.15.1, and never be touched again). Personally I think this is OK and reflects the development process.
>>> From my POV, this build looks good enough for a release.
>>> Stefan
>> I found a num_threads bug for prange, I'd like to include a fix for >> that. How do I get it in both master and release? Can I add it to >> release and then merge release in master?
> I didn't actually look at it, but I saw Stefan mention he cherry-picked > commits over. If so, one can not merge release into master (at least without > a lot of hassle or commits showing up twice). You should commit to master > and then cherry-pick to release.
> After the release, the 'release' branch should be discarded (or just renamed > 0.15.1, and never be touched again). Personally I think this is OK and > reflects the development process.
>>>> From my POV, this build looks good enough for a release.
>>>> Stefan
>>> I found a num_threads bug for prange, I'd like to include a fix for >>> that. How do I get it in both master and release? Can I add it to >>> release and then merge release in master?
>> I didn't actually look at it, but I saw Stefan mention he cherry-picked >> commits over. If so, one can not merge release into master (at least without >> a lot of hassle or commits showing up twice). You should commit to master >> and then cherry-pick to release.
>> After the release, the 'release' branch should be discarded (or just renamed >> 0.15.1, and never be touched again). Personally I think this is OK and >> reflects the development process.
>>> From my POV, this build looks good enough for a release.
>>> Stefan
>> I found a num_threads bug for prange, I'd like to include a fix for >> that. How do I get it in both master and release? Can I add it to >> release and then merge release in master?
> I didn't actually look at it, but I saw Stefan mention he cherry-picked > commits over. If so, one can not merge release into master (at least without > a lot of hassle or commits showing up twice). You should commit to master > and then cherry-pick to release.
> After the release, the 'release' branch should be discarded (or just renamed > 0.15.1, and never be touched again). Personally I think this is OK and > reflects the development process.
This is unfortunate as it will break "make repo" or syncing to a specific release. I'll try to merge them if it's not too painful. Assuming the release branch is a proper subset of the main branch, that should be feasible.
FYI, I'm planning on pushing the release out later today, I'll keep an eye out for that last fix.
<rober...@math.washington.edu> wrote: > On Mon, Sep 19, 2011 at 2:23 PM, Dag Sverre Seljebotn > <d.s.seljeb...@astro.uio.no> wrote: >> On 09/19/2011 11:06 PM, mark florisson wrote:
>>> On 17 September 2011 19:02, Stefan Behnel<stefan...@behnel.de> wrote:
>>>> From my POV, this build looks good enough for a release.
>>>> Stefan
>>> I found a num_threads bug for prange, I'd like to include a fix for >>> that. How do I get it in both master and release? Can I add it to >>> release and then merge release in master?
>> I didn't actually look at it, but I saw Stefan mention he cherry-picked >> commits over. If so, one can not merge release into master (at least without >> a lot of hassle or commits showing up twice). You should commit to master >> and then cherry-pick to release.
>> After the release, the 'release' branch should be discarded (or just renamed >> 0.15.1, and never be touched again). Personally I think this is OK and >> reflects the development process.
> This is unfortunate as it will break "make repo" or syncing to a > specific release. I'll try to merge them if it's not too painful. > Assuming the release branch is a proper subset of the main branch, > that should be feasible.
> FYI, I'm planning on pushing the release out later today, I'll keep an > eye out for that last fix.
> - Robert
It's in, maybe a good idea to wait for hudson to stay blue.
