Mailman 3 May 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

Cygwin: Handling missing C99 long double functions
by Erik Bray June 7, 2016

June 7, 2016

Hi again, Sorry if I'm spamming the list too much, but I've encountered another pretty serious and unfortunate issue with Cython on Cygwin. The problem now is that many of libm long double functions like sqrtl, tanl, etc. are missing on Cygwin (missing from newlib to be specific). I think this is a previously known issue, but nothing's ever really been done about it. Well, to be clear, sometimes they're present, but only when sizeof(double) == sizeof(long double). However on 64-bit Cygwin sizeof(long double) == 16, so the functions are simply not defined. This seems to be due to lack of interest / effort: https://www.cygwin.com/ml/cygwin/2011-04/msg00231.html That post is 5 years old, but I can't find any evidence that this has changed. There are quite a few tests in Cygwin's test suite that test long double support. I guess what I'm asking is what would be the best thing to do about it. I could just skip those tests on Cygwin, though I'm not sure the best way to go about skipping an entire test for a given platform. More generally though, outside the context of testing, this means Cygwin will sometimes generate code that cannot be compiled on this platform, and a question arises as to what to do about that. I have some thoughts, but am not sure if it's worth discussing any further or not. Thanks, Erik

7 17

Supporting cython.operator in C
by Jeroen Demeyer June 2, 2016

June 2, 2016

The following code cimport cython.operator cdef long foo(long x, long y): return cython.operator.comma(x, y) gives AttributeError: 'CBinopNode' object has no attribute 'analyse_c_operation' Is there any fundamental reason why such operators are only implemented for C++ and not pure C? What would be needed to support such operators in C? Jeroen.

2 8

segfault in 'async def' coroutines
by Yury Selivanov May 19, 2016

May 19, 2016

Hi, Under some circumstances, in asyncio code that runs in uvloop [1], cython code segfaults in cython/Cython/Utility/Coroutine.c: static PyObject * __Pyx_Coroutine_get_qualname(__pyx_CoroutineObject *self) { Py_INCREF(self->gi_qualname); return self->gi_qualname; } "self->gi_qualname" can be NULL. The correct code is probably: __Pyx_Coroutine_get_qualname(__pyx_CoroutineObject *self) { if (self->gi_qualname == NULL) { return __pyx_empty_unicode; } Py_INCREF(self->gi_qualname); return self->gi_qualname; } Thanks, Yury

2 7

async def coroutines miss __module__
by Yury Selivanov May 16, 2016

May 16, 2016

In CPython: >>> async def foo(): pass >>> foo.__module__ '__main__' In Cython, async def coroutines lack __module__ attribute Yury

2 1

missing cimport in module '.' - bug?
by Christoph Groth May 13, 2016

May 13, 2016

Hello, The setup.py script of our package "kwant" uses Cython.Build.cythonize. Everything works well, except that for pyx files that cimport a module from "." an error message is generated. E.g. for the file "kwant/linalg/lapack.pyx" that contains the line from . cimport f_lapack The following message appears whenever setup.py is run: missing cimport in module '.': kwant/linalg/lapack.pyx No error message appears for files that cimport only from somewhere else than ".", e.g.: from .defs cimport gint The said messages do not seem to cause any problems, but they are of course somewhat of a nuiscance. They seem to be created by Cython.Build.Dependencies.cimported_files(). The culprit seems to be the function find_pxd in that module that does not seem to handle properly the case when module is ".". To check out the problem, download "kwant" from PyPI and execute, for example, "./setup.py --help". Cheers, Christoph

2 1

@staticmethod decorator applied twice
by Jeroen Demeyer May 12, 2016

May 12, 2016

When investigating some issue with decorators, I noticed the following stange thing: it seems that the @staticmethod decorator is actually applied twice in some cases. For example, the testsuite file tests/run/static_methods.pyx contains the following code: cdef class A: @staticmethod def static_def(int x): ... The relevant part of the Cython-generated code: __pyx_t_1 = PyCFunction_NewEx(&__pyx_mdef_14static_methods_1A_1static_def, NULL, __pyx_n_s_static_methods); ... PyTuple_SET_ITEM(__pyx_t_2, 0, __pyx_t_1); __pyx_t_1 = __Pyx_PyObject_Call(__pyx_builtin_staticmethod, __pyx_t_2, NULL); ... if (PyDict_SetItem((PyObject *)__pyx_ptype_14static_methods_A->tp_dict, __pyx_n_s_static_def, __pyx_t_1) < 0) ... __pyx_t_1 = __Pyx_GetNameInClass((PyObject *)__pyx_ptype_14static_methods_A, __pyx_n_s_static_def); ... PyTuple_SET_ITEM(__pyx_t_2, 0, __pyx_t_1); __pyx_t_1 = __Pyx_PyObject_Call(__pyx_builtin_staticmethod, __pyx_t_2, NULL); ... if (PyDict_SetItem((PyObject *)__pyx_ptype_14static_methods_A->tp_dict, __pyx_n_s_static_def, __pyx_t_1) < 0) I might be missing something, but this really looks like Cython is applying the @staticmethod decorator twice.

1 1

Illegal C code generated with numpy complex type
by Jeroen Demeyer May 12, 2016

May 12, 2016

Current Cython git master breaks SageMath because Cython generates calls to non-existing functions like fabs_npy_float64(). Since this is a regression since Cython 0.24, I made a blocker ticket http://trac.cython.org/ticket/879 Jeroen.

1 0