typedef array regression

487 views
Skip to first unread message

Jason Grout

unread,
Apr 26, 2013, 10:03:18 PM4/26/13
to cython...@googlegroups.com
I'm seeing some code that worked in Cython 0.17 [1], but does not work
in 0.17.4 or in the current 0.19 release.

-------------------------
cdef struct a:
int b
int c

ctypedef a a_t[1]

cdef class MyClass:
cdef a_t _a

cpdef set(MyClass m, int b, int c):
cdef a *myvar = m._a
myvar.b = b
myvar.c = c

cpdef get(MyClass m):
cdef a *myvar = m._a
print myvar.b
print myvar.c
---------------------------

This won't compile in newer Cython versions, giving an error of "error:
incompatible types in assignment", pointing to the lines in get and set
where myvar is assigned. It seems to work fine in Cython 0.17, though.

In recent Cython versions (0.17.4, 0.19), the set and get functions
generate code that looks like this to do the first assignment of the
myvar pointer to m._a:

__Pyx_RefNannyDeclarations
__pyx_t_1s_a_t __pyx_t_1;

[snip]

__pyx_t_1 = __pyx_v_m->_a;
__pyx_v_myvar = __pyx_t_1;

However, in Cython 0.17, the assignment is done directly, without going
through the pyx_t_1 variable:

__pyx_v_myvar = __pyx_v_m->_a;


So...

1. Is this an intentional regression? I didn't see anything that seemed
connected to this in the release notes. I did see someone else that has
the same error:
http://stackoverflow.com/questions/13485364/cant-install-kivy-cython-gcc-error

2. I realize now that it's probably cleaner just to write my code as:

----------------------
cdef struct a:
int b
int c

cdef class MyClass:
cdef a _a

cpdef set(MyClass m, int b, int c):
cdef a *myvar = &m._a
myvar.b = b
myvar.c = c

cpdef get(MyClass m):
cdef a *myvar = &m._a
print myvar.b
print myvar.c
---------------------------
However, do you know of a nice workaround that touches just the get and
set functions? This is a simplified example---in the real example,
these are functions that call into the Sage library (using the Sage
bitsets), and it would be useful if I could get a workaround that didn't
require patching Sage.

Thanks,

Jason


[1] actually, just before version 0.17, which was the version included
in Sage a while ago, from http://trac.sagemath.org/sage_trac/ticket/13029

Jason Grout

unread,
Apr 26, 2013, 10:23:59 PM4/26/13
to cython...@googlegroups.com
On 4/26/13 9:03 PM, Jason Grout wrote:

> However, do you know of a nice workaround that touches just the get and
> set functions? This is a simplified example---in the real example,
> these are functions that call into the Sage library (using the Sage
> bitsets), and it would be useful if I could get a workaround that didn't
> require patching Sage.


I just found a workaround, involving taking the address of the 0th
element of the _a array.

cdef struct a:
int b
int c

ctypedef a a_t[1]

cdef class MyClass:
cdef a_t _a

cpdef set(MyClass m, int b, int c):
cdef a *myvar = &m._a[0]
myvar.b = b
myvar.c = c

cpdef get(MyClass m):
cdef a *myvar = &m._a[0]
print myvar.b
print myvar.c

I suppose the question of whether this is a regression that should be
looked into still stands.

Thanks,

Jason


Robert Bradshaw

unread,
Apr 30, 2013, 2:20:36 AM4/30/13
to cython...@googlegroups.com
This regression certainly isn't intentional, though I'm not sure how
hard it will be to fix.
> --
>
> --- 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
Reply all
Reply to author
Forward
0 new messages