Mailman 3 May 2013 - cython-devel

Re: [Cython] [cython-users] Re: Cython Typed Memoryviews versus Cython+Numpy Speed ups
by Stefan Behnel May 17, 2013

May 17, 2013

Robert Bradshaw, 17.04.2013 06:02: > On Tue, Apr 16, 2013 at 6:46 PM, pythonOmetrist >> Attached HTML seems mostly white, and not clear where to go from here. Nogil >> seems to be one option. > > Just a brief glance at the code, you have a lot of n_k_w[x][y] which > is vastly more expensive than n_k_w[x, y]. Is that always equivalent? If so, we might want to transform it internally. Stefan

2 1

Cython 0.19.1 released
by Stefan Behnel May 11, 2013

May 11, 2013

Hi all, Cython 0.19.1 is following the course of the recent 0.19 release. This is mainly a bug fix release that adds only minor new features and fixes some bugs and regressions in the latest release. Upgrading is generally recommended. You can get it from here: http://cython.org/release/Cython-0.19.1.tar.gz http://cython.org/release/Cython-0.19.1.zip Release notes: https://github.com/cython/cython/blob/8f07f8d8265799cada5046fe0b7c0807d7b41… Documentation: http://docs.cython.org/ Major changes include: * A warning is emitted when negative literal indices are found inside of a code section that disables ``wraparound`` handling. This helps with fixing invalid code that might fail in the face of future compiler optimisations. * A regression in 0.19 was fixed that rejected valid C expressions from being used in C array size declarations. * Testing large (> int) C integer values for their truth value could fail due to integer wrap-around. * The automatic signature documentation tries to preserve more semantics of default arguments and argument types. Specifically, ``bint`` arguments now appear as type ``bool``. Have fun, Stefan

1 0

Re: [Cython] [cython-users] mimetype and icon for Cython programs?
by Stefan Behnel May 9, 2013

May 9, 2013

Shriramana Sharma, 09.05.2013 05:17: > On Thu, May 9, 2013 at 5:30 AM, Robert Bradshaw wrote: >> Feel free to use >> the log at http://en.wikipedia.org/wiki/File:Cython-logo.svg (with our >> without the trailing ython). > > For proper transparency I removed the white rectangle used to make O > look like C: > > http://en.wikipedia.org/wiki/File:Cython-logo.svg Just to keep things official and to avoid the possibility of legal conflicts, I uploaded my original version here: https://de.wikipedia.org/wiki/Datei:Cython-logo.svg Apparently, I cannot overwrite the english version file. If someone else can, please replace it. > But since this apparently isn't under a free licence, it can't be part > of the official KDE distro. Is there a way out? Not sure how KDE handles this, but it also uses the official Python logo for .py files. So I can't imagine it being a problem. > I have submitted https://bugs.kde.org/show_bug.cgi?id=319557 to > include this into KDE. Please use the official version instead then. > This still leaves us with the question as to where we are supposed to > register this mimetype officially if necessary. IANA, I guess: https://www.iana.org/assignments/media-types Not sure it's worth it, though. Stefan

1 0

nogil doesn't seem to work when defined on extern cpp functions
by Ryan Pessa May 8, 2013

May 8, 2013

Hello, I ran into an interesting problem today. It doesn't seem like Cython respects the `nogil` statement on extern cpp functions. I am trying to use a blocking I/O function, and am running it in secondary thread so I can use another library function to cancel it. I have tried it both on the `extern` line: cdef extern from "digitalpersona/dpfp_api.h" nogil: uint32_t DPFPGetEvent(dp_uid_t* pDevUID, dp_device_event_t** ppEvent, uint32_t uTimeoutMsec) and on the function itself: cdef extern from "digitalpersona/dpfp_api.h" nogil: uint32_t DPFPGetEvent(dp_uid_t* pDevUID, dp_device_event_t** ppEvent, uint32_t uTimeoutMsec) nogil Either way, this statement still blocks other threads: res = dpfp_api.DPFPGetEvent(pIdDev, &pEvent, dpfp_api.DP_TIMEOUT_INFINITE) While this statement does not: with nogil: res = dpfp_api.DPFPGetEvent(pIdDev, &pEvent, dpfp_api.DP_TIMEOUT_INFINITE) All variables used (res, pIdDev, pEvent) are C variables. Obviously this is not a huge issue, as I can bypass the GIL using `with nogil`. But I figured it would be a good idea to report it anyway. Ryan Pessa AerisPOS Project Manager / Developer Essential Elements <http://www.essential-elements.net/> | AerisPOS<http://www.aerispos.com/>

3 2

Cython 0.19.1 release candidate
by Stefan Behnel May 8, 2013

May 8, 2013

Hi, here's a release candidate for 0.19.1. I accept feedback for the next two days, then I'll send the final release out. http://cython.org/release/Cython-0.19.1rc1.tar.gz The changelog is on github: https://github.com/cython/cython/blob/1491df80144a13ac4c6d8027283f7619a716f… Stefan

2 2

project proposal: line tracing/profiling, coverage, etc.
by Stefan Behnel May 8, 2013

May 8, 2013

Hi, in the past, Robert and I have invested some work into supporting profiling and tracing in Cython, and I would like to see this finalised. While Python level tracing and profiling might not seem like the ideal tools for performance critical Cython code, they are actually pretty handy when much of your code is Python code and you want to do, say, coverage analysis over your whole code base, without having to exclude the Cython parts. So I've opened a ticket that highlights the missing bits. http://trac.cython.org/cython_trac/ticket/815 If anyone's interested in pursuing this, I'd be glad to help getting you on the right track. I don't even think there's all that much left to do, but it's still a bit of cleanup and maybe some naughty little details along the way. Would make a good entry project, IMHO. Anyone interested? Stefan

1 1

Generated C++ code incompatible with Clang
by Hannes Röst May 7, 2013

May 7, 2013

Dear mailing list In the process of developing a rather large Cython project where we wrap the scientific OpenMS library (http://sourceforge.net/projects/open-ms/) using Cython, we have come across an issue with the C++ code that is generated by Cython. The issue is that Cython generates C++ that is not compatible with the Clang compiler. I hope this is the correct mailing list to report this issue since it seems to be a bug in Cython and not in Clang (after some discussion we have concluded that Clang is most likely correct in rejecting the generated code). Since we do not have access to the issue tracker, we hoped posting our issue here would clear up matters. The issue occurs with the following minimal testcase: from libcpp.vector cimport vector as libcpp_vector from cython.operator cimport dereference as deref, preincrement as inc cdef class TestClass: cdef libcpp_vector[float] inst def __iter__(self): it = self.inst.begin() while it != self.inst.end(): yield deref(it) inc(it) When compiled with Cython to C++, it generates C++ that cannot be compiled with Clang (however it seems that gcc and MSVS accept the code). It seems that the same issue with Clang was already discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=623303 and the conclusion was that Clang is correct in reporting the code as erroneous. In the above case, the invalid C++ code that gets generated is: p->__pyx_v_it.std::vector<float>::iterator::~iterator(); The correct code for the above case would probably be (this is just a suggestion, it compiles with gcc and clang on our machines and our tests run through with it): typedef std::vector<float>::iterator _it; p->__pyx_v_it.~_it(); We have tested it with the 0.18 release as well as the newest 0.19b2 build from github (58131b68dc033fc7ca269d875a2aab2b4e9646a2) and the results were the same. Thanks, Hannes Röst -- Hannes Röst Institute of Molecular Systems Biology ETH Zürich Hönggerberg HPT C75 Wolfgang-Pauli Strasse 16 CH-8093 Zürich (Switzerland) phone: 0041 44 633 3945 fax: 0041 44 633 10 51 e-mail: roest(a)imsb.biol.ethz.ch

2 3

Re: [Cython] [cython] Order cdef classes by inheritance before generating the code. (#223)
by Stefan Behnel May 6, 2013

May 6, 2013

Nikita Nemkin, 05.05.2013 16:13: > cdef classes must be (topologically) ordered by inheritance to satisfy the following dependencies: > 1) dealloc function definition: derived classes call base class dealloc; > 2) vtable pointer initialization in module init function. > Wrong order causes C/C++ compilation failure for 1) and segfault on import for 2). > > Normally, source order is the correct order, but forward declarations can change this. See included test case for example. > I hit this problem because I forward declare all my classes in alphabetic order (and then include class definitions from .pxi files, one class per file). > > The simple (although not obvious) workaround is to reorder forward delarations, but I believe it's worth fixing permanently. > You can merge this Pull Request by running: > > git pull https://github.com/nnemkin/cython cdef_class_order > > Or you can view, comment on it, or merge it online at: > > https://github.com/cython/cython/pull/223 Luckily, this broke the Sage build, by running into an infinite loop while sorting. https://sage.math.washington.edu:8091/hudson/job/sage-build/1778/ We clearly need more tests for extension type hierarchies spread across multiple modules. Stefan

1 0

Re: [Cython] [cython] Hide Cython utility classes (like memoryview) from Python level module scope. (#222)
by Stefan Behnel May 5, 2013

May 5, 2013

Nikita Nemkin, 04.05.2013 19:52: > Two changes included: > > 1) cdef classes in utility code can have compiler directives attached to them. This is not used anywhere ATM, but memoryviews may benefit from ``(a)cython.final``. > > 2) All utility classes are excluded from module dictionary by *implicitly* marking them with ``(a)cython.internal`` . This fixes [#775](http://trac.cython.org/cython_trac/ticket/775), test is included. > > I don't quite understand what CythonScope is and how utility classes are *supposed* to be hidden, but as it is now, utility code scope is merged into main module scope and there is nothing special about its classes. > > BTW if a user declares his own class with the same name as utility class (for example, ``memoryview``), everything breaks down. > You can merge this Pull Request by running: > > git pull https://github.com/nnemkin/cython cy_utility_decorators > > Or you can view, comment on it, or merge it online at: > > https://github.com/cython/cython/pull/222 I wonder why utility classes actually need a Python name. Can't they just live with None as "name"? All they should really need is their cname and a properly analysed entry stored in the right places, so deleting their Python visible name when merging them into the main module should fix this. Stefan

2 2

any more fixes for 0.19.1 ?
by Stefan Behnel May 4, 2013

May 4, 2013

Hi, since there's an unpleasant regression in 0.19, I'd like to release 0.19.1 soon. If you have any more fixes that should go in, you may want to apply them now or at least speak up to delay the release. I'm aware of ticket 810, but it doesn't seem like a regression and I don't currently see an obvious simple way to reproduce it. It looks like a classical "last reference dies while still in use" kind of problem to me. Maybe even a bug in Sage rather than Cython that just accidentally worked in older releases, although I'm not saying that there is nothing Cython could do about it. http://trac.cython.org/cython_trac/ticket/810 Ticket 814 (compiler crash during C++ code analysis) would also be worth closing before a release as it might be an easy fix, even though it's not a regression (crashes for me also in 0.18). http://trac.cython.org/cython_trac/ticket/814 I also think that Ticket 775 ("memoryview" name leaks into module namespace) should eventually be fixed as it's annoying and unexpected, although not necessarily right in this release (it's been like this forever). http://trac.cython.org/cython_trac/ticket/775 Anything else? Stefan

2 3