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

Re: [Cython] [cython-users] Podcast Interview
by Robert Bradshaw Feb. 26, 2016

Feb. 26, 2016

Craig Citro and I were able to join Tobias for this last month, and the podcast was recently released. Listen to it at http://pythonpodcast.com/cython-developers.html or on your favorite podcast player of choice. On Thu, Dec 31, 2015 at 6:04 AM, Denis Akhiyarov <denis.akhiyarov(a)gmail.com> wrote: > There is also cython-develop mailing list here: > > https://mail.python.org/pipermail/cython-devel/2015-December/thread.html > > -- > > --- > You received this message because you are subscribed to the Google Groups "cython-users" group. > To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

1 0

Bug in 0.24.0a0: bytes passed instead of strings
by Marvin Poul Feb. 23, 2016

Feb. 23, 2016

Hi, when trying to debug cython3 modules from gdb build also with python3, you get a error in gdb plugin code "Python Exception <class 'TypeError'> must be str, not bytes:". This is because in Cython.Debugger.libcython during "cy import" or "cy break" a bytes object is passed to gdb.string_to_argv, but it expects a normal str. I attached a simple fix that worked for me, but I don't know enough about the gdb's plugin system whether it will hold in all cases. The gdb version I ran into this with is 7.10.1.

1 0

Cython-0.23.4 build failing on gcc6 for upcoming fedora 24
by Neal Becker Feb. 21, 2016

Feb. 21, 2016

Anyone able to shed any light on this? Here are the logs: https://kojipkgs.fedoraproject.org//work/tasks/4202/12804202/build.log

6 14

libcpp container definition cleanup
by Yury V. Zaytsev Feb. 15, 2016

Feb. 15, 2016

Hi, I've recently submitted a bunch of pull requests with cleanups for libcpp.string and libcpp.vector, most importantly fixing overloads taking and/or returning iterators and C++11 methods: https://github.com/cython/cython/pull/488 https://github.com/cython/cython/pull/489 I might also manage to take a look at set / map / pair which we likewise need for our projects, but it would be great to get some feedback from the core developers first. If the dominating opinion is that I'm strongly misguided in some way, I'd appreciate a short note before I invest more work into this :-) Many thanks! -- Sincerely yours, Yury V. Zaytsev

1 0

import-free setuptools integration
by Nils Werner Feb. 12, 2016

Feb. 12, 2016

I have implemented some very simple setuptools integration that circumvents the requirement to `import cython` in `setup.py` entirely, doing away with the century-old problem of having to importing requirements during installation: <https://github.com/cython/cython/pull/477> This implementation is inspired by CFFI's setuptools integration: <https://cffi.readthedocs.org/en/latest/cdef.html#distutils-setuptools>. They do not require you to `import cffi` but simply define an additional keyword argument `cffi_modules` for `setup()`. This additional keyword argument _does not raise errors when cffi is not installed yet_ but can be used once cffi is there (as defined in `setup_requires`). Later setuptools will call cffi and have it do whatever it wants with the contents of the argument. Cython can do the exact same. Below you have the usual `setup.py`, with the chicken and egg `import` problem and a few `Extensions` that need to be `cythonize`d: import setuptools from Cython.Build import cythonize # this will fail if cython is not present prior to running `pip install this` from setuptools.extension import Extension extensions = [ Extension("fib", ["fib.pyx"]), Extension("fib2", ["fib2.pyx"]), ] setuptools.setup( name='example', version="1.0.0", packages=setuptools.find_packages(), setup_requires=['cython'], install_requires=['cython'], ext_modules=cythonize(extensions), ) With the changes I am proposing the usual ext_modules=cythonize(extensions), can be replaced with cython_modules=extensions, removing the need for `from Cython.Build import cythonize` and solving the import problem: import setuptools from setuptools.extension import Extension extensions = [ Extension("fib", ["fib.pyx"]), Extension("fib2", ["fib2.pyx"]), ] setuptools.setup( name='example', version="1.0.0", setup_requires=['cython'], # we must later require a Cython version that has this kind of integration install_requires=['cython'], cython_modules=extensions, ) This allows a nicer automated installation of tools that depend on cython and also allows end users to keep their `setup.py` cleaner and leaner. Additionally, I have also extended `cythonize()` a bit and thus allow for definitions like: import setuptools from setuptools.extension import Extension extensions = [ Extension("fib", ["fib.c"]), Extension("fib2", ["fib2.c"]), ] setuptools.setup( name='example', version="1.0.0", extras_require={'cython': ['cython']}, ext_modules=extensions, cython_modules=extensions, ) This will automatically compile pyx->c if cython is installed and a re-compilation is needed. Otherwise it will merely compile c->so. This allows devs to ship the generated C-code (as you suggest per your docs) but takes the heuristic to find out whether to compile pyx->C->so or only C->so completely out of `setup.py` and under control of cython. The change is written to be backwards compatible: - Using `cython_modules` is entirely optional and not using it is sideeffect-free - Having `cythonize()` internally automatically compile *.pyx files when *.c files are provided is disabled by default and must be enabled using the `replace_extension` keyword argument (`cython_modules` enables that option).

2 2

Cython 0.23.4 bug: C++ pairs with unsigned values inside other templates
by Kevin Thornton Feb. 11, 2016

Feb. 11, 2016

Hi, I've come across an odd bug while creating interfaces to existing C++ functions via Cython. If a C++ pair is contained inside of another template type, the pair cannot contain unsigned integers unless a typedef is provided for unsigned. Examples: #This works: cdef vector[pair[char,char]] doit(): cdef vector[pair[char,char]] rv return rv #This fails: cdef vector[pair[unsigned,char]] doit2(): cdef vector[pair[unsigned,char]] rv return rv #But this works: ctypedef unsigned uint cdef vector[pair[uint,uint]] doit3(): cdef vector[pair[uint,uint]] rv return rv #This fails: cdef void doit4( const vector[pair[unsigned,double]] & x): pass --Kevin

1 0

Compiler crash in AnalyseExpressionsTransform / overload resolution with templates
by Yury V. Zaytsev Feb. 11, 2016

Feb. 11, 2016

Hi, I'm trying to improve the declarations in libcpp.string and cover them with unit tests. In this process, I've stumbled upon a compiler crash in overload resolution. A simple reproducer below; if the last line is uncommented, the code compiles just fine: cdef extern from *: cdef cppclass string_helper: cppclass iterator: pass string_helper& insert(size_t, char*, size_t) iterator insert[input_iterator](iterator, input_iterator, input_iterator) def test_insert(): cdef string_helper s cdef string_helper.iterator it s.insert[string_helper.iterator](it, it, it) s.insert(0, <char*>0, 0) zaytsev@work:~/src/cython$ ./cython-git/cython.py --cplus crash.pyx Error compiling Cython file: ------------------------------------------------------------ ... def test_insert(): cdef string_helper s cdef string_helper.iterator it s.insert[string_helper.iterator](it, it, it) s.insert(0, <char*>0, 0) ^ ------------------------------------------------------------ crash.pyx:13:12: Compiler crash in AnalyseExpressionsTransform ModuleNode.body = StatListNode(crash.pyx:1:0) StatListNode.stats[1] = DefNode(crash.pyx:9:0, modifiers = [...]/0, name = u'test_insert', py_wrapper_required = True, reqd_kw_flags_cname = '0', used = True) File 'Nodes.py', line 430, in analyse_expressions: StatListNode(crash.pyx:10:4) File 'Nodes.py', line 4755, in analyse_expressions: ExprStatNode(crash.pyx:13:12) File 'ExprNodes.py', line 519, in analyse_expressions: SimpleCallNode(crash.pyx:13:12, analysed = True, use_managed_ref = True) File 'ExprNodes.py', line 4938, in analyse_types: SimpleCallNode(crash.pyx:13:12, analysed = True, use_managed_ref = True) File 'ExprNodes.py', line 4992, in analyse_c_function_call: SimpleCallNode(crash.pyx:13:12, analysed = True, use_managed_ref = True) Compiler crash traceback from this point on: File "/home/zaytsev/src/cython/cython-git/Cython/Compiler/ExprNodes.py", line 4992, in analyse_c_function_call entry = PyrexTypes.best_match(args, alternatives, self.pos, env) File "/home/zaytsev/src/cython/cython-git/Cython/Compiler/PyrexTypes.py", line 4133, in best_match [pattern.type.deduce_template_params(actual) for (pattern, actual) in zip(func_type.args, arg_types)], File "/home/zaytsev/src/cython/cython-git/Cython/Compiler/PyrexTypes.py", line 3594, in deduce_template_params elif self.empty_declaration_code() == actual.template_type.empty_declaration_code(): AttributeError: 'CIntType' object has no attribute 'template_type' -- Sincerely yours, Yury V. Zaytsev

1 0

Bug: compilation failure with "Template parameter not a type" for pointer & reference types
by Yury V. Zaytsev Feb. 10, 2016

Feb. 10, 2016

Hi, I came across the following bug, while trying to implement iterator versions of std::string members, for which a simple reproducer is below. If the return type of a function is a normal type, then everything is fine, but if it's a pointer or reference type, then Cython refuses to compile it. Could something please be done about that? Many thanks! Error compiling Cython file: ------------------------------------------------------------ ... cdef extern from * nogil: cdef cppclass test: void assign[input_iterator](input_iterator, input_iterator) char assign[input_iterator](input_iterator, input_iterator) char* assign[input_iterator](input_iterator, input_iterator) char& assign[input_iterator](input_iterator, input_iterator) ^ ------------------------------------------------------------ notatype.pyx:6:35: Template parameter not a type -- Sincerely yours, Yury V. Zaytsev

1 2

iterators / libcpp container definitions cleanup, any clues?
by Yury V. Zaytsev Feb. 9, 2016

Feb. 9, 2016

Hi, I've been looking into libcpp container definitions and found that they are kind of messy, in particular, iterators are defined as nested classes for every container. This leads to code duplication, and for certain containers some overloaded methods seem to be missing or conversely declared, but not provided. I was trying to have a stab at cleaning this up and offering patches, but I'm confused as to how to proceed. At first, I thought that I could turn concepts into a hierarchy of inherited classes in `iterator.pxd` like _ForwardIterator -> _BidirectionalIterator -> _RandomAccessIterator and inherit container iterators from those classes. It seems that this is a bad idea for several reasons: 1) Apparently, there are some problems with inheritance, overload resolution and type deduction, e.g. such that Cython deduces `_RandomAccessIterator` as a result type for a + operation instead of `vector[int].iterator` (which inherits from _RandomAccessIterator). 2) Cython thinks these are real classes and uses them in explicit template arguments in generated C++ code. The combination of (1) and (2) causes a lot of fail. The only other possibility that crossed my mind so far was to use the old "include" for code reuse and create files like _RandomAccessIterator.pxi, _RandomAccessIteratorConst.pxi, etc. and include their contents in the container definitions. Sounds terrible, and I guess this wouldn't get merged, even if I get that to work. Now, are there better approaches that I've overlooked? -- Sincerely yours, Yury V. Zaytsev

1 0