Robert Bradshaw, 10.09.2013 02:14:
>>> Wow. The first version of this PR used Cython memoryviews, which added a
>>> whopping 14 kLOC of generated C to the repo. Switched back to bare pointers
>>> to keep the compile times within bounds.
>> It would be interesting to hear the Cython team's point o
On Sep 12, 2013, at 6:33 PM, Stefan Behnel wrote:
> Robert Bradshaw, 10.09.2013 02:14:
Wow. The first version of this PR used Cython memoryviews, which added a
whopping 14 kLOC of generated C to the repo. Switched back to bare
pointers to keep the compile times within bounds.
>>
Robert Bradshaw, 12.09.2013 23:02:
> Thanks for the careful analysis. See
> https://github.com/cython/cython/commit/e8b54dec4cdc94764abda4a107bc37dcd58e6f13
Might be possible to merge it with this special case:
https://github.com/cython/cython/blob/master/Cython/Compiler/Code.py#L50
and/or make
Thanks for the careful analysis. See
https://github.com/cython/cython/commit/e8b54dec4cdc94764abda4a107bc37dcd58e6f13
On Tue, Sep 10, 2013 at 3:26 PM, Dénes Vadász wrote:
> Hello,
>
> according to valgrind the following Cython fragment causes a heap corruption
> (with Python 2.7.5 and Cython 0.19
Hi,
A few weeks ago I started an implementation of that simple usecase:
cdef long a[2], x, y
# set a[0] and a[1] to some useful values
x, y = a
It does works, but I’m not used to the interactions between the
different parts of the code, I mainly hacked away where I could. I’m
especially diss
