Re: [Cython] Possible bug related to multiple assignment

2011-06-16 Thread Stefan Behnel 

Andrew Collette, 16.06.2011 04:51:

I ran into some odd behavior when working on my cython-based project
(h5py).  The following cython code snippet is the culprit ("priv" is a
function argument of type void**):

 cdef conv_size_t *sizes
 priv[0] = sizes =malloc(sizeof(conv_size_t))

gets turned into this (with Cython 0.14.1):

 (__pyx_v_priv[0]) = ((__pyx_t_4h5py_5_conv_conv_size_t
*)malloc((sizeof(__pyx_t_4h5py_5_conv_conv_size_t;
 __pyx_v_sizes = ((__pyx_t_4h5py_5_conv_conv_size_t
*)malloc((sizeof(__pyx_t_4h5py_5_conv_conv_size_t;


This is fixed in the latest master branch.

And, yes, we're long overdue for a release.

Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Possible bug related to multiple assignment

2011-06-16 Thread Stefan Behnel 

Stefan Behnel, 16.06.2011 09:46:

Andrew Collette, 16.06.2011 04:51:

I ran into some odd behavior when working on my cython-based project
(h5py). The following cython code snippet is the culprit ("priv" is a
function argument of type void**):

cdef conv_size_t *sizes
priv[0] = sizes =malloc(sizeof(conv_size_t))

gets turned into this (with Cython 0.14.1):

(__pyx_v_priv[0]) = ((__pyx_t_4h5py_5_conv_conv_size_t
*)malloc((sizeof(__pyx_t_4h5py_5_conv_conv_size_t;
__pyx_v_sizes = ((__pyx_t_4h5py_5_conv_conv_size_t
*)malloc((sizeof(__pyx_t_4h5py_5_conv_conv_size_t;


This is fixed in the latest master branch.


Ah, sorry. It was actually broken, even though my test run initially told 
me otherwise. Strange ...


The problem was the C type cast, which was incorrectly considered a 
"simple" expression that didn't need a temporary assignment. Malloc is the 
most obvious case where this hits, as it's almost always used through a cast.


It's fixed now. Thanks for report and example.

Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

[Cython] Test runner changes for Python/PyPy backend

2011-06-16 Thread Stefan Behnel 

Hi,

Romain wants to start writing tests for his Python/ctypes backend branch, 
so we need to extend the test runner.


We'll eventually want to merge his branch back into normal mainline, so I 
suggest actually just running the complete test suite in a new, separate 
configuration, just like we do with C and C++ now. So we'd have a switch 
"--no-ctypes" that disables these tests, and (I assume) a new test class 
(inheriting from the normal compile test case) that properly runs them in 
plain CPython. If the implementation becomes PyPy specific, "--no-pypy" 
will make more sense, but it currently appears to target ctypes in general.


I'm also considering making the backend selection a positive opt-in, i.e. 
switch from "--no-cpp" and friends to "--backends=c,cpp,ctypes". That would 
have avoided the future configuration change in all existing Jenkins test 
jobs (which will then need to disable the new backend tests).


Does that fit everyone's expectations?

There's one problem I see: the ctypes backend will likely have most 
optimisations disabled, so many (most?) of the test tree assertions will 
make no sense. I think it's best to just keep that out of the backend 
specific pipeline completely for now. We have the C/C++ test modes for that.


And, obviously, switching from duplicating to triplicating the test cases 
will substantially increase the time for a complete test run, although a 
lot of the running time is currently spent in the C compiler more than the 
actual test code runs.


Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel