Mailman 3 July 2016 - cython-devel

cygdb: no debug files were found
by Nathan Goldbaum Sept. 14, 2016

Sept. 14, 2016

Hi all, I'm following the directions in the link below to debug some cython code using cygdb: http://docs.cython.org/src/userguide/debugging.html Unfortunately, when I try to actually debug my program using cygdb, I get a "no debug files were found" error. It looks like the error is getting raised here: https://github.com/cython/cython/blob/master/Cython/Debugger/Cygdb.py#L33 So for some reason the "cython_debug" folder isn't being generated at build time. I tried to follow the directions closely, you can see the notes I put together during the installation process here: https://bpaste.net/show/6b11f815d449 Unfortunately the library I'm trying to debug (yt: bitbucket.org/yt_analysis/yt) uses a somewhat nonstandard build setup based on numpy distutils, and I suspect that is breaking some of the assumptions that went into the cygdb instructions in the cython docs. Does anyone have any idea what went wrong here? For now I'm going to fall back to regular gdb, and debug the autogenerated cython sources. Thanks for your help, Nathan Goldbaum

2 1

Minor issue with running tests and -Wlong-long
by Erik Bray Sept. 5, 2016

Sept. 5, 2016

Hello, As some of you already know I've been doing some work on Cython on Cygwin [in the process I I'm constantly mixing the two up in speech, but maybe in writing I'll do better :)]. There are several issues with the tests on Cygwin, and that's one thing I'll work on. But a major annoyance I've encountered when running any tests is a huge number of warnings from gcc such as: embray@PC-pret-47 ~/src/cython $ CFLAGS="-O0" ./runtests.py -vv --no-cpp addloop Python 2.7.10 (default, Jun 1 2015, 18:05:38) [GCC 4.9.2] Running tests against Cython 0.24 f68b5bd0fa620d0dc26166bffe5fe42d94068720 Backends: c runTest (__main__.CythonRunTestCase) compiling (c) and running addloop ... === C/C++ compiler error output: === In file included from /usr/include/python2.7/Python.h:58:0, from addloop.c:4: /usr/include/python2.7/pyport.h:69:27: warning: ISO C90 does not support ‘long long’ [-Wlong-long] #define PY_LONG_LONG long long ^ /usr/include/python2.7/pyport.h:793:34: note: in definition of macro ‘PyAPI_FUNC’ # define PyAPI_FUNC(RTYPE) RTYPE ^ /usr/include/python2.7/intobject.h:46:21: note: in expansion of macro ‘PY_LONG_LONG’ PyAPI_FUNC(unsigned PY_LONG_LONG) PyInt_AsUnsignedLongLongMask(PyObject *); ^ In file included from /usr/include/python2.7/Python.h:58:0, from addloop.c:4: ... And so on. For now an easy workaround is to add -Wno-long-long to the compiler flags. But I was curious why I was seeing this in Cygwin but not on my Ubuntu system, and here's why: In runtests.py there is a check https://github.com/cython/cython/blob/master/runtests.py#L829 if self.language=='c' and compiler='gcc': ext_compile_flags.extend(['-std=c89', '-pedantic']) where in this case `compiler` is assigned `sysconfig.get_config_var('CC')`. On my Linux system this expands to "x86_64-linux-gnu-gcc -pthread". Whereas on Cygwin (and probably many other systems) it expands simply to "gcc". I'm guessing that to do what it intended the above line should read "and 'gcc' in compiler". But this also raises the question: Why are the tests run with these flags? If Python was configured with HAVE_LONG_LONG, then these warnings will be inevitable. Thanks, Erik

2 2

Migration of tickets from trac to github
by Robert Bradshaw Aug. 17, 2016

Aug. 17, 2016

Please see https://github.com/robertwb/issues-import-test/issues/ as to what this would look like. (This is a partial import, due to github API rate limiting issues.) Unless something looks terribly wrong, I'll start the real migration shortly. - Robert

5 13

BUG: cannot override cdef by cpdef method in .pxd
by Jeroen Demeyer July 29, 2016

July 29, 2016

Hello, I recently learned from Robert Bradshaw that it is legal in Cython to override cdef methods by cpdef methods. But doing this in a .pxd file causes a compile-time error: *foo.pyx*: cdef class Base(object): cdef meth(self): print("Base.meth()") cdef class Derived(Base): cpdef meth(self): print("Derived.meth()") *foo.pxd*: cdef class Base(object): cdef meth(self) cdef class Derived(Base): cpdef meth(self) This gives (both on 0.24.1 and on master): Error compiling Cython file: ------------------------------------------------------------ ... cdef class Base(object): cdef meth(self): return self cdef class Derived(Base): cpdef meth(self): ^ ------------------------------------------------------------ foo.pyx:6:10: 'meth' already defined As second attempt, I could simply not declare the cpdef method in the .pxd file. Just use cdef class Derived(Base): pass This compiles, but leads to bugs with broken vtabs. I am omitting the complete code here, but it's clear why this cannot work: other modules get the vtab wrong since they don't know about the cpdef slot. Jeroen.

1 1

(Possible) bug: module level global vars end up in upper scope?
by Yury V. Zaytsev July 27, 2016

July 27, 2016

Hi, I've hit the following deviation from Python 2: when a Cython module has a global variable, somehow, upon importing the module, the global variables end up in the *current* (importing) module scope, rather than *imported* module scope, and, while normally relatively harmless, in the case of namedtuples, for instance, this has caused pickling errors in our production code. test1.py / test2.pyx import collections Test = collections.namedtuple("Test", ["test"]) $ ipython Python 2.7.6 (default, Jun 22 2015, 17:58:13) IPython 1.2.1 -- An enhanced Interactive Python. In [1]: import test1 In [2]: test1.Test Out[2]: test1.Test In [3]: import test2 In [4]: test2.Test Out[4]: __main__.Test I would appreciate any hints in the case that I'm deeply confused and doing something obviously wrong... -- Sincerely yours, Yury V. Zaytsev

2 2

Cython infrastructure
by Robert Bradshaw July 24, 2016

July 24, 2016

Since the inception of the Cython project, William Stein's generously allowed us to share Sage's hardware to host Cython's infrastructure, which has been a great help. However, I think the time has come to re-evaluate our options, which have actually improved a lot over the last couple of years. Note that this is not simply an issue of finding hardware, or raw VMs, as we want to cut down on the personal maintenance costs as well (both ongoing and emergency, neither of which are suited to a small number of volunteers). Several years ago we moved the main repositories over to github, and the wiki was moved a while ago as well (to solve the spam problem). However, the web site, trac (for bugs), and jenkins (for continuous testing) are still on UW hardware. I propose we address them as follows: cython.org Currently cython.org consists of a single landing page, a pile of release tarballs, and all the documentation (which is 100% generated from the repository). I propose we rely on github pages for the (small) site, pypi for tarball archiving, and http://cython.readthedocs.io (I recently got admin permission for) for the documentation. trac.cython.org This is probably the most controversial, but I think it makes sense to migrate to github issues. While clearly not as powerful, featureful, or customizable as trac, it seems it would fulfill our modest needs. I am happy to do the migration if no one objects. jenkins This is the hardest to replace. We have travis.ci which integrates well with github (e.g. automatically checking pull requests) but is much more limited (e.g. it doesn't have artifact caching, there's no way we'd have enough CPU to build and test the latest pre-releases of CPython, let alone all of Sage). This has been where UW's hardware has been something we simply couldn't get anywhere else. There are really three parts to this: (1) the configuration (2) the hosting of the jeknins server and (3) the build slaves themselves. (3) is ephemeral, and ideally could come and go with little friction as people and institutions are willing to donate raw horsepower (e.g. UW). I'm not sure about (2)--that requires a single machine at least (but less beefy than those for (3)). Ideally (1) could be under revision control (e.g. in a git repository) allowing us to set up (2) and (3) easily. Anyone have any input/experience on this? Or can travis-ci be adopted to be a sufficient replacement? All of this puts a lot in the hands of one company (github). I highly doubt they're going away, but because of the distributed nature of Git even if they disappeared nothing permanent would be lost. I would also set up a script to periodically backup github issues which is the one non-repo-backed service we use. (Is it worth also trying to archive github pr discussion? Maybe set up a and subscribe mailing list just for that?) - Robert

7 15

bug report
by swapnil jariwala July 21, 2016

July 21, 2016

Hello all, trac.cython.org does not open for me, I've come across an error while trying the tutorial, I've elaborated the same in below question http://stackoverflow.com/questions/38386722/how-to-resolve-error-error-comp… any help would be highly appreciated. Thanks Swapnil

2 1

PEP 520 -- Preserving Class Attribute Definition Order
by Stefan Behnel July 18, 2016

July 18, 2016

Hi all! Here's a nice PEP that seems easy to implement in Cython. It has been accepted for inclusion in Python 3.6. https://www.python.org/dev/peps/pep-0520/ Any volunteers? Please reply on the cython-devel mailing list. Stefan

1 0

PEP 487 -- Simpler customisation of class creation
by Stefan Behnel July 18, 2016

July 18, 2016

Hi all! Here's a nice PEP that we should implement in Cython. It has been accepted for inclusion in Python 3.6. https://www.python.org/dev/peps/pep-0487/ We should at least support it for all Cython implemented Python classes. Backporting it to older CPython versions would then require an internally defined metaclass, since Python itself would otherwise not support it for subclasses. Any volunteers? Please reply on the cython-devel mailing list. Stefan

1 0

Cython 0.24.1 released
by Stefan Behnel July 18, 2016

July 18, 2016

Hi all! I just pushed a bug-fix-only release for the current 0.24 series. The update should be safe for everyone using 0.24. https://pypi.python.org/pypi/Cython/0.24.1 Complete changelog follows below. SHA1 sum: a837efb73c195585ce6e27cf53e3587285ccd39f Cython-0.24.1.tar.gz Have fun, Stefan 0.24.1 (2016-07-15) =================== Bugs fixed ---------- * IPython cell magic was lacking a good way to enable Python 3 code semantics. It can now be used as "%%cython -3". * Follow a recent change in PEP 492 and CPython 3.5.1 that now requires the "__aiter__()" method of asynchronous iterators to be a simple "def" method instead of an "async def" method. See https://www.python.org/dev/peps/pep-0498/ * Coroutines and generators were lacking the "__module__" special attribute. * C++ "std::complex" values failed to auto-convert from and to Python complex objects. * Namespaced C++ types could not be used as memory view types due to a lack of name mangling. Patch by Ivan Smirnov. * Assignments between identical C++ types that were declared with differently typedefed template types could fail. * Rebuilds could fail to evaluate dependency timestamps in C++ mode. Patch by Ian Henriksen. * Macros defined in the "distutils" compiler option do not require values anymore. Patch by Ian Henriksen. * Minor fixes for MSVC, Cygwin and PyPy.

3 3