gmane.comp.python.cython.user

Cythonize is special?

Shriramana Sharma — 2013-05-19T11:46:05

Hello. How exactly is:

from distutils.core import setup
from Cython.Build import cythonize
setup(
    name = "My hello app",
    ext_modules = cythonize('hello.pyx'), # accepts a glob pattern
)

different from:

from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
setup (
ext_modules = [ Extension ( "hello", [ "hello.pyx" ] ) ],
cmdclass    = { "build_ext" : build_ext }
)

Is it just that the former is somewhat shorter, especially seeing as
the docstring for cythonize says: ""Compile a set of source modules
into C/C++ files and return a list of distutils Extension objects for
them.""

Or is there any other essential difference that makes using Cythonize
preferable to manually specifying the Extension params?

Thanks.

Win7 Python 2.7 Cython helloworld example compile error ! help ,please

杨雪峰 — 2013-05-18T15:54:45

Hi all:

     I am a new user of Cython. I install it by the Anaconda package. When 
i try the example on the website, i get the following problem !

Setup.py 
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext

setup(
    cmdclass = {'build_ext': build_ext},
    ext_modules = [Extension("helloworld", ["helloworld.pyx"])]
)

the pyx file is just a print 'hello world' 

the Error :

running build_ext
skipping 'helloworld.c' Cython extension (up-to-date)
building 'helloworld' extension
C:\MinGW\bin\gcc.exe -DMS_WIN64 -mdll -O -Wall -IC:\Anaconda\include 
-IC:\Anaconda\PC -c helloworld.c -o 
build\temp.win-amd64-2.7\Release\helloworld.o
writing build\temp.win-amd64-2.7\Release\helloworld.def
creating build\lib.win-amd64-2.7
C:\MinGW\bin\gcc.exe -DMS_WIN64 -shared -s 
build\temp.win-amd64-2.7\Release\helloworld.o 
build\temp.win-amd64-2.7\Release\helloworld.def -LC:\Anaconda\libs 
-LC:\Anaconda\PCbuild\amd64 -lpython27 -lmsvcr90 -o 
build\lib.win-amd64-2.7\helloworld.pyd
build\temp.win-amd64-2.7\Release\helloworld.o:helloworld.c:(.text+0x85): 
undefined reference to `_imp__PyOS_snprintf'
build\temp.win-amd64-2.7\Release\helloworld.o:helloworld.c:(.text+0x8d): 
undefined reference to `_imp__Py_GetVersion'
build\temp.win-amd64-2.7\Release\helloworld.o:helloworld.c:(.text+0x108): 
undefined reference to `_imp__PyOS_snprintf'
build\temp.win-amd64-2.7\Release\helloworld.o:helloworld.c:(.text+0x129): 
undefined reference to `_imp__PyErr_WarnEx'
build\temp.win-amd64-2.7\Release\helloworld.o:helloworld.c:(.text+0x146): 
undefined reference to `_imp__PyTuple_New'
build\temp.win-amd64-2.7\Release\helloworld.o:helloworld.c:(.text+0x170): 
undefined reference to `_imp__PyString_FromStringAndSize'
many undefined reference like the things above  and the final line is as 
following:
collect2: ld ¨Z¨e¨[¨n 1
error: command 'gcc' failed with exit status 1

Can anybody help me ? i know little about the gcc compiler. i supposed the 
problem may be caused by the mingw.

thanks !!

Cython c compiler setting

杨雪峰 — 2013-05-18T18:22:57

Hi all

       I follow the instruction 
from http://wiki.cython.org/64BitCythonExtensionsOnWindows  try to use 
windows c compiler to build python extension. but cython are still using 
mingw gcc to compile my files which cause many undefined reference errors.

      it became green words after i command setenv /x64 /release 

C:\Users\Yang 
Xuefeng\Dropbox\workspaces\pythonxy\autoencoders\Cythonlearning\te 
st>python setup.py build_ext running build_ext skipping 'helloworld.c' 
Cython extension (up-to-date) building 'helloworld' extension 
C:\MinGW\bin\gcc.exe -DMS_WIN64 -mdll -O -Wall -IC:\Anaconda\include 
-IC:\Anacon da\PC -c helloworld.c -o 
build\temp.win-amd64-2.7\Release\helloworld.o writing 
build\temp.win-amd64-2.7\Release\helloworld.def C:\MinGW\bin\gcc.exe 
-DMS_WIN64 -shared -s build\temp.win-amd64-2.7\Release\hell oworld.o 
build\temp.win-amd64-2.7\Release\helloworld.def -LC:\Anaconda\libs -LC: 
\Anaconda\PCbuild\amd64 -lpython27 -lmsvcr90 -o 
build\lib.win-amd64-2.7\hellowor ld.pyd 
build\temp.win-amd64-2.7\Release\helloworld.o:helloworld.c:(.text+0x85): 
undefin ed reference to `_imp__PyOS_snprintf'

please , help me !


regards

Yang Xuefeng

First Cython ModuleI

Aidin Hasanzadeh — 2013-05-18T12:05:42

Hey,

I am new with Cython and starting my first module. I am using 
eclipse/Ubunty. I installed cython and tried to implement the very first 
example, Hello world.

http://docs.cython.org/src/userguide/tutorial.html

I made the setup file, but importing Cython.Distutils could not be resolved.

from distutils.core import setupfrom distutils.extension import Extensionfrom Cython.Distutils import build_ext
setup(
    cmdclass = {'build_ext': build_ext},
    ext_modules = [Extension("helloworld", ["helloworld.pyx"])])



Thanks for any help
Aidin

Type error

Pedro Camargo — 2013-05-19T00:33:36

Hi guys,

                  I'm working on a fairly long code that is compiling
correctly, but giving an error when it runs.

 

                I'm working on Windows 64 bits, Python 2.7 (last installer
made available) and the last versions of the installers for
Numpy/Scipy/Cython  made by Chris Gohlke.

 

Thanks for the help,

                

Pedro

 

The error is:

 

File "Assignment2.pyx", line 493, in Assignment._Ordering_and_Forward_Star
(Assignment2.c:6242)

    cdef _Ordering_and_Forward_Star(np.ndarray[ITYPE_t, ndim=2, mode='c']
graph, #A_Node/B_Node

ValueError: Buffer dtype mismatch, expected 'ITYPE_t' but got 'long long'

 

 

 

It points to this header:

 

cdef _Ordering_and_Forward_Star(np.ndarray[ITYPE_t, ndim=2, mode='c'] graph,
#A_Node/B_Node

                    np.ndarray[ITYPE_t, ndim=2, mode='c'] g_aux,

                    np.ndarray[DTYPE_t, ndim=2, mode='c'] graph_data,

                    np.ndarray[DTYPE_t, ndim=2, mode='c'] g_aux2,

                    np.ndarray[ITYPE_t, ndim=1, mode='c'] ind,

                    np.ndarray[ITYPE_t, ndim=1, mode='c'] graph_fs):

 

 

And the matrices are dimensioned and the function called this way:

 

graph=np.zeros((l,2), dtype=ITYPE) #Holds node of origin and node of
destination

graph_fs=np.zeros(nodes+1, dtype=ITYPE)  #Holds the Forward star for the
graph

graph_data=np.zeros((l,2), dtype=DTYPE) #Holds data for the graph. First
column is the nested utility and the second the utility used for Shortest
path

.

g_aux=graph.copy() #to sort the indices

g_aux2=graph_data.copy()

 

_Ordering_and_Forward_Star(graph,

                               g_aux,

                               graph_data,

                               g_aux2,

                                ind,

                                graph_fs)

 

Searching the problem I saw references to a problem of 32 Vs. 64 bits, but
when I tried with 32 bits I get this:

 

C:\Users\Pedro\Desktop\Paths test>c:\Python27\python setup_Assignment.py
build_e

xt --inplace

running build_ext

skipping 'Assignment2.c' Cython extension (up-to-date)

building 'Assignment' extension

Traceback (most recent call last):

  File "setup_Assignment.py", line 23, in <module>

    include_dirs=[np.get_include()])

  File "c:\Python27\lib\distutils\core.py", line 152, in setup

    dist.run_commands()

  File "c:\Python27\lib\distutils\dist.py", line 953, in run_commands

    self.run_command(cmd)

  File "c:\Python27\lib\distutils\dist.py", line 972, in run_command

    cmd_obj.run()

  File "c:\Python27\lib\site-packages\Cython\Distutils\build_ext.py", line
163,

in run

    _build_ext.build_ext.run(self)

  File "c:\Python27\lib\distutils\command\build_ext.py", line 339, in run

    self.build_extensions()

  File "c:\Python27\lib\site-packages\Cython\Distutils\build_ext.py", line
171,

in build_extensions

    self.build_extension(ext)

  File "c:\Python27\lib\distutils\command\build_ext.py", line 498, in
build_exte

nsion

    depends=ext.depends)

  File "c:\Python27\lib\distutils\msvc9compiler.py", line 473, in compile

    self.initialize()

  File "c:\Python27\lib\distutils\msvc9compiler.py", line 383, in initialize

    vc_env = query_vcvarsall(VERSION, plat_spec)

  File "c:\Python27\lib\distutils\msvc9compiler.py", line 299, in
query_vcvarsal

l

    raise ValueError(str(list(result.keys())))

ValueError: [u'path']

 

C:\Users\Pedro\Desktop\Paths test>

for loop with variable step not optimized

Josh Ayers — 2013-05-19T00:01:09

I just noticed that a for-loop using the standard Python range construct 
isn't optimized to C-code if the step is a run-time variable.  It is 
optimized if the step parameter is a compile-time constant, or if the old 
Pyrex style for-loop syntax is used.  I tested with Cython 0.18 and 0.19.1 
and both behaved the same way.

Here's a minimal example.

DEF STEP = 2

def loops():
    cdef int i, start = 0, stop = 10, step = 2

    for i in range(start, stop, step): # generates Python loop
        print(i)

    for i in range(start, stop, STEP): # generates C loop
        print(i)

    for i from start <= i < stop by step: # generates C loop
        print(i)

Is this a bug?

Thanks,
Josh Ayers

Spiro Python interface using Cython

Shriramana Sharma — 2013-05-18T06:37:40

Spiro is an algorithm for producing smooth splines given a set of
on-curve control points. I am working on polishing the library. I
wrote a Python interface using Cython (thanks to all those who develop
it!).

The Spiro library uses callbacks, hence my recent in doing that in
Cython. I am happy to say I have been successful. The attached code
demonstrates it to whoever can spend the time to read it. The code is
under the GPLv3+. (Note: you don't need to worry about the internals
of spiro.c -- just look at spiro.h and bezctx.h to understand the
library being wrapped.)

I have one question: Clang generates the warning:

spiro_cy.c:653:1: warning: declaration does not declare anything
[-Wmissing-declarations]
spiro_cp;
^~~~~~~~
1 warning generated.

Why is this and what should I do to fix it? Thanks.

OSX 10.8: setuptools generates gcc command that wants to use to use .c instead of .cpp

Justin Israel — 2013-05-18T01:55:23

This is a strange issue that happens for my project only when someone with 
OSX 10.8 (mountain lion) tries to build the extension. I don't have 10.8 so 
I am still waiting on a colleague to forward me a dump of the literal 
failure, but I figured I could start the question now and provide more info 
if needed.

The issue is pretty straight forward. On <=10.7.x, when building the 
extension in place, it properly respects the language="c++" Extension 
attribute. It cythonizes the pyx => cpp, and runs the proper gcc command to 
build.

On 10.8.x, it seems it is cythonizing the cpp file just fine, but then it 
generates a gcc command that is trying to compile a .c that does not exist, 
obviously. The way I can get it to succeed is if I modify my setup file to 
not use cython. Then I manually cythonize the pyx => cpp, and have it use 
the cpp source directly in the setuptools Extension (I have one of those 
common use_cython style flag setups that I just force to False). 

Does anyone offhand know what might be an issue on osx 10.8? I know apple 
mucked with the compiler setups a whole bunch, and have seen my fair share 
of posts containing "problems compiling XYZ on 10.8", requiring some 
special adjustment. I know that the person who encountered this error had 
freshly installed the xcode command-line tools to get their compilers, and 
had no previous setup for building from source code until they were trying 
to build my extension.

Example setup.py code looks like:

...
cmdclass = {}
if use_cython:
    SRC = 'foo.pyx'
    cmdclass['build_ext'] = build_ext
else:
    SRC = 'foo.cpp'
...
ext = Extension('plow.client.plow',
    [SRC],
    language="c++",
    libraries=[...], 
    extra_compile_args=cflags,
    extra_link_args=ldflags,
    define_macros=[...]
)
...
setup(
   ...
    ext_modules = [ext],
    cmdclass=cmdclass,
   ...
)

Sorting algorithm

Pedro Camargo — 2013-05-17T00:06:26

Hi,

                I’m currently working on a cdef function inside a cython
(indexing numpy arrays) module and I need to sort a numpy array (actually
need the argsort). How can I proceed?

 

Can I just call array_index=np.argsort(array). Wouldn’t it defeat the
purpose of array indexing?  Does anybody have a sorting algorithm in Cython
they could share? Couldn’t find anything online.

 

Thanks,

Pedro

cython's property and nondata descriptors

Nils Bruin — 2013-05-16T17:18:47

Two questions about cython's "property:" directive.

1] In python, a nondata descriptor is a descriptor that doesn't have
its '__set__' slot filled. Such descriptors can be overridden by
entries in the instance '__dict__'. One might expect that specifying a
cython "property" without giving a "__set__" method would lead to such
an entry, but it doesn't: It leads to a datadescriptor that cannot be
overridden by instance attributes:

%cython
cdef class T(object):
    property B:
        def __get__(self):
            return 1


AttributeError: attribute 'B' of 'T' objects is not writable

This mirrors the < at >property decorator in python but it makes it hard to
specify nondata descriptors. Are there thoughts about how to make it
more convenient to declare nondata descriptors

2] Using the < at >property decorator in a cdef class works, but leads to
less efficient code:

%cython
cdef class T(object):
    property B:
        def __get__(self):
            return 1
    < at >property
    def C(self):
        return 1

625 loops, best of 3: 78.6 ns per loop
625 loops, best of 3: 275 ns per loop

would it be desirable to automatically transcribe "< at >property" to
"property .."? Perhaps not, since the semantics of the two are
different and both are valid, but I expect it's a common pitfall for
people who try to translate python to cython code.

static typing of mpf type variables in cython

Ecython — 2013-05-16T01:54:50

Hello,

I am a new user of cython. I am working with mpf variables in python
but would like to know its static version in cython for speed up.

For example I was looking for something similar like the following:

python: N=10                                     static typing via cython: 
cdef int N=10

Is there a similar way to do this with mpf variables? something like:

python:                                              What would be the 
equivalent static
                                                         version in cython?
from mpmath import mpf
N=mpf(10)                                          cdef mpf_t N=10 ? (but 
this doesn't work?)

Thank you,

build error using cython on OS X and Python 3.3 -- __time_t appearing from nowhere

রামি চৌধুরি — 2013-05-14T14:48:58

Hi everyone,

I'm having an error building a Cython module on OS X, using Python 3.3.

The code I'm trying to build 
is https://github.com/esplorio/couchbase-python-client/tree/pylibcouchbase

Function pointer as part of a C struct

Alexander Eisenhuth — 2013-05-13T09:50:51

Hello everybody,

I want to use a callback as part of a C struct with read/write access. 
Is this possible? The following describes the problem. And if you can 
help, how do I connect a python function to the callback?

Any help welcome!

Regards
Alexander

---- stderr of compiling Device.pyx ---
Error compiling Cython file:
------------------------------------------------------------
...
     def __setattr__(self, name, value):
         print "DeviceDescriptor_.__setattr__", name, value
         if name == "deviceNumber":
             self._device_descriptor.deviceNumber = <Uint8> value
         elif name == "deviceMeasurement":
             self._device_descriptor.deviceMeasurement = 
<DeviceMeasureFunc> value
                                                        ^
------------------------------------------------------------
Device.pyx:55:56: Python objects cannot be cast to pointers of primitive 
types

----- Device.h ----
typedef ErrorStatus (*DeviceMeasureFunc)(Uint32*);

typedef struct DeviceDescriptorTag
{
Uint8 deviceNumber;
DeviceMeasureFunc deviceMeasurement;

} DeviceDescriptor;
------- Device.pyx ---
cdef extern from "Device.h":

     ctypedef ErrorStatus (*DeviceMeasureFunc)(Uint32*)

     ctypedef struct DeviceDescriptor_c "DeviceDescriptor":
         Uint8 deviceNumber
         DeviceMeasureFunc deviceMeasurement

cdef class DeviceDescriptor:

     cdef DeviceDescriptor_c _device_descriptor

     def __getattr__(self, name):
         ret_val = None
         if name == "deviceNumber":
             ret_val = self._device_descriptor.deviceNumber
         else:
             self.__raise_attrib_not_found(name)
         return ret_val

     def __setattr__(self, name, value):
         if name == "deviceNumber":
             self._device_descriptor.deviceNumber = <Uint8> value
         elif name == "deviceMeasurement":
             self._device_descriptor.deviceMeasurement = 
<DeviceMeasureFunc> value
         else:
             self.__raise_attrib_not_found(name)

     def __raise_attrib_not_found(self, name):
         raise AttributeError("Attribute %s not in %s" % (name, type(self)))

TypeError: can't apply this setattr

Shriramana Sharma — 2013-05-12T07:24:41

For practice, I am implementing a subclass of builtins.list in Cython
which will store only str-s and has one data member "approved" which
should take only a boolean. It's entirely Python syntax except that it
has a cdef at the head.

However I am getting a TypeError saying "can't apply this __setattr__"
when I try to initialize an object of this type:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "strlist.pyx", line 24, in strlist.strlist.__init__ (strlist.c:1215)
    self.approved = False
  File "strlist.pyx", line 33, in strlist.strlist.__setattr__ (strlist.c:1417)
    super().__setattr__ ( name, value )
TypeError: can't apply this __setattr__ to strlist.strlist object

OTOH when I try the same using the pure Python implementation of the
class (i.e. just removed cdef) I have no problem:

strlist(<super: <class 'strlist'>, <strlist object>>,approved=False)

The code is attached. Can anyone please help me figure out what I'm
doing wrong? Thanks.

if condition transformation to switch-case

Alok Singhal — 2013-05-11T20:52:36

Consider the following code:

cdef extern from "errno.h":
    enum:
        EWOULDBLOCK
        EAGAIN

cdef int is_eagain(int i):
    return i != EWOULDBLOCK and i != EAGAIN

The code checks for EWOULDBLOCK and EAGAIN both, although they could be the 
same (on linux for example).  This is mostly done for portability (for 
example, see the "Portability note" at 
http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Error-Codes.html#index-EAGAIN-97
).

Cython transforms the above code to:

  switch (__pyx_v_i) {
    case EWOULDBLOCK:
    case EAGAIN:
    __pyx_t_1 = 0;
    break;
    default:
    __pyx_t_1 = 1;
    break;
  }

If EWOULDBLOCK == EAGAIN, this results in compilation error since the two 
case labels are the same.

For my immediate use, I changed my code to only test for EAGAIN, but is 
there a better way to write the code so that I can still use both 
EWOULDBLOCK and EAGAIN?

Thanks,
Alok

Cython 0.19.1 released

Stefan Behnel — 2013-05-11T09:01:02

Hi all,

Cython 0.19.1 is following the course of the recent 0.19 release. This is
mainly a bug fix release that adds only minor new features and fixes some
bugs and regressions in the latest release. Upgrading is generally recommended.

You can get it from here:

http://cython.org/release/Cython-0.19.1.tar.gz

http://cython.org/release/Cython-0.19.1.zip

Release notes:
https://github.com/cython/cython/blob/8f07f8d8265799cada5046fe0b7c0807d7b41fb3/CHANGES.rst

Documentation: http://docs.cython.org/


Major changes include:

* A warning is emitted when negative literal indices are found inside of
  a code section that disables ``wraparound`` handling.  This helps with
  fixing invalid code that might fail in the face of future compiler
  optimisations.

* A regression in 0.19 was fixed that rejected valid C expressions from
  being used in C array size declarations.

* Testing large (> int) C integer values for their truth value could fail
  due to integer wrap-around.

* The automatic signature documentation tries to preserve more semantics
  of default arguments and argument types.  Specifically, ``bint``
  arguments now appear as type ``bool``.


Have fun,

Stefan

Numpy access reduces reference count. Numpy array not recognized?

Martin Fiers — 2013-05-11T08:17:49

Dear Cython community!

Yesterday I bumped onto a fairly involved problem regarding numpy buffers. 
The basic idea is that I wanted to send a numpy-generated array from a 
self-made C++ class (TestObject.h) to a cython function 
(pass_np_array.pyx). Apparently, there's something wrong with the reference 
counting and the code crashes after a few cycles.

I made a minimal working example, which can be found in attachment, because 
it's fairly involved. To run locally, you can extract the tar and call 
run_test.sh.

Comments are inside the test file test_pass_array.py and in the pyx file 
which I inline here because most information is in there.

I also tried compiling with the refnanny support to see if there's 
something wrong there. But it seems it doesn't detect counting errors. For 
more information, see the test_pass_array.py.


pass_np_array.pyx
------------------------------------

import numpy as np
cimport numpy as np
import cython

cdef extern from "TestObject.h":
    cdef cppclass TestObject:
        TestObject()
        
        # Create a numpy array, and deliberately increase refcount to 
demonstrate crash.
        void create_object(int additional_refcount)
        
        # Does this actually help defining the buffer correctly?
        np.ndarray[complex, ndim=1] get_numpy_array()
        



cdef print_object(TestObject obj):

    # First problem: I need an explicit cast arr = obj.get_numpy_array()
    # So I cannot access the matrix elements using obj.get_numpy_array()[0]
    cdef np.ndarray[complex, ndim=1] arr
    
    # Second problem:
    # In cython, the code below generates __pyx_t_1 = ((PyObject 
*)__pyx_v_obj.get_numpy_array()); 
    # I guess this is wrong behavior, as this decreases the reference count 
later (Py_GOTREF/...)
    # Something like PyArray_FromArray would maybe be more appropriate, but 
hacking the generated cpp file
    # and adding PyArray_FromArray does not resolve the problem.
    arr = obj.get_numpy_array()
    
    # Printing the reference count: After each call to print_object, the 
reference count decreases.
    import sys
    print 'Ref count arr: ', sys.getrefcount(arr)
    
    print arr[0]
    
    # The code below crashes the cython compiler  "Compiler crash in 
AnalyseExpressionsTransform"
    #print obj.get_numpy_array()[0]
    
    # (all the problems above are probably related to the fact that the 
get_numpy_array 
    # does not contain the correct information)
    
def run():
    cdef TestObject O
    O = TestObject()
    
    # Run Py_INCREF twice on the created object
    O.create_object(2)

    # First time it works
    print_object(O)
    
    # Second time: reference counting went down with one!?
    # We deliberately increased the ref-count in TestObject in 
create_object.
    print_object(O)

    print_object(O)
    
    # On the line below it will SEGFAULT/GLIBC/double corrupted list, or 
other 
    # nice crash
    print_object(O) 

    print_object(O)


Thank you for looking at this problem!

Regards,
Martin

Numpy array reference count decreases with each function call

Martin Fiers — 2013-05-11T08:04:35

Hello,

I think I found some bug in the reference counting of numpy buffers. I 
isolated the part to make a minimal working example, which can be found in 
the attachment. After extracting, you can call run_test.sh which compiles 
the example and crashes. I tested cython-0.17,0.18 and 0.19.

The idea is that TestObject.h creates a numpy array and passes it to a 
cython function. It appears, after a full day of debugging and searching on 
the internet, that there's something wrong with reference counting and I 
cannot directly access the buffer. My guess is that it's caused by the 
get_numpy_array not being recognized correctly by the cython compiler. I 
inlined some of the possible causes/problems in comments.

Eventually, the program crashes because the reference counting decreases 
with one each time the function is called.
Also, I compile with the refnanny support to see if there's something wrong 
there. But it seems it doesn't detect counting errors. For more 
information, see the test_pass_array.py.

If there is no easy fix, is there some kind of workaround in order to keep 
the object 'alive'?

Here's the pyx file to illustrate the problems (for full working example, 
see attachment):


import numpy as np
cimport numpy as np
import cython

cdef extern from "TestObject.h":
    cdef cppclass TestObject:
        TestObject()
        
        # Create a numpy array, and deliberately increase refcount to 
demonstrate crash.
        void create_object(int additional_refcount)
        
        # Does this actually help defining the buffer correctly?
        np.ndarray[complex, ndim=1] get_numpy_array()
        

cdef print_object(TestObject obj):

    # First problem: I need an explicit cast arr = obj.get_numpy_array()
    # So I cannot access the matrix elements using obj.get_numpy_array()[0]
    cdef np.ndarray[complex, ndim=1] arr
    
    # Second problem:
    # In cython, the code below generates __pyx_t_1 = ((PyObject 
*)__pyx_v_obj.get_numpy_array()); 
    # I guess this is wrong behavior, as this decreases the reference count 
later (Py_GOTREF/...)
    # Something like PyArray_FromArray would maybe be more appropriate, but 
hacking the generated cpp file
    # and adding PyArray_FromArray does not resolve the problem.
    arr = obj.get_numpy_array()
    
    # Printing the reference count: After each call to print_object, the 
reference count decreases.
    import sys
    print 'Ref count arr: ', sys.getrefcount(arr)
    
    print arr[0]
    
    # The code below crashes the cython compiler  "Compiler crash in 
AnalyseExpressionsTransform"
    #print obj.get_numpy_array()[0]
    
    # (all the problems above are probably related to the fact that the 
get_numpy_array 
    # does not contain the correct information)
    
def run():
    cdef TestObject O
    O = TestObject()
    
    # Run Py_INCREF twice on the created object
    O.create_object(2)

    # First time it works
    print_object(O)
    
    # Second time: reference counting went down with one.
    # We deliberately increased the ref-count in TestObject in 
create_object.
    print_object(O)

    print_object(O)
    
    # On the line below it will SEGFAULT/GLIBC/double corrupted list, or 
other 
    # nice crash
    print_object(O) 

    print_object(O)

Thank you for helping me solve this quite complex problem!
Martin

Using Clang

Shriramana Sharma — 2013-05-10T11:17:14

This is really probably a distutils thing and not Cython-specific but
I don't want to subscribe to yet another mailing list for this one
thing so:

What do I have to change in the setup.py file to use Clang i.o. GCC
for compiling my Cython modules?

Thanks.

Two potential bugs in Cython 0.19

Gabriel Jacobo — 2013-05-09T15:49:38

I've just got two user reports of issues compiling my engine with Cython
0.19 (which are not present in Cython 0.18).

The statement "import time", produces a "cythonization" error of

import time, sys
      ^
------------------------------------------------------------

backends/sdl/GameLoop.pyx:16:7: Assignment to non-lvalue 'time'


The other error happens when compiling. On certain modules (not all, I
haven't figured out the reason why yet) I get ‘PyDateTime_IMPORT’ and
PyDateTimeAPI undeclared symbols errors.

Are these bugs or is there some new requirement on Cython 0.19 I'm not
complying with? (additional imports required, etc)

Thanks for any help!

Python headers not a dependency for Cython?

Shriramana Sharma — 2013-05-09T12:08:57

I'm using Kubuntu Raring and surprisingly the cython and cython3
packages don't seem to depend on the python-dev and python3-dev
packages -- they only "suggest" them (green bullets):

http://packages.ubuntu.com/raring/cython
http://packages.ubuntu.com/raring/cython3

Likewise they don't depend on gcc, but then again there are other C compilers.

IIUC python-dev and python3-dev should be dependencies since it is not
possible to compile Cython files without the Python headers. if this
is correct, then I'll file a Debian packaging bug.