Cython 0.15.1 release candidate

[Robert Bradshaw]

See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only
release, we hope to get it out shortly.

- Robert

[Nikolaus Rath]

Robert Bradshaw <robertwb-g7kksM1vlZH...@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.«

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

[Stefan Behnel]

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.

Stefan

[Nikolaus Rath]

Could we get an updated rc1 tarball for testing?

Thanks,

[Stefan Behnel]

Nikolaus Rath, 17.09.2011 02:20:

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

https://sage.math.washington.edu:8091/hudson/job/cython-release-sdist/10/artifact/dist/Cython-0.15.1.tar.gz

or, more generally, the latest sdist from the release branch (currently the
same as the above):

https://sage.math.washington.edu:8091/hudson/job/cython-release-sdist/

From my POV, this build looks good enough for a release.

Stefan

[Robert Bradshaw]

Excellent.

- Robert

[Jon Olav Vik]

On Sep 17, 8:02 pm, Stefan Behnel <stefan...@behnel.de> wrote:
> > Could we get an updated rc1tarballfor testing?

> You can try this one, which was built from the fixed release branch:

> https://sage.math.washington.edu:8091/hudson/job/cython-release-sdist...

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.

c:\git\cython>gcc --version
gcc (GCC) 4.5.0
c:\git\cython>gdb --version
GNU gdb (GDB) 7.2
c:\git\cython>python runtests.py --compiler=mingw32 --no-refnanny >
runtests.txt 2>&1

=============================
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.)

The full output is attached as a zip file.

Best regards,
Jon Olav

[mark florisson]

Hm, for some reason all your tests are failing with "OSError: [Errno
24] Too many open files". Did you change any rlimits?

[Jon Olav Vik]

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




http://forums.devx.com/archive/index.php/t-136946.html

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

[mark florisson]

On 18 September 2011 12:22, Jon Olav Vik <jon...@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).

[mark florisson]

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.

[Jon Olav Vik]

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

[mark florisson]

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.

[mark florisson]

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?

[Dag Sverre Seljebotn]

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.

Dag Sverre

[mark florisson]

On 19 September 2011 22:23, Dag Sverre Seljebotn

Ok, I'll do that. Thanks Dag!

[mark florisson]

Ok that was easy :)

[Robert Bradshaw]

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

[mark florisson]

On 19 September 2011 23:03, Robert Bradshaw

It's in, maybe a good idea to wait for hudson to stay blue.