Mailman 3 August 2012 - cython-devel

C++ STL iteration bugs
by Stefan Behnel Aug. 20, 2012

Aug. 20, 2012

Hi, I ran into a couple of problems with the new C++ STL integration, just dumping them here for now. Invalid C code when using a stack allocated C++ vector inside of a generator, also lacking type conversion utility code: https://github.com/cython/cython/commit/d0a8e24720c3ed4e723b5a1b204bf375780… Failure to compile iteration over pointer to C++ vector, apparently a type inference bug: https://github.com/cython/cython/commit/edd10c3b33afcac8f471ac6d6664e29f2d9… I may not be able to take a serious look at them within the next week but would like to see them fixed for the release, so I'd be happy if someone can manage to work on them. Stefan

3 10

new arrayarray.h header file not C99 compatible
by Stefan Behnel Aug. 20, 2012

Aug. 20, 2012

Hi, I'm getting test build failures with the new arrayarray.h header file when I enable "--std=c89" or "c99" in the CFLAGS: """ memoryview_inplace_division.c:877: warning: declaration does not declare anything memoryview_inplace_division.c:893: warning: declaration does not declare anything memoryview_inplace_division.c: In function ‘newarrayobject’: memoryview_inplace_division.c:929: error: ‘arrayobject’ has no member named ‘ob_item’ ... """ The lines it warns about (and which trigger the subsequent errors) are the following union declarations: """ typedef struct arrayobject { PyObject_HEAD union { Py_ssize_t ob_size, length; }; union { char *ob_item; float *_f; double *_d; int *_i; unsigned *_I; unsigned char *_B; signed char *_b; char *_c; unsigned long *_L; long *_l; short *_h; unsigned short *_H; Py_UNICODE *_u; void *_v; }; ... """ Apparently, anonymous unions only became part of the C standard in C11: http://stackoverflow.com/questions/3228104/anonymous-union-within-struct-no… That's unfortunate, but I think we'd best give the unions a name (and let users change all code that uses them ...). BTW, is there any reason we have a "length" field at all? Shouldn't we be using Py_SIZE() ? Stefan

2 4

In-place division in memoryview, ndarray causes compiler error
by Matthew Brett Aug. 20, 2012

Aug. 20, 2012

Hi, For this file: <file1> def div1(int[:] A): A[0] /= 1 </file1> or this one: <file2> def div2(object[int, ndim=1] A): A[0] /= 1 </file2> I get: File "/Users/mb312/usr/local/lib/python2.7/site-packages/Cython/Compiler/Nodes.py", line 354, in generate_execution_code stat.generate_execution_code(code) File "/Users/mb312/usr/local/lib/python2.7/site-packages/Cython/Compiler/Nodes.py", line 4536, in generate_execution_code if c_op in ('/', '%') and self.lhs.type.is_int and not code.directives['cdivision']: AttributeError: 'CCodeWriter' object has no attribute 'directives This is only for in-place division. I'm using current trunk: Cython version 0.17b2 Cheers, Matthew

2 1

Templated attributes in extensions classes in 0.17 Beta 2
by Brett Calcott Aug. 19, 2012

Aug. 19, 2012

I'm not sure if this is a bug in 0.17 beta or not. But something is not working. Default-constructed attributes in an extension definition appear to work (though I can't see where they are documented on the site…) So this works: ----test.h -------- #include <vector> struct Attributes { std::vector<int> v; }; -----test.pyx------ from libcpp.vector cimport vector cdef extern from "test.h": cdef cppclass Attributes: vector[int] v cdef class Test: cdef Attributes a def __cinit__(self, list x): self.a.v = x However, if I try to put the templated attribute in directly: ----test2.pyx------ from libcpp.vector cimport vector cdef class Test: cdef vector[int] v def __cinit__(self, list x): self.v = x cython compiles it fine, but I get an error in the cpp compilation: test2.cpp:722:23: error: expected a type new((void*)&(p->v)) std::vector(); So it looks like it's doing the funky in place construction, but not getting the template parameters in there… Should this work? Cheers, Brett

2 1

Add includes to generated header files
by Jeff Copeland Aug. 11, 2012

Aug. 11, 2012

I'm working on some C++ projects and I'm using cython to embed python code. In an effort to make things easy for C++ devs not as familiar with cython/python I've made a small change to insert #includes in generated header files the same as is done in generated c code. This allows one who is using code processed with cython to just include the header and not worry about any other headers that may be required to match data types. Not having these headers is especially problematic because otherwise the error message presented at compilation can sometimes be quite cryptic. Patch is attached. Any reason this should not be done? Thanks, Jeff

2 4

Anyone for a doc cleanup before the release?
by Stefan Behnel Aug. 10, 2012

Aug. 10, 2012

Hi, building the documentation currently yields a number of Sphinx warnings: https://sage.math.washington.edu:8091/hudson/job/cython-docs/lastSuccessful… It would be nice if someone found the time to clean some of them up. Stefan

3 5

remaining open issues for 0.17
by Stefan Behnel Aug. 10, 2012

Aug. 10, 2012

Hi, please correct me if I'm missing something, but besides the fused types default value thing, I currently see two open issues for 0.17. One is the 32bit problem we have in the buffer code, the other one is the "vile hack" that Robert added as a type inference fix. I just ran into the following code (while compiling Django) which currently crashes the compiler, and I think it's due to one of those "type inference modifies state" issues. """ def func(**kwargs): """ >>> sorted(func(a=3, b=4)) [1, 2, 3, 4] """ return [ arg for arg in [1,2] + kwargs.values() ] """ How should we deal with these? Personally, I consider general C code portability issues more annoying than code that fails to compile but that can be worked around by users. So, unless we can fix the default values and/or the type inference issues soonishly, I would concentrate on the 32bit issues for now and release 0.17 when we get them resolved. Thoughts? Stefan

6 21

Re: [Cython] Cython Debian builds - failing cygdb tests
by Stefan Behnel Aug. 10, 2012

Aug. 10, 2012

Hi, Yaroslav Halchenko retried the test run on Sparc and all code related bugs seem to be resolved now (I had to fix a few minor endianess bugs). However, the cygdb tests still fail, but do not lead to a test run failure. Yaroslav Halchenko, 10.08.2012 01:05: > tested current 0.16rc1-591-g5de843a on sparc -- indeed resolved ;) but > then also mentioned that at the beginning there is a separate batch of > tests "inside gdb" which seems to fail... they (some or all) also fail > on i386 where I have started to rerun now after installing gdb. Full > log from sparc: > http://www.onerussian.com/tmp/0.16rc1-591-g5de843a-sparc-tests-output.txt > > Since gdb might or might not be installed (it is not listed in > Build-Depends of the debian package but neither conflicts with having > gdb installed) on the build host -- if those failures could be > just ignored, I better exclude them explicitly (I guess with > --exclude=Debugger) Is that the expected behaviour? Or is there just something missing in the build server setup, maybe something wrong with the gdb Python plugin? It looks like it's doing something, though... Stefan

3 3

Bitey
by Dag Sverre Seljebotn Aug. 9, 2012

Aug. 9, 2012

https://github.com/dabeaz/bitey Dag -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

1 0

automatically raise MemoryError on exceptional C return values
by Stefan Behnel Aug. 9, 2012

Aug. 9, 2012

Hi, given how ubiquitous manual memory management is in C, I think it would be nice to let Cython generate the exception raising also for C, not only for C++. The difference is this: cdef extern from "...": char* make_new_buffer() except NULL as MemoryError int append_to_buffer(char* buffer, char* value) \ except -1 as MemoryError c_buffer = make_new_buffer() # raises MemoryError on NULL append_to_buffer(c_buffer, "testdata") # raises MemoryError on -1 append_to_buffer(c_buffer, "moredata") # raises MemoryError on -1 versus this: cdef extern from "...": char* make_new_buffer() int append_to_buffer(char* buffer, char* value) c_buffer = make_new_buffer() if c_buffer is NULL: raise MemoryError() if append_to_buffer(c_buffer, "testdata") == -1: raise MemoryError() if append_to_buffer(c_buffer, "moredata") == -1: raise MemoryError() I don't think it's necessary to support this for anything but MemoryError, since you'd normally want a formatted error message for everything else. Alternative colours for the bike shed: char* make_new_buffer() except NULL raise MemoryError char* make_new_buffer() raise MemoryError for NULL char* make_new_buffer() raise MemoryError from NULL What do you think? Stefan

3 8