From lists at onerussian.com Mon Dec 3 17:23:20 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 3 Dec 2012 11:23:20 -0500 Subject: [Cython] Cython 0.17.2 released In-Reply-To: <50ABED53.8070104@behnel.de> References: <50ABED53.8070104@behnel.de> Message-ID: <20121203162320.GH7431@onerussian.com> shouldn't there be http://wiki.cython.org/ReleaseNotes-0.17.2 ? ;-) > Complete changelog: > 0.17.2 (2012-11-20) > =================== > Features added > -------------- > * ``cythonize()`` gained a best effort compile mode that can be used to > simply ignore .py files that fail to compile. > Bugs fixed > ---------- > * Replacing an object reference with the value of one of its cdef > attributes could generate incorrect C code that accessed the object after > deleting its last reference. > * C-to-Python type coercions during cascaded comparisons could generate > invalid C code, specifically when using the 'in' operator. > * "obj[1,]" passed a single integer into the item getter instead of a tuple. > * Cyclic imports at module init time did not work in Py3. > * The names of C++ destructors for template classes were built incorrectly. > * In pure mode, type casts in Cython syntax and the C ampersand operator > are now rejected. Use the pure mode replacements instead. > * In pure mode, C type names and the sizeof() function are no longer > recognised as such and can be used as normal Python names. > * The extended C level support for the CPython array type was declared too > late to be used by user defined classes. > * C++ class nesting was broken. > * Better checking for required nullary constructors for stack-allocated C++ > instances. > * Remove module docstring in no-docstring mode. > * Fix specialization for varargs function signatures. > * Fix several compiler crashes. -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From lists at onerussian.com Mon Dec 3 17:19:17 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 3 Dec 2012 11:19:17 -0500 Subject: [Cython] Cython 0.17.2 released In-Reply-To: <50ABED53.8070104@behnel.de> References: <50ABED53.8070104@behnel.de> Message-ID: <20121203161917.GG7431@onerussian.com> congrats! please do not forget to push git tag for 0.17.2 ;) On Tue, 20 Nov 2012, Stefan Behnel wrote: > Hi everyone, > I'm happy to announce the release of Cython 0.17.2. This is a (mostly) bug > fix release for the stable 0.17 release series. > http://pypi.python.org/pypi/Cython/0.17.2 > Direct downloads: > http://cython.org/release/Cython-0.17.2.tar.gz > http://cython.org/release/Cython-0.17.2.zip > Github version: > https://github.com/cython/cython/commit/10183d61eb5cf33e6912dec2ab09740498f0947c > Have fun, > Stefan > Complete changelog: > 0.17.2 (2012-11-20) > =================== > Features added > -------------- > * ``cythonize()`` gained a best effort compile mode that can be used to > simply ignore .py files that fail to compile. > Bugs fixed > ---------- > * Replacing an object reference with the value of one of its cdef > attributes could generate incorrect C code that accessed the object after > deleting its last reference. > * C-to-Python type coercions during cascaded comparisons could generate > invalid C code, specifically when using the 'in' operator. > * "obj[1,]" passed a single integer into the item getter instead of a tuple. > * Cyclic imports at module init time did not work in Py3. > * The names of C++ destructors for template classes were built incorrectly. > * In pure mode, type casts in Cython syntax and the C ampersand operator > are now rejected. Use the pure mode replacements instead. > * In pure mode, C type names and the sizeof() function are no longer > recognised as such and can be used as normal Python names. > * The extended C level support for the CPython array type was declared too > late to be used by user defined classes. > * C++ class nesting was broken. > * Better checking for required nullary constructors for stack-allocated C++ > instances. > * Remove module docstring in no-docstring mode. > * Fix specialization for varargs function signatures. > * Fix several compiler crashes. > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > http://mail.python.org/mailman/listinfo/cython-devel -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From lists at onerussian.com Mon Dec 3 22:10:07 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 3 Dec 2012 16:10:07 -0500 Subject: [Cython] (no subject) Message-ID: <20121203211007.GI7431@onerussian.com> reproduced with cython 0.17.2 (+ few post release fixes), originally detected/reported [1] with 0.17.1 on Debian systems using debug build of Python: $> python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; s=weakfail.foo(42)' python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. [1] 12648 abort python-dbg -c $> cat weakfail.pyx import weakref foo_dict = weakref.WeakValueDictionary() cdef class Foo: cdef object __weakref__ def foo(key): obj = Foo() foo_dict[key] = obj return obj it seems to work fine with cython 0.15.2 . Any ideas? requires separate/new bug report? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692313 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From lists at onerussian.com Mon Dec 3 22:37:43 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 3 Dec 2012 16:37:43 -0500 Subject: [Cython] python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion `gc->gc.gc_refs != 0' failed In-Reply-To: <20121203211007.GI7431@onerussian.com> References: <20121203211007.GI7431@onerussian.com> Message-ID: <20121203213743.GJ7431@onerussian.com> pardon the initial absence of subject On Mon, 03 Dec 2012, Yaroslav Halchenko wrote: > reproduced with cython 0.17.2 (+ few post release fixes), originally > detected/reported [1] with 0.17.1 on Debian systems using debug build of > Python: > $> python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; s=weakfail.foo(42)' > python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. > [1] 12648 abort python-dbg -c > $> cat weakfail.pyx > import weakref > foo_dict = weakref.WeakValueDictionary() > cdef class Foo: > cdef object __weakref__ > def foo(key): > obj = Foo() > foo_dict[key] = obj > return obj > it seems to work fine with cython 0.15.2 . Any ideas? requires separate/new bug report? > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692313 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From brad.froehle at gmail.com Mon Dec 3 22:45:28 2012 From: brad.froehle at gmail.com (Bradley M. Froehle) Date: Mon, 3 Dec 2012 13:45:28 -0800 Subject: [Cython] (no subject) In-Reply-To: <20121203211007.GI7431@onerussian.com> References: <20121203211007.GI7431@onerussian.com> Message-ID: I ran `git bisect`: d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 is the first bad commit commit d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 Author: Mark Florisson Date: Tue Apr 10 15:01:00 2012 +0100 Decref memoryview slice class attributes https://github.com/cython/cython/commit/d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 -Brad On Mon, Dec 3, 2012 at 1:10 PM, Yaroslav Halchenko wrote: > reproduced with cython 0.17.2 (+ few post release fixes), originally > detected/reported [1] with 0.17.1 on Debian systems using debug build of > Python: > > $> python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; > s=weakfail.foo(42)' > python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion > `gc->gc.gc_refs != 0' failed. > [1] 12648 abort python-dbg -c > > $> cat weakfail.pyx > import weakref > foo_dict = weakref.WeakValueDictionary() > > cdef class Foo: > cdef object __weakref__ > > def foo(key): > obj = Foo() > foo_dict[key] = obj > return obj > > > it seems to work fine with cython 0.15.2 . Any ideas? requires > separate/new bug report? > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692313 > -- > Yaroslav O. Halchenko > Postdoctoral Fellow, Department of Psychological and Brain Sciences > Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 > Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 > WWW: http://www.linkedin.com/in/yarik > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > http://mail.python.org/mailman/listinfo/cython-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at onerussian.com Wed Dec 5 17:54:26 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Wed, 5 Dec 2012 11:54:26 -0500 Subject: [Cython] (no subject) In-Reply-To: References: <20121203211007.GI7431@onerussian.com> Message-ID: <20121205165426.GL7431@onerussian.com> Thank you Bradley, This was easy enough even so that I could fix it (I think) -- just a typo: https://github.com/cython/cython/pull/165 feedback would be welcome ;) On Mon, 03 Dec 2012, Bradley M. Froehle wrote: > I ran `git bisect`: > d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 is the first bad commit > commit d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 > Author: Mark Florisson <[1]markflorisson88 at gmail.com> > Date: ? Tue Apr 10 15:01:00 2012 +0100 > ? ? Decref memoryview slice class attributes > [2]https://github.com/cython/cython/commit/d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 > -Brad > On Mon, Dec 3, 2012 at 1:10 PM, Yaroslav Halchenko > <[3]lists at onerussian.com> wrote: > reproduced with cython 0.17.2 (+ few post release fixes), originally > detected/reported [1] with ?0.17.1 on Debian systems using debug build > of > Python: > $> python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; > s=weakfail.foo(42)' > python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion > `gc->gc.gc_refs != 0' failed. > [1] ? ?12648 abort ? ? ?python-dbg -c > $> cat weakfail.pyx > import weakref > foo_dict = weakref.WeakValueDictionary() > cdef class Foo: > ? ? cdef object __weakref__ > def foo(key): > ? ? obj = Foo() > ? ? foo_dict[key] = obj > ? ? return obj > it seems to work fine with cython 0.15.2 . ?Any ideas? ?requires > separate/new bug report? > [1] [4]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692313 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From markflorisson88 at gmail.com Wed Dec 5 18:11:06 2012 From: markflorisson88 at gmail.com (mark florisson) Date: Wed, 5 Dec 2012 17:11:06 +0000 Subject: [Cython] (no subject) In-Reply-To: <20121205165426.GL7431@onerussian.com> References: <20121203211007.GI7431@onerussian.com> <20121205165426.GL7431@onerussian.com> Message-ID: On 5 December 2012 16:54, Yaroslav Halchenko wrote: > Thank you Bradley, > > This was easy enough even so that I could fix it (I think) -- just a > typo: > > https://github.com/cython/cython/pull/165 > > feedback would be welcome ;) > > On Mon, 03 Dec 2012, Bradley M. Froehle wrote: > >> I ran `git bisect`: >> d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 is the first bad commit >> commit d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 >> Author: Mark Florisson <[1]markflorisson88 at gmail.com> >> Date: ? Tue Apr 10 15:01:00 2012 +0100 >> ? ? Decref memoryview slice class attributes >> [2]https://github.com/cython/cython/commit/d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 >> -Brad >> On Mon, Dec 3, 2012 at 1:10 PM, Yaroslav Halchenko >> <[3]lists at onerussian.com> wrote: > >> reproduced with cython 0.17.2 (+ few post release fixes), originally >> detected/reported [1] with ?0.17.1 on Debian systems using debug build >> of >> Python: > >> $> python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; >> s=weakfail.foo(42)' >> python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion >> `gc->gc.gc_refs != 0' failed. >> [1] ? ?12648 abort ? ? ?python-dbg -c > >> $> cat weakfail.pyx >> import weakref >> foo_dict = weakref.WeakValueDictionary() > >> cdef class Foo: >> ? ? cdef object __weakref__ > >> def foo(key): >> ? ? obj = Foo() >> ? ? foo_dict[key] = obj >> ? ? return obj > >> it seems to work fine with cython 0.15.2 . ?Any ideas? ?requires >> separate/new bug report? > >> [1] [4]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692313 > -- > Yaroslav O. Halchenko > Postdoctoral Fellow, Department of Psychological and Brain Sciences > Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 > Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 > WWW: http://www.linkedin.com/in/yarik > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > http://mail.python.org/mailman/listinfo/cython-devel Thanks, I merged it. From markflorisson88 at gmail.com Wed Dec 5 18:12:33 2012 From: markflorisson88 at gmail.com (mark florisson) Date: Wed, 5 Dec 2012 17:12:33 +0000 Subject: [Cython] (no subject) In-Reply-To: References: <20121203211007.GI7431@onerussian.com> <20121205165426.GL7431@onerussian.com> Message-ID: On 5 December 2012 17:11, mark florisson wrote: > On 5 December 2012 16:54, Yaroslav Halchenko wrote: >> Thank you Bradley, >> >> This was easy enough even so that I could fix it (I think) -- just a >> typo: >> >> https://github.com/cython/cython/pull/165 >> >> feedback would be welcome ;) >> >> On Mon, 03 Dec 2012, Bradley M. Froehle wrote: >> >>> I ran `git bisect`: >>> d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 is the first bad commit >>> commit d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 >>> Author: Mark Florisson <[1]markflorisson88 at gmail.com> >>> Date: ? Tue Apr 10 15:01:00 2012 +0100 >>> ? ? Decref memoryview slice class attributes >>> [2]https://github.com/cython/cython/commit/d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 >>> -Brad >>> On Mon, Dec 3, 2012 at 1:10 PM, Yaroslav Halchenko >>> <[3]lists at onerussian.com> wrote: >> >>> reproduced with cython 0.17.2 (+ few post release fixes), originally >>> detected/reported [1] with ?0.17.1 on Debian systems using debug build >>> of >>> Python: >> >>> $> python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; >>> s=weakfail.foo(42)' >>> python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion >>> `gc->gc.gc_refs != 0' failed. >>> [1] ? ?12648 abort ? ? ?python-dbg -c >> >>> $> cat weakfail.pyx >>> import weakref >>> foo_dict = weakref.WeakValueDictionary() >> >>> cdef class Foo: >>> ? ? cdef object __weakref__ >> >>> def foo(key): >>> ? ? obj = Foo() >>> ? ? foo_dict[key] = obj >>> ? ? return obj >> >>> it seems to work fine with cython 0.15.2 . ?Any ideas? ?requires >>> separate/new bug report? >> >>> [1] [4]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692313 >> -- >> Yaroslav O. Halchenko >> Postdoctoral Fellow, Department of Psychological and Brain Sciences >> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 >> Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 >> WWW: http://www.linkedin.com/in/yarik >> _______________________________________________ >> cython-devel mailing list >> cython-devel at python.org >> http://mail.python.org/mailman/listinfo/cython-devel > > Thanks, I merged it. It'd be nice if you could add this as a testcase in the tests/run directory as a "don't segfault" kind of test. From lists at onerussian.com Thu Dec 6 04:40:06 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Wed, 5 Dec 2012 22:40:06 -0500 Subject: [Cython] (no subject) In-Reply-To: References: <20121203211007.GI7431@onerussian.com> <20121205165426.GL7431@onerussian.com> Message-ID: <20121206034006.GN7431@onerussian.com> On Wed, 05 Dec 2012, mark florisson wrote: > > Thanks, I merged it. > It'd be nice if you could add this as a testcase in the tests/run > directory as a "don't segfault" kind of test. I would be happy to extend the test battery but my blunt attempt failed, i.e. the test doesn't cause the failure: (git)novo:~deb/cython[remotes/upstream/master~1]git $> rm -rf ~/.pyxbld ; python-dbg ./runtests.py -v -v weakfail; cat tests/run/weakfail.pyx Python 2.7.3 (default, Sep 9 2012, 17:05:18) [GCC 4.7.1] Running tests against Cython 0.18-pre 73895001642d4531d32cac5ad2499f4ed5f3b286 Backends: c,cpp runTest (__main__.CythonRunTestCase) compiling (c) and running weakfail ... test_weakref (line 8) (weakfail.__test__) Doctest: weakfail.__test__.test_weakref (line 8) ... ok runTest (__main__.CythonRunTestCase) compiling (cpp) and running weakfail ... test_weakref (line 8) (weakfail.__test__) Doctest: weakfail.__test__.test_weakref (line 8) ... ok ---------------------------------------------------------------------- Ran 4 tests in 2.015s OK ALL DONE [193903 refs] import weakref foo_dict = weakref.WeakValueDictionary() cdef class Foo: cdef object __weakref__ def test_weakref(key): """ >>> _ = test_weakref(48) """ obj = Foo() foo_dict[key] = obj return obj whenever if I do it manually then -- yeap: (git)novo:~deb/cython[remotes/upstream/master~1]tests/run $> rm -rf ~/.pyxbld ; PYTHONPATH=../../ python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; s=weakfail.test_weakref(42)' python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. [1] 5508 abort PYTHONPATH=../../ python-dbg -c so how to make it 'effective'? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From stefan_ml at behnel.de Fri Dec 7 09:13:34 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 07 Dec 2012 09:13:34 +0100 Subject: [Cython] Broken C++ compile test Message-ID: <50C1A52E.5020502@behnel.de> Hi, the question by Czarek Tomczak on the users list made me stumble into this old C++ test: https://github.com/cython/cython/blob/master/tests/compile/cpp_operators.pyx It's completely broken and only failed to fail because it was never executed. Apparently, the test runner shadowed it with the test of the same name in the tests/run/ directory. Stefan From stefan_ml at behnel.de Fri Dec 7 09:48:42 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 07 Dec 2012 09:48:42 +0100 Subject: [Cython] Broken C++ compile test In-Reply-To: <50C1A52E.5020502@behnel.de> References: <50C1A52E.5020502@behnel.de> Message-ID: <50C1AD6A.2090005@behnel.de> Stefan Behnel, 07.12.2012 09:13: > the question by Czarek Tomczak on the users list made me stumble into this > old C++ test: > > https://github.com/cython/cython/blob/master/tests/compile/cpp_operators.pyx > > It's completely broken and only failed to fail because it was never > executed. Apparently, the test runner shadowed it with the test of the same > name in the tests/run/ directory. Hmm, sorry. It's not shadowed, it's just disabled in bugs.txt. Still, I wonder if this test actually makes sense - do we want to support this kind of syntax for C++ classes, or can this test just die? Stefan From sebastian at sipsolutions.net Fri Dec 7 11:36:02 2012 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Fri, 07 Dec 2012 11:36:02 +0100 Subject: [Cython] change strides attribute Message-ID: <1354876562.29425.19.camel@sebastian-laptop> Hey, The current numpy contiguous flags are relatively restrictive. This means that for example an array of `shape == (1,3,1)` and `itemsize == 1` is C-Contiguous if `strides == (3,1,1)` and F-Contiguous if `strides == (1,1,3)`. It would simplify flags settings and avoid copies here and there and generally be what most seem to expect to ignore the `strides[i]` if `shape[i] == 1` (or all if the array has 0 size). Which means that for example `strides == (0,1,-32)` (so arbitrary but `strides[1]`) would be both C- and F-contiguous. However trying to change this, runs into problems with user code relying on `strides[-1] == itemsize` (C-Contiguous) or `strides[0] == itemsize` (F-Contiguous). But there seems to be no way to really deprecate or protect Cython generated C-Code against such a change, because even if the contiguous buffer requested by Cython has nice strides, a user writing `arr.strides` accesses the original array which may not have and there is no way to give compile time warnings by deprecating flags. So I was wondering (I don't know cython that well) if `arr.strides` could not use `buffer.strides` internally to allow redefinition of contiguous flags in numpy in some future without breaking existing Cython user code. Maybe it is not worth it to go through much trouble for these flags but it seems nicer to me for code simplicity and just generally to be more consistent to redefine them at some point. Regards, Sebastian From robertwb at gmail.com Fri Dec 7 20:05:21 2012 From: robertwb at gmail.com (Robert Bradshaw) Date: Fri, 7 Dec 2012 11:05:21 -0800 Subject: [Cython] Broken C++ compile test In-Reply-To: <50C1AD6A.2090005@behnel.de> References: <50C1A52E.5020502@behnel.de> <50C1AD6A.2090005@behnel.de> Message-ID: On Fri, Dec 7, 2012 at 12:48 AM, Stefan Behnel wrote: > Stefan Behnel, 07.12.2012 09:13: >> the question by Czarek Tomczak on the users list made me stumble into this >> old C++ test: >> >> https://github.com/cython/cython/blob/master/tests/compile/cpp_operators.pyx >> >> It's completely broken and only failed to fail because it was never >> executed. Apparently, the test runner shadowed it with the test of the same >> name in the tests/run/ directory. > > Hmm, sorry. It's not shadowed, it's just disabled in bugs.txt. > > Still, I wonder if this test actually makes sense - do we want to support > this kind of syntax for C++ classes, or can this test just die? It looks like it's from way back in the day before we had even come to a final decision on syntax. I've nuked it. - Robert From lists at onerussian.com Mon Dec 10 14:55:35 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 10 Dec 2012 08:55:35 -0500 Subject: [Cython] (no subject) In-Reply-To: <20121206034006.GN7431@onerussian.com> References: <20121203211007.GI7431@onerussian.com> <20121205165426.GL7431@onerussian.com> <20121206034006.GN7431@onerussian.com> Message-ID: <20121210135535.GZ7431@onerussian.com> On Wed, 05 Dec 2012, Yaroslav Halchenko wrote: > On Wed, 05 Dec 2012, mark florisson wrote: > > > Thanks, I merged it. > > It'd be nice if you could add this as a testcase in the tests/run > > directory as a "don't segfault" kind of test. > I would be happy to extend the test battery but my blunt attempt failed, > i.e. the test doesn't cause the failure: > (git)novo:~deb/cython[remotes/upstream/master~1]git > $> rm -rf ~/.pyxbld ; python-dbg ./runtests.py -v -v weakfail; cat tests/run/weakfail.pyx > Python 2.7.3 (default, Sep 9 2012, 17:05:18) > [GCC 4.7.1] > Running tests against Cython 0.18-pre 73895001642d4531d32cac5ad2499f4ed5f3b286 > Backends: c,cpp > runTest (__main__.CythonRunTestCase) > compiling (c) and running weakfail ... test_weakref (line 8) (weakfail.__test__) > Doctest: weakfail.__test__.test_weakref (line 8) ... ok > runTest (__main__.CythonRunTestCase) > compiling (cpp) and running weakfail ... test_weakref (line 8) (weakfail.__test__) > Doctest: weakfail.__test__.test_weakref (line 8) ... ok > ---------------------------------------------------------------------- > Ran 4 tests in 2.015s > OK > ALL DONE > [193903 refs] > import weakref > foo_dict = weakref.WeakValueDictionary() > cdef class Foo: > cdef object __weakref__ > def test_weakref(key): > """ > >>> _ = test_weakref(48) > """ > obj = Foo() > foo_dict[key] = obj > return obj > whenever if I do it manually then -- yeap: > (git)novo:~deb/cython[remotes/upstream/master~1]tests/run > $> rm -rf ~/.pyxbld ; PYTHONPATH=../../ python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; s=weakfail.test_weakref(42)' > python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. > [1] 5508 abort PYTHONPATH=../../ python-dbg -c > so how to make it 'effective'? no hints from the experts? ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From stefan_ml at behnel.de Mon Dec 10 15:31:54 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 10 Dec 2012 15:31:54 +0100 Subject: [Cython] (no subject) In-Reply-To: <20121210135535.GZ7431@onerussian.com> References: <20121203211007.GI7431@onerussian.com> <20121205165426.GL7431@onerussian.com> <20121206034006.GN7431@onerussian.com> <20121210135535.GZ7431@onerussian.com> Message-ID: <50C5F25A.5010606@behnel.de> Yaroslav Halchenko, 10.12.2012 14:55: > On Wed, 05 Dec 2012, Yaroslav Halchenko wrote: >> On Wed, 05 Dec 2012, mark florisson wrote: >>>> Thanks, I merged it. > >>> It'd be nice if you could add this as a testcase in the tests/run >>> directory as a "don't segfault" kind of test. > >> I would be happy to extend the test battery but my blunt attempt failed, >> i.e. the test doesn't cause the failure: > >> (git)novo:~deb/cython[remotes/upstream/master~1]git >> $> rm -rf ~/.pyxbld ; python-dbg ./runtests.py -v -v weakfail; cat tests/run/weakfail.pyx >> Python 2.7.3 (default, Sep 9 2012, 17:05:18) >> [GCC 4.7.1] > >> Running tests against Cython 0.18-pre 73895001642d4531d32cac5ad2499f4ed5f3b286 >> Backends: c,cpp > >> runTest (__main__.CythonRunTestCase) >> compiling (c) and running weakfail ... test_weakref (line 8) (weakfail.__test__) >> Doctest: weakfail.__test__.test_weakref (line 8) ... ok >> runTest (__main__.CythonRunTestCase) >> compiling (cpp) and running weakfail ... test_weakref (line 8) (weakfail.__test__) >> Doctest: weakfail.__test__.test_weakref (line 8) ... ok > >> ---------------------------------------------------------------------- >> Ran 4 tests in 2.015s > >> OK >> ALL DONE >> [193903 refs] >> import weakref > >> foo_dict = weakref.WeakValueDictionary() > >> cdef class Foo: >> cdef object __weakref__ > >> def test_weakref(key): >> """ >> >>> _ = test_weakref(48) >> """ >> obj = Foo() >> foo_dict[key] = obj >> return obj > > >> whenever if I do it manually then -- yeap: > >> (git)novo:~deb/cython[remotes/upstream/master~1]tests/run >> $> rm -rf ~/.pyxbld ; PYTHONPATH=../../ python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; s=weakfail.test_weakref(42)' >> python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. >> [1] 5508 abort PYTHONPATH=../../ python-dbg -c > >> so how to make it 'effective'? > > no hints from the experts? ;) Usually, running gc.collect() after this kind of test (i.e. as part of the doctest) is a good way to provoke a crash in time. Stefan From lists at onerussian.com Mon Dec 10 16:38:28 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 10 Dec 2012 10:38:28 -0500 Subject: [Cython] (no subject) In-Reply-To: <50C5F25A.5010606@behnel.de> References: <20121203211007.GI7431@onerussian.com> <20121205165426.GL7431@onerussian.com> <20121206034006.GN7431@onerussian.com> <20121210135535.GZ7431@onerussian.com> <50C5F25A.5010606@behnel.de> Message-ID: <20121210153828.GA7431@onerussian.com> On Mon, 10 Dec 2012, Stefan Behnel wrote: > >> so how to make it 'effective'? > > no hints from the experts? ;) > Usually, running gc.collect() after this kind of test (i.e. as part of the > doctest) is a good way to provoke a crash in time. wasn't it obvious ? ;-) Thanks! https://github.com/cython/cython/pull/167 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From brad.froehle at gmail.com Mon Dec 10 21:08:11 2012 From: brad.froehle at gmail.com (Bradley M. Froehle) Date: Mon, 10 Dec 2012 12:08:11 -0800 Subject: [Cython] unused function '__pyx_pw_5numpy_7ndarray_1__getbuffer__' Message-ID: I've been noticing some unused function warnings of the following variety: test.cpp:1189:12: warning: unused function > '__pyx_pw_5numpy_7ndarray_1__getbuffer__' [-Wunused-function] > static int __pyx_pw_5numpy_7ndarray_1__getbuffer__(PyObject *__pyx_v_self, > Py_buffer *__pyx_v_info, int __pyx_v_flags) { > ^ > test.cpp:2008:13: warning: unused function > '__pyx_pw_5numpy_7ndarray_3__releasebuffer__' [-Wunused-function] > static void __pyx_pw_5numpy_7ndarray_3__releasebuffer__(PyObject > *__pyx_v_self, Py_buffer *__pyx_v_info) { > ^ > 2 warnings generated. ---- test.pyx ---- from numpy cimport import_array, import_ufunc import_array(); import_ufunc() These warnings were once silenced by some code introduced in a previous commit: commit 6cc61605a91c8ebf16318a07439a206118d81614 > Author: Lisandro Dalcin > Date: Wed Apr 28 16:18:43 2010 -0300 > introduce CYTHON_UNUSED macro to annotate functions and parametes > - Silent compiler warnings about unused function/parametes > - Defined to __attribute__((__unused__)) for GCC(>3.4) and ICC > - Applied to a __{get|release}buffer__ special methods > - Applied to a couple of (self,unused) parameter pairs But later reappeared: commit 519a19a9006494c6165ea481553a298d9bf9a008 > Author: Vitja Makarov > Date: Sun Jan 8 19:22:38 2012 +0400 > DefNode: split into function and python wrapper I've introduced a pull request to re-silence these warnings: https://github.com/cython/cython/pull/168 -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertwb at gmail.com Mon Dec 10 22:16:07 2012 From: robertwb at gmail.com (Robert Bradshaw) Date: Mon, 10 Dec 2012 13:16:07 -0800 Subject: [Cython] unused function '__pyx_pw_5numpy_7ndarray_1__getbuffer__' In-Reply-To: References: Message-ID: Thanks! Merged. On Mon, Dec 10, 2012 at 12:08 PM, Bradley M. Froehle wrote: > I've been noticing some unused function warnings of the following variety: > >> test.cpp:1189:12: warning: unused function >> '__pyx_pw_5numpy_7ndarray_1__getbuffer__' [-Wunused-function] >> static int __pyx_pw_5numpy_7ndarray_1__getbuffer__(PyObject *__pyx_v_self, >> Py_buffer *__pyx_v_info, int __pyx_v_flags) { >> ^ >> test.cpp:2008:13: warning: unused function >> '__pyx_pw_5numpy_7ndarray_3__releasebuffer__' [-Wunused-function] >> static void __pyx_pw_5numpy_7ndarray_3__releasebuffer__(PyObject >> *__pyx_v_self, Py_buffer *__pyx_v_info) { >> ^ >> 2 warnings generated. > > > ---- test.pyx ---- > from numpy cimport import_array, import_ufunc > import_array(); import_ufunc() > > These warnings were once silenced by some code introduced in a previous > commit: > >> commit 6cc61605a91c8ebf16318a07439a206118d81614 >> Author: Lisandro Dalcin >> Date: Wed Apr 28 16:18:43 2010 -0300 >> introduce CYTHON_UNUSED macro to annotate functions and parametes >> - Silent compiler warnings about unused function/parametes >> - Defined to __attribute__((__unused__)) for GCC(>3.4) and ICC >> - Applied to a __{get|release}buffer__ special methods >> - Applied to a couple of (self,unused) parameter pairs > > > But later reappeared: > >> commit 519a19a9006494c6165ea481553a298d9bf9a008 >> Author: Vitja Makarov >> Date: Sun Jan 8 19:22:38 2012 +0400 >> DefNode: split into function and python wrapper > > > I've introduced a pull request to re-silence these warnings: > https://github.com/cython/cython/pull/168 > > -Brad > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > http://mail.python.org/mailman/listinfo/cython-devel > From stefan_ml at behnel.de Fri Dec 14 08:28:01 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 14 Dec 2012 08:28:01 +0100 Subject: [Cython] Cython 0.17.2 released In-Reply-To: <20121203162320.GH7431@onerussian.com> References: <50ABED53.8070104@behnel.de> <20121203162320.GH7431@onerussian.com> Message-ID: <50CAD501.4050402@behnel.de> Yaroslav Halchenko, 03.12.2012 17:23: > shouldn't there be > http://wiki.cython.org/ReleaseNotes-0.17.2 > ? ;-) You can copy it over from https://github.com/cython/cython/blob/0.17/CHANGES.rst if you feel like it. :) I added a link at the top of http://wiki.cython.org/ReleaseHistory Stefan From stefan_ml at behnel.de Fri Dec 14 15:13:51 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 14 Dec 2012 15:13:51 +0100 Subject: [Cython] Cython 0.17.3 released Message-ID: <50CB341F.1010304@behnel.de> Hi all, I'm happy to announce the next bug fix release of the current stable Cython 0.17 series: 0.17.3. It fixes two crash bugs, for weakrefs and for the cleanup code on interpreter shutdown, so if you are using these features, you might want to upgrade. http://cython.org/release/Cython-0.17.3.tar.gz http://cython.org/release/Cython-0.17.3.zip github: https://github.com/cython/cython/commit/1da2e2fa78504f2a01a999e6549d14219af62a1b The release notes for the 0.17 series are here: https://github.com/cython/cython/blob/0.17/CHANGES.rst Have fun, Stefan Bugs fixed ---------- * During final interpreter cleanup (with types cleanup enabled at compile time), extension types that inherit from base types over more than one level that were cimported from other modules could lead to a crash. * Weak-reference support in extension types (with a "cdef __weakref__" attribute) generated incorrect deallocation code. * In CPython 3.3, converting a Unicode character to the Py_UNICODE type could fail to raise an overflow for non-BMP characters that do not fit into a wchar_t on the current platform. * Negative C integer constants lost their longness suffix in the generated C code. From animus at wayround.org Sat Dec 15 02:17:34 2012 From: animus at wayround.org (Alexey V Gorshkov) Date: Sat, 15 Dec 2012 03:17:34 +0200 Subject: [Cython] Cython is not PEP-420 (Implicit Namespace Packages) compliant Message-ID: <50CBCFAE.7020004@wayround.org> Hi! Reporting about Cython PEP-420 (Implicit Namespace Packages) incompliance. (Sample package setup attached) (http://www.python.org/dev/peps/pep-0420/) Next package's tree will not work and will return error . ./setup.py ./firstlevel ./firstlevel/secondlevel ./firstlevel/secondlevel/mydearpackage ./firstlevel/secondlevel/mydearpackage/__init__.py ./firstlevel/secondlevel/mydearpackage/test.pyx ./firstlevel/secondlevel/mydearpackage/test_h.pxd ===== Error Message ===== > python3 ./setup.py build_ext --inplace running build_ext cythoning firstlevel/secondlevel/mydearpackage/test.pyx to firstlevel/secondlevel/mydearpackage/test.c Error compiling Cython file: ------------------------------------------------------------ ... cimport firstlevel.secondlevel.mydearpackage.test_h ^ ------------------------------------------------------------ firstlevel/secondlevel/mydearpackage/test.pyx:1:8: 'firstlevel.secondlevel.mydearpackage.test_h.pxd' not found building 'firstlevel.secondlevel.mydearpackage.test' extension creating build creating build/temp.linux-i686-3.3 creating build/temp.linux-i686-3.3/firstlevel creating build/temp.linux-i686-3.3/firstlevel/secondlevel creating build/temp.linux-i686-3.3/firstlevel/secondlevel/mydearpackage i486-pc-linux-gnu-gcc -pthread -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python3.3m -c firstlevel/secondlevel/mydearpackage/test.c -o build/temp.linux-i686-3.3/firstlevel/secondlevel/mydearpackage/test.o firstlevel/secondlevel/mydearpackage/test.c:1:2: error: #error Do not use this file, it is the result of a failed Cython compilation. error: command 'i486-pc-linux-gnu-gcc' failed with exit status 1 ===== Error Message End ===== Simply adding __init__.py to firstlevel and firstlevel/secondlevel, and there will no building error ===== Normal Success Message ===== >python3 ./setup.py build_ext --inplace running build_ext cythoning firstlevel/secondlevel/mydearpackage/test.pyx to firstlevel/secondlevel/mydearpackage/test.c building 'firstlevel.secondlevel.mydearpackage.test' extension i486-pc-linux-gnu-gcc -pthread -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python3.3m -c firstlevel/secondlevel/mydearpackage/test.c -o build/temp.linux-i686-3.3/firstlevel/secondlevel/mydearpackage/test.o i486-pc-linux-gnu-gcc -pthread -shared build/temp.linux-i686-3.3/firstlevel/secondlevel/mydearpackage/test.o -L/usr/lib -lpython3.3m -o /mnt/sda3/home/agu/p/pep420test/firstlevel/secondlevel/mydearpackage/test.cpython-33m.so ===== Normal Success Message End ===== -------------- next part -------------- A non-text attachment was scrubbed... Name: pep420test-0.0.0.tar.gz Type: application/gzip Size: 798 bytes Desc: not available URL: From stefan_ml at behnel.de Sat Dec 15 06:51:19 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 15 Dec 2012 06:51:19 +0100 Subject: [Cython] Cython is not PEP-420 (Implicit Namespace Packages) compliant In-Reply-To: <50CBCFAE.7020004@wayround.org> References: <50CBCFAE.7020004@wayround.org> Message-ID: <50CC0FD7.7000902@behnel.de> Alexey V Gorshkov, 15.12.2012 02:17: > Reporting about Cython PEP-420 (Implicit Namespace Packages) incompliance. > > (Sample package setup attached) > > (http://www.python.org/dev/peps/pep-0420/) > > Next package's tree will not work and will return error > [...] I'm sure it's not - the compile time package resolution code in Cython was written long before namespace packages were even being thought about. (For comparison, remember that almost none of the existing CPython versions supports namespaces packages either, 3.3 is the only exception). Basically, the runtime import code should be ok, but the package resolution at compile time, that is used mainly for cimports and for figuring out the fully qualified module name of compiled modules, doesn't have any support for packages that don't have an __init__.py. Would you care to change that? You could try to come up with a patch, we'd certainly appreciate it. Stefan From stefan_ml at behnel.de Sat Dec 15 18:34:28 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 15 Dec 2012 18:34:28 +0100 Subject: [Cython] releasing 0.18? Message-ID: <50CCB4A4.6040101@behnel.de> Hi, the current master doesn't really have the one new, great&shiny feature, but I don't see a reason to keep the changes back that we have implemented so far. Robert's const support and the integer overflow checks (assuming that both are ready) are certainly worth it. Unless Mark's minivect changes are ready to merge soonish, I don't think we should keep waiting for them. So, what about getting the master ready for a release? Note that this means that we need a couple of more comments in the changelog, as well as documentation for the things that need it (const?). Stefan From animus at wayround.org Sat Dec 15 21:05:55 2012 From: animus at wayround.org (Alexey V Gorshkov) Date: Sat, 15 Dec 2012 22:05:55 +0200 Subject: [Cython] Cython is not PEP-420 (Implicit Namespace Packages) compliant In-Reply-To: <50CC0FD7.7000902@behnel.de> References: <50CBCFAE.7020004@wayround.org> <50CC0FD7.7000902@behnel.de> Message-ID: <50CCD823.1080604@wayround.org> Stefan Behnel wrote: > Alexey V Gorshkov, 15.12.2012 02:17: >> Reporting about Cython PEP-420 (Implicit Namespace Packages) incompliance. >> >> (Sample package setup attached) >> >> (http://www.python.org/dev/peps/pep-0420/) >> >> Next package's tree will not work and will return error >> [...] > I'm sure it's not - the compile time package resolution code in Cython was > written long before namespace packages were even being thought about. (For > comparison, remember that almost none of the existing CPython versions > supports namespaces packages either, 3.3 is the only exception). > > Basically, the runtime import code should be ok, but the package resolution > at compile time, that is used mainly for cimports and for figuring out the > fully qualified module name of compiled modules, doesn't have any support > for packages that don't have an __init__.py. > > Would you care to change that? You could try to come up with a patch, we'd > certainly appreciate it. > > Stefan > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > http://mail.python.org/mailman/listinfo/cython-devel Following changes works for me. But I did not made any tests except on package I've sent in initial message. diff --git a/Cython/Utils.py b/Cython/Utils.py index 5739f38..8f05287 100644 --- a/Cython/Utils.py +++ b/Cython/Utils.py @@ -3,7 +3,7 @@ # anywhere else in particular # -import os, sys, re, codecs +import os, os.path, sys, re, codecs modification_time = os.path.getmtime @@ -87,7 +87,7 @@ def search_include_directories(dirs, qualified_name, suffix, pos, else: dirs = (find_root_package_dir(file_desc.filename),) + dirs - dotted_filename = qualified_name + dotted_filename = qualified_name.replace('.', os.path.sep) if suffix: dotted_filename += suffix if not include: From markflorisson88 at gmail.com Sun Dec 16 01:18:55 2012 From: markflorisson88 at gmail.com (mark florisson) Date: Sun, 16 Dec 2012 00:18:55 +0000 Subject: [Cython] releasing 0.18? In-Reply-To: <50CCB4A4.6040101@behnel.de> References: <50CCB4A4.6040101@behnel.de> Message-ID: On 15 December 2012 17:34, Stefan Behnel wrote: > Hi, > > the current master doesn't really have the one new, great&shiny feature, > but I don't see a reason to keep the changes back that we have implemented > so far. Robert's const support and the integer overflow checks (assuming > that both are ready) are certainly worth it. Unless Mark's minivect changes > are ready to merge soonish, I don't think we should keep waiting for them. > > So, what about getting the master ready for a release? > > Note that this means that we need a couple of more comments in the > changelog, as well as documentation for the things that need it (const?). > > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > http://mail.python.org/mailman/listinfo/cython-devel Great. There was an issue with extension types as dtype in memoryviews, which I hope to have a look at tomorrow. From robertwb at gmail.com Sun Dec 16 09:39:39 2012 From: robertwb at gmail.com (Robert Bradshaw) Date: Sun, 16 Dec 2012 00:39:39 -0800 Subject: [Cython] releasing 0.18? In-Reply-To: <50CCB4A4.6040101@behnel.de> References: <50CCB4A4.6040101@behnel.de> Message-ID: On Sat, Dec 15, 2012 at 9:34 AM, Stefan Behnel wrote: > Hi, > > the current master doesn't really have the one new, great&shiny feature, > but I don't see a reason to keep the changes back that we have implemented > so far. Robert's const support and the integer overflow checks (assuming > that both are ready) are certainly worth it. Unless Mark's minivect changes > are ready to merge soonish, I don't think we should keep waiting for them. > > So, what about getting the master ready for a release? > > Note that this means that we need a couple of more comments in the > changelog, as well as documentation for the things that need it (const?). +1 I have a bit more I want to do with the integer overflow checks, but an imminent release will be a good motivation to finally finish this up :). - Robert From stefan_ml at behnel.de Thu Dec 20 07:24:57 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 20 Dec 2012 07:24:57 +0100 Subject: [Cython] [cython] Fix __Pyx_ImportType if #Py_LIMITED_API is defined. (#171) In-Reply-To: References: Message-ID: <50D2AF39.2010902@behnel.de> Hi Bradley, Bradley M. Froehle, 19.12.2012 21:31: > I was recently trying to use mpi4py in a hand-written Python 3 extension > module with `#define Py_LIMITED_API`. Work on getting Cython play nicely with Py_LIMITED_API is certainly appreciated. In most cases, it should be as simple as adding another #ifdef to utility functions that are already written in plain C anyway. A lot of the optimisations will need this. > One side effect of the limited > API is that `PyTypeObject` becomes an opaque type. > This means that our `__Pyx_ImportType` cannot just introspect > `tp_basicsize`. > > I've updated the code to extract the `tp_basicsize` value from the > `__basicsize__` attribute which should be available instead. > > I'd appreciate comments on the code style here... I'm not sure how to > write these sorts of calls most efficiently yet. I think it's ok. The only issue is that PyObject_GetAttrString() creates an intermediate string object from the char* you pass. Py3.3 (or 3.2+?) has a mechanism for avoiding this. We could start using that if available, or maybe even copy it over into Cython to use it in older versions as well. Anyway, this is code that runs at import time - I don't think it's any performance critical (and if a whole import works, the memory allocated for a tiny string can't be an issue either...). Stefan From brad.froehle at gmail.com Thu Dec 20 08:03:39 2012 From: brad.froehle at gmail.com (Bradley M. Froehle) Date: Wed, 19 Dec 2012 23:03:39 -0800 Subject: [Cython] [cython] Fix __Pyx_ImportType if #Py_LIMITED_API is defined. (#171) In-Reply-To: <50D2AF39.2010902@behnel.de> References: <50D2AF39.2010902@behnel.de> Message-ID: This was the only issue I ran into while trying to use a Cython compiled module from a new module compiled with Py_LIMITED_API, and the fix turned out to be pretty simple. The real trick, as you allude to, will be to have a Cython generated module itself be able to be compiled with Py_LIMITED_API. -Brad On Wed, Dec 19, 2012 at 10:24 PM, Stefan Behnel wrote: > Hi Bradley, > > Bradley M. Froehle, 19.12.2012 21:31: > > I was recently trying to use mpi4py in a hand-written Python 3 extension > > module with `#define Py_LIMITED_API`. > > Work on getting Cython play nicely with Py_LIMITED_API is certainly > appreciated. In most cases, it should be as simple as adding another #ifdef > to utility functions that are already written in plain C anyway. A lot of > the optimisations will need this. > > > > One side effect of the limited > > API is that `PyTypeObject` becomes an opaque type. > > This means that our `__Pyx_ImportType` cannot just introspect > > `tp_basicsize`. > > > > I've updated the code to extract the `tp_basicsize` value from the > > `__basicsize__` attribute which should be available instead. > > > > I'd appreciate comments on the code style here... I'm not sure how to > > write these sorts of calls most efficiently yet. > > I think it's ok. The only issue is that PyObject_GetAttrString() creates an > intermediate string object from the char* you pass. Py3.3 (or 3.2+?) has a > mechanism for avoiding this. We could start using that if available, or > maybe even copy it over into Cython to use it in older versions as well. > > Anyway, this is code that runs at import time - I don't think it's any > performance critical (and if a whole import works, the memory allocated for > a tiny string can't be an issue either...). > > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > http://mail.python.org/mailman/listinfo/cython-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at onerussian.com Thu Dec 20 19:02:18 2012 From: lists at onerussian.com (Yaroslav Halchenko) Date: Thu, 20 Dec 2012 13:02:18 -0500 Subject: [Cython] Cython 0.17.2 released In-Reply-To: <50CAD501.4050402@behnel.de> References: <50ABED53.8070104@behnel.de> <20121203162320.GH7431@onerussian.com> <50CAD501.4050402@behnel.de> Message-ID: <20121220180218.GA17537@onerussian.com> On Fri, 14 Dec 2012, Stefan Behnel wrote: > Yaroslav Halchenko, 03.12.2012 17:23: > > shouldn't there be > > http://wiki.cython.org/ReleaseNotes-0.17.2 > > ? ;-) > You can copy it over from > https://github.com/cython/cython/blob/0.17/CHANGES.rst > if you feel like it. :) ah cool -- catch this PR https://github.com/cython/cython/pull/172 then ;) Also, for me 'sdist' failed due to $> git show-ref -s HEAD exiting with -1 with git 1.8.0 in my clone... not sure about this dark side of git, but looking at other projects, git rev-parse HEAD might be a better choice for this purpose would you accept such a fix/PR ? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From robertwb at gmail.com Thu Dec 20 19:46:04 2012 From: robertwb at gmail.com (Robert Bradshaw) Date: Thu, 20 Dec 2012 10:46:04 -0800 Subject: [Cython] Cython 0.17.2 released In-Reply-To: <20121220180218.GA17537@onerussian.com> References: <50ABED53.8070104@behnel.de> <20121203162320.GH7431@onerussian.com> <50CAD501.4050402@behnel.de> <20121220180218.GA17537@onerussian.com> Message-ID: On Thu, Dec 20, 2012 at 10:02 AM, Yaroslav Halchenko wrote: > > On Fri, 14 Dec 2012, Stefan Behnel wrote: >> Yaroslav Halchenko, 03.12.2012 17:23: >> > shouldn't there be >> > http://wiki.cython.org/ReleaseNotes-0.17.2 >> > ? ;-) > >> You can copy it over from >> https://github.com/cython/cython/blob/0.17/CHANGES.rst >> if you feel like it. :) > > ah cool -- catch this PR > https://github.com/cython/cython/pull/172 > then ;) > > > Also, for me 'sdist' failed due to > > $> git show-ref -s HEAD > > exiting with -1 with git 1.8.0 in my clone... not sure about this dark > side of git, but looking at other projects, > > git rev-parse HEAD > > might be a better choice for this purpose > > would you accept such a fix/PR ? Yes, please send us a fix. (This was written right when we were moving to git, before we knew it well.) - Robert From stefan_ml at behnel.de Fri Dec 21 21:25:59 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 21 Dec 2012 21:25:59 +0100 Subject: [Cython] Travis-CI builds for Cython Message-ID: <50D4C5D7.8070609@behnel.de> Hi, I've set up travis builds for Cython's master branch: https://travis-ci.org/cython/cython There isn't currently any advantage over Jenkins (they run on 32bit Ubuntu Linux) and in fact, it's even less interesting because they don't support Py2.4 nor Py3.1, they only use CPython/PyPy release versions (not the latest developer versions as we do on Jenkins), and their Py2.5 installation even seems to be a bit broken (the embed test doesn't link against zlib automatically in that version). So, I'm not sure it's worth it, but it shouldn't hurt either. Personally, I find the Debian builds way more interesting, but their sources need to be updated manually: https://buildd.debian.org/status/package.php?p=cython&suite=experimental Stefan