Mailman 3 December 2015 - 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

cython 0.23.4 test failure, async_iter_pep492 (), asyncio_generators, test_async_def_future.py
by Dimitri John Ledkov Jan. 14, 2016

Jan. 14, 2016

Hello, Building 0.23.4 fails on ubuntu with python 3.5. Full build log is at: https://launchpadlibrarian.net/228728126/buildlog_ubuntu-xenial-amd64.cytho… First with 2.7, run.asyncio_generators are skipped. Then there is a successful run of asyncio_generators (?!) and then a failed one (?!) The what i think relevant portion of the build log is as follows: async_iter_pep492 () Doctest: async_iter_pep492 ... ok test_aiter_raises (async_iter_pep492) Doctest: async_iter_pep492.test_aiter_raises ... ok test_broken_anext (async_iter_pep492) Doctest: async_iter_pep492.test_broken_anext ... ok test_for_1 (async_iter_pep492) Doctest: async_iter_pep492.test_for_1 ... ok test_for_2 (async_iter_pep492) Doctest: async_iter_pep492.test_for_2 ... ok test_for_3 (async_iter_pep492) Doctest: async_iter_pep492.test_for_3 ... ok test_with_for (async_iter_pep492) Doctest: async_iter_pep492.test_with_for ... ok runTest (__main__.EndToEndTest) End-to-end asyncio_generators ... FAIL runTest (__main__.CythonRunTestCase) compiling (c) and running attr ... attr () Doctest: attr ... /usr/bin/python3.5 test_async_def_future.py Traceback (most recent call last): File "test_async_def_future.py", line 16, in <module> runloop() File "test_async_def_future.py", line 14, in runloop assert events == expected, events AssertionError: ['setup', 'setval', None] ok Any help resolving this would help. Is this a broken python3.5? or cython? or both? -- Regards, Dimitri.

2 2

strange error message
by B. Clausius Jan. 5, 2016

Jan. 5, 2016

Hi cython devs, a strange error message, showing cython internals: $ cat gldraw.pxd ctypedef float vec4[4] ctypedef vec4 mat4[4] $ cat glarea.pyx cimport gldraw cdef struct Data: gldraw.mat4 matrix cdef Data data cdef void sync(): data.changed = True # <- this wrong line produces the error $ cython glarea.pyx Error compiling Cython file: ------------------------------------------------------------ ... void PyTuple_SET_ITEM(object p, Py_ssize_t pos, object o) void PyList_SET_ITEM(object p, Py_ssize_t pos, object o) @cname("__Pyx_carray_to_py_vec4") cdef inline list __Pyx_carray_to_py_vec4(vec4 *v, Py_ssize_t length): ^ ------------------------------------------------------------ carray.to_py:112:41: 'vec4' is not a type identifier Error compiling Cython file: ------------------------------------------------------------ ... PyList_SET_ITEM(l, i, value) return l @cname("__Pyx_carray_to_tuple_vec4") cdef inline tuple __Pyx_carray_to_tuple_vec4(vec4 *v, Py_ssize_t length): ^ ------------------------------------------------------------ carray.to_py:124:45: 'vec4' is not a type identifier $ cython --version Cython version 0.23.3 Best regards, B.C.

3 5

Cython coverage and having the package root in a child directory of the coverage working directory
by Masood Malekghassemi Dec. 15, 2015

Dec. 15, 2015

tl;dr: How ought one fix file tracing paths for Cython coverage? Hello y'all, I'm currently trying to integrate C code into the GRPC Python project wherein said code is outside of my control, and belonging to the umbrella GRPC project. The Python+Cython code exists in a subdirectory (i.e. the package_dirs for setup.py includes an entry '': 'src/python/grpcio'). Everything works great, *except* for the Cython coverage plugin. For some strange reason, when the _c_files_map of the Plugin object is created, it appears to assume that the files it's reading are coming directly off of the invocation site of coverage.py as opposed to where the files actually are. Going a bit deeper: in the generated .c file for the .pyx, the package directory stem 'src/python/grpcio' is missing from comments on __Pyx_TraceLine(...): /* "grpc/_cython/cygrpc.pyx":53 * grpc_shutdown() * * _module_state = _ModuleState() # <<<<<<<<<<<<<< * */ This doesn't appear to be a problem for .pxi files, however: /* "src/python/grpcio/grpc/_cython/_cygrpc/server.pyx.pxi":32 * cimport cpython * * import time # <<<<<<<<<<<<<< * * */ We cannot simply move the Cython files around to being relative to umbrella root, as that would involve changing the umbrella project structure beyond the parameters of our current desiderata. I'm currently working around this problem by just ignoring the .pyx file (it contains little code anyway), and keeping only the .pxi files. I'd like to fix this (it doesn't seem difficult), but haven't looked into where one ought to start yet. An aside: we're using .pxi files instead of .pxds now due to some inexplicable behavior wherein a .pxd induces an expectation that a module exists when it doesn't. We're not splitting the extension out into multiple modules because there must now be only one copy of the statically linked gRPC core (wherein static linkage is among recent desiderata for distribution purposes). Context: https://github.com/grpc/grpc/tree/350345ffc70c93295ad5b78b306f9668a6332589 (steps to see what's happening: make; CONFIG=opt ./tools/run_tests/run_python.sh. The relevant C file may be examined under src/python/grpcio/grpc/_cython following the build). Thanks for reading!

1 0

Implementing tp_richcmp using __eq__ etc.
by Emmanuel Gil Peyrot Dec. 1, 2015

Dec. 1, 2015

Hello, I’m trying to implement the compilation of __eq__, __ne__, etc. in extension types, to have them available in pure mode (see ticket #130). I currently have an implementation which basically pastes the body.stats from those six functions in a __richcmp__ one using a template, but I find that very inelegant, as it removes the information about the original location of this code which is very bad for debugging, forces all six (or less) functions to use the same argument names (or rename them), and probably some other issues. So my idea was to convert each of those special function into a CFuncDefNode from a DefNode, in order to remove the Python wrapper, then to implement the new tp_richcmp slot as an util function directly in C. If this plan is sound, I’d like a few more informations, for now mostly about the DefNode to CFuncDefNode conversion, which I’ve been unable to do programmatically, with some later passes complaining about missing base_type or declarator properties. The next question is about determining in the C code whether a specific method exists, and otherwise returning NotImplemented instead. Thanks for listening, I’m not sure I’ve been very understandable, I’m still quite confused. ^^' -- Emmanuel Gil Peyrot

1 0