Mailman 3 October 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 coverage and multiple projects
by Masood Malekghassemi Oct. 29, 2015

Oct. 29, 2015

I'd asked this of Robert Bradshaw earlier and was pointed in this direction (specifically towards Stefan), so here goes! I'm having trouble with getting Cython to play nicely with the coverage.py tool via the Cython.Coverage plug-in. We have tests that are running from a different setup.py project than the one which contains the Cython files (the projects respectively being for the duration of this discussion the 'tests' project and the 'source' project). The generated coverage file contains the line data for individual .pyx files, but the paths of the .pyx files themselves *within* the .coverage file appear to be rooted in the tests project rather than the site-packages folder in which the source project's files were installed (i.e. paths that never exist throughout the edit-build-test cycle). After editing the .coverage file manually to point to the source project directory, coverage.py reports that the .pyx files are not python files and errors out... but the .coveragerc file contains the plug-in module via `[run]\n plugins = Cython.Coverage`, so I'd have expected the Cython coverage.py plug-in to catch those files and handle them instead of letting the rest of coverage.py get confused over them. Furthermore, this is against the 4.0 coverage.py release rather than the 4.0b2 coverage.py release (which appears to be the version against which the latest edit to the Cython code base was made). I don't see any API differences between the two in the plug-ins, but I might have missed something so maybe that's relevant. A secondary issue: the .pyx files are never copied over to the installation directory, so even if the paths were 'correct' (with respect to being copied into the site-packages folder or being accessible via developer mode pip-installs), they wouldn't be found. This seems like it wouldn't necessarily be an issue from a cursory glance at the source code as the file tracer in the Cython coverage.py plug-in appears to spit out blank lines in such a scenario. Complicating matters further, we're running the tests through pytest. That said, I've given up on trying to get pytest-cov to play nicely with this until I can get a manual invocation of `coverage report ...` to produce output describing the .pyx files. Thanks for reading this far. Got any pointers? ---------------------------------------------------------------- Context: https://github.com/soltanmm/grpc/tree/cy-wip/src/python Basic steps to run the tests: - cd $GRPC_REPOSITORY_ROOT - make - CONFIG=opt ./tools/run_tests/build_python.sh 2.7 - CONFIG=opt PYVER=2.7 ./run_tests/run_python.sh

2 3

Do we really need realpath()?
by Jeroen Demeyer Oct. 28, 2015

Oct. 28, 2015

Hello, I am currently profiling Cython's dependency-checking code when compiling the SageMath Cython library. I am skipping the actual cythonization, so it's really just the first "for m in module_list" loop in cythonize(). I noticed that about 10% of total time is spent in os.path.realpath() calls in Cython/Build/Dependencies.py. Do we really need realpath()? Isn't abspath() sufficient? These realpath() calls have been introduced in commit 1bfd57ef7b1a350135024b19a9352411a952c553 Author: R. Andrew Ohana <andrew.ohana(a)gmail.com> Date: Tue Apr 9 14:03:19 2013 -0700 copy sources and depends instead of headers Jeroen.

2 1

[Bug] Generator comprehension not compiling
by Carlos Pita Oct. 25, 2015

Oct. 25, 2015

Hi, in cython 0.24.0a0 this: ---------- import cython as cy @cy.cfunc def f(cats): ''.join(c for c in cats) ---------- fails to compile with: Compiler crash in AnalyseDeclarationsTransform. Nevertheless the following close variations do compile: ---------- import cython as cy @cy.cfunc def f(cats): ''.join([c for c in cats]) ---------- ---------- cdef f(cats): ''.join(c for c in cats) ---------- Cheers -- Carlos

1 1

'Class' redeclared error if C++ class & file name match those of the wrapper class
by Nathan Goldbaum Oct. 22, 2015

Oct. 22, 2015

Hi all, I'm forwarding this at the request of David Nemesky ("savior" on Freenode), who I've been chatting with on the cython IRC channel. He was having trouble signing up to the cython-devel mailing list, so I've gone ahead and sent his bug report in for him. His report follows below. Apparently this error happens under very specific circumstances, but I managed to run into them. When wrapping a C++ class, Cython reports a "'ClassName' redeclared" error, if: - the name of the .pyx is the same as the name of the .pxd - the name of the python class is the same as the name of the C++ class Mismatch in either the file- or the class name results in a successful compilation. I have modified my fork of the cython-cpp-test repo to make the issue easily reproducible. In https://github.com/DavidNemeskey/cython-cpp-test/, try `python setup.py build_ext --inplace` (do not forget to delete all .cpp and .so files between calls) in the following branches: - cython_bug (diff file, diff class) -> OK - diff_file_same_class -> OK - same_file_diff_class -> OK - same_file_same_class -> ERROR (https://bpaste.net/show/2c1af5fa5ee2) Since Cython compiles xxx.pyx to xxx.cpp in this case, in order to avoid problems with testclass.cpp being overwritten, I implemented the class in testclass.hpp (in the original repo, there was a .h and a .cpp file). However, implementing everything in the header is not a pre-requisite of the bug, as is evident from branch same_file_same_class_diff_c.

2 1

keyword argument to prange() for num_threads gives undefined error
by Thouis (Ray) Jones Oct. 22, 2015

Oct. 22, 2015

I couldn't find this in the Cython Trac, but forgive me if it's been addressed already. One of my students ran into the bug referenced in this cython-users post: https://groups.google.com/forum/#!topic/cython-users/xYZLKPAwmTE It appears that keyword arguments to functions can't be used as the value for prange(num_threads=...). It's unclear why, but it causes my compiler to crash with "undefined variable __pyx_v_num_threads". I don't have a trac account, but could set one up to file this, if necessary. Ray Jones

1 0

[Refactor] Emulated types
by Carlos Pita Oct. 18, 2015

Oct. 18, 2015

Hi, I'm in the process of refactoring the emulated types in Shadow, in order to simplify a bit that part of the module. Ultimately I want to add support for declaring typed memory views in pure python (currently it's only possible to declare them as strings, Shadow does implement the slicing part -tho it's messy here- but the parser is unable to get them right from decorators). But before that I'd like to simplify things a bit, as I've said, and before that I need to get a good grasp of what I'm trying to simplify, so I'd better hear your opinion about the following points first: 1) Shadow allows creating array types like this: cython.array(cython.int, 10) but the compiler will complain that cython.array is an unknown type. 2) Furthermore Shadow allows to instantiate every type: cython.int(10), cython.array(cython.int, 20)(), etc. The compiler rejects all these constructs, so I see little point in supporting this feature. I think that disallowing these features (AFAICS completely unsupported by the compiler) will simplify the code a lot and will allow to merge the "shameless copy" section in a more coherent fashion. Is there any compelling reason to keep them? What is/was their rationale? Cheers -- Carlos

1 3

[Bug] Unable to cast to python type.
by Carlos Pita Oct. 18, 2015

Oct. 18, 2015

Hi, import cython as cy y = cy.cast('list', x) fails to compile with "AttributeError: 'TypecastNode' object has no attribute 'typecheck'". But the following examples do compile: y = <list> x y = cy.cast('int', x) Cheers -- Carlos

1 1

Bug in list comprehension
by Leandro Pereira de Lima e Silva Oct. 17, 2015

Oct. 17, 2015

Hello, I've think I've found a bug in Cython (or is this just a funny feature?). The error occurs when the variable name used as source for the iteration is also used as a value. Given the files test1.pyx (cython) and test2.py (python): test1.pyx: def test(): x = range(10) return [x for x in x] test2.py: def test(): x = range(10) return [x for x in x] The results in running them are: >>> import test1, test2 >>> test1.test() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "test1.pyx", line 4, in test1.test (/Users/leandro/.pyxbld/temp.macosx-10.6-intel-3.4/pyrex/test1.c:666) return [x for x in x] UnboundLocalError: local variable 'x' referenced before assignment >>> test2.test() [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> A regular for loop will behave correctly: code: def test(): x = range(10) ret = [] for x in x: ret.append(x) return ret result: >>> import test1, test2 >>> test1.test() [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> test2.test() [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> Cheers, Leandro

2 1

Exposing C++'s <iterator>
by Kevin Thornton Oct. 16, 2015

Oct. 16, 2015

Hello, I was wanting to use C++s' back_inserter in Cython, and I got it working. I'm writing the list to ask about what more I should do before submitting a pull request. In short, the following definitions were sufficient: ##Define the basic iterator types (this is incomplete) cdef extern from "<iterator>" namespace "std": cdef cppclass iterator[Category,T,Distance,Pointer,Reference]: pass cdef cppclass output_iterator_tag: pass #The goal here is to get back_inserter working, as it is handy. cdef cppclass back_insert_iterator[T](iterator[output_iterator_tag,void,void,void,void]): pass back_insert_iterator[CONTAINER] back_inserter[CONTAINER](CONTAINER &) ##Not shown here, but I've gotten C++11's move algorithm to work, too, ##using same kind of prototype cdef extern from "<algorithm>" namespace "std": OUTPUT copy[INPUT,OUTPUT](INPUT,INPUT,OUTPUT) I've worked up a tiny test package that is on GitHub: https://github.com/molpopgen/cython_cpp_iterators The tests work, and I can indeed copy amongst C++ containers. I've also gotten the C++ move algorithm to work. The prototype is the same as for 'copy' above. I'd be willing to define the remaining classes from <iterator> and add a .pxd file. Any input would be appreciated. Thanks, Kevin

1 0