Ondrej Certik | 1 Jul 02:26
Picon
Gravatar

[Cython] accessing ctype array's b_ptr

Hi,

I need to access ctype array's b_ptr. The array is defined in
Python-2.6.2/Modules/_ctypes/ctypes.h  as:

struct tagCDataObject {
    PyObject_HEAD
    char *b_ptr;        /* pointer to memory block */
    int  b_needsfree;   /* need _we_ free the memory? */
    CDataObject *b_base;    /* pointer to base object or NULL */
    Py_ssize_t b_size;  /* size of memory block in bytes */
    Py_ssize_t b_length;    /* number of references we need */
    Py_ssize_t b_index; /* index of this object into base's
                   b_object list */
    PyObject *b_objects;    /* dictionary of references we need to
keep, or Py_None */
    union value b_value;
};

So I wrote this cython code:

cdef extern from "Python.h":
    ctypedef void PyTypeObject

cdef struct CDataObject:
    Py_ssize_t ob_refcnt
    PyTypeObject *ob_type
    char *b_ptr

and then I use it like this:
(Continue reading)

Lisandro Dalcin | 1 Jul 02:42
Picon
Gravatar

Re: [Cython] accessing ctype array's b_ptr

On Tue, Jun 30, 2009 at 9:26 PM, Ondrej Certik<ondrej@...> wrote:
>
> However, this assumes some particular form of PyObject_HEAD. Once it
> changes, my code will segfault.
>

Indeed. That changes when you use a debug build of Python (./configure
--with-pydebug).

> So I guess the right way to do this is
> to write my own C header file with the above struct (e.g. using the
> PyObject_HEAD macro) and then just reference it using:
>
> cdef extern from "Python.h":
>    ctypedef void PyTypeObject
>
> cdef extern from "my_header.h":
>    ctypedef struct CDataObject:
>        char *b_ptr
>
> which should always work.
>
> What do you think?
>

Provided that ctypes.h is not a public header, I would do exactly the
same as you...

PS: Can you believe that ctypes, being intended to be a tool for easy
interoperation with C code, does not provide a public C API in order
(Continue reading)

Ondrej Certik | 1 Jul 03:07
Picon
Gravatar

Re: [Cython] accessing ctype array's b_ptr

On Tue, Jun 30, 2009 at 6:42 PM, Lisandro Dalcin<dalcinl <at> gmail.com> wrote:
> On Tue, Jun 30, 2009 at 9:26 PM, Ondrej Certik<ondrej <at> certik.cz> wrote:
>>
>> However, this assumes some particular form of PyObject_HEAD. Once it
>> changes, my code will segfault.
>>
>
> Indeed. That changes when you use a debug build of Python (./configure
> --with-pydebug).
>
>> So I guess the right way to do this is
>> to write my own C header file with the above struct (e.g. using the
>> PyObject_HEAD macro) and then just reference it using:
>>
>> cdef extern from "Python.h":
>>    ctypedef void PyTypeObject
>>
>> cdef extern from "my_header.h":
>>    ctypedef struct CDataObject:
>>        char *b_ptr
>>
>> which should always work.
>>
>> What do you think?
>>
>
> Provided that ctypes.h is not a public header, I would do exactly the
> same as you...
>
> PS: Can you believe that ctypes, being intended to be a tool for easy
(Continue reading)

Ondrej Certik | 1 Jul 03:14
Picon
Gravatar

Re: [Cython] accessing ctype array's b_ptr

On Tue, Jun 30, 2009 at 7:07 PM, Ondrej Certik<ondrej <at> certik.cz> wrote:
> On Tue, Jun 30, 2009 at 6:42 PM, Lisandro Dalcin<dalcinl <at> gmail.com> wrote:
>> On Tue, Jun 30, 2009 at 9:26 PM, Ondrej Certik<ondrej <at> certik.cz> wrote:
>>>
>>> However, this assumes some particular form of PyObject_HEAD. Once it
>>> changes, my code will segfault.
>>>
>>
>> Indeed. That changes when you use a debug build of Python (./configure
>> --with-pydebug).
>>
>>> So I guess the right way to do this is
>>> to write my own C header file with the above struct (e.g. using the
>>> PyObject_HEAD macro) and then just reference it using:
>>>
>>> cdef extern from "Python.h":
>>>    ctypedef void PyTypeObject
>>>
>>> cdef extern from "my_header.h":
>>>    ctypedef struct CDataObject:
>>>        char *b_ptr
>>>
>>> which should always work.
>>>
>>> What do you think?
>>>
>>
>> Provided that ctypes.h is not a public header, I would do exactly the
>> same as you...
>>
(Continue reading)

Lisandro Dalcin | 1 Jul 03:27
Picon
Gravatar

Re: [Cython] accessing ctype array's b_ptr

On Tue, Jun 30, 2009 at 10:07 PM, Ondrej Certik<ondrej@...> wrote:
>
> One more question. I am using ctypes because using it I can take a
> list of floats and create a C array of it:
>
> (c_float * len(ptr))(*ptr)
>
> from historical reasons (I am adapting some opengl example from
> pyglet, that used that approach --- since pyglet uses ctypes to wrap
> opengl).

You can even use the builtin array.array to convert a list of float to
an array of floats.. Of course. Next you will need to make some Python
C-API calls to get the pointer to the memory buffer. The second part
is what I'm currently doing in mpi4py, and it is working from Py2.3 to
Py3.1

>
>I use cython, so I think a better way is to use numpy?
>

If the numpy dependency is not a problem, perhaps this is the better way.

> opengl supports strides, but it's just one number, e.g. it has to be
> the same for all rows (as opposed to numpy). Is it safe to just copy
> the numpy array, to make sure it's contiguous and then just use the
> pointer to the .data member of ndarray? That's what I always do, but I
> don't know if this is the safe or best approach.
>

(Continue reading)

Lisandro Dalcin | 1 Jul 03:30
Picon
Gravatar

Re: [Cython] accessing ctype array's b_ptr

On Tue, Jun 30, 2009 at 10:14 PM, Ondrej Certik<ondrej@...> wrote:
>
> Ah, I think I am wrong. Numpy's strides is exactly what I need, right?
>
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.strides.html
>
> so I just take *any*  numpy array, as long as it has the right dtype,
> and then just pass the pointer to .data and strides to the opengl
> function.
>

Perhaps it works... Just in case, test it with a numpy array using
Fortran ordering, perhaps OpenGL does not like it?

BTW, do arrays with more than two dimensions make sense in OpenGL? Do
you know exactly what numpy strides mean (any nd-array have
nd-strides, even the contiguous ones) ?

--

-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Ondrej Certik | 1 Jul 04:08
Picon
Gravatar

Re: [Cython] accessing ctype array's b_ptr

On Tue, Jun 30, 2009 at 7:30 PM, Lisandro Dalcin<dalcinl <at> gmail.com> wrote:
> On Tue, Jun 30, 2009 at 10:14 PM, Ondrej Certik<ondrej <at> certik.cz> wrote:
>>
>> Ah, I think I am wrong. Numpy's strides is exactly what I need, right?
>>
>> http://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.strides.html
>>
>> so I just take *any*  numpy array, as long as it has the right dtype,
>> and then just pass the pointer to .data and strides to the opengl
>> function.
>>
>
> Perhaps it works... Just in case, test it with a numpy array using
> Fortran ordering, perhaps OpenGL does not like it?

So far all functions in opengl use 1D arrays only.

>
> BTW, do arrays with more than two dimensions make sense in OpenGL? Do
> you know exactly what numpy strides mean (any nd-array have
> nd-strides, even the contiguous ones) ?

Yes, a stride is the number of bytes you need to move your pointer to
get to the next element in the array. opengl only accepts 1D arrays,
but it *does* accept a stride.

Can it happen, that a 1D numpy array has stride which is bigger than
sizeof(dtype)? so far I didn't manage to create one.

Ondrej
(Continue reading)

Robert Bradshaw | 1 Jul 06:11
Favicon

Re: [Cython] accessing ctype array's b_ptr

On Jun 30, 2009, at 7:08 PM, Ondrej Certik wrote:

> On Tue, Jun 30, 2009 at 7:30 PM, Lisandro Dalcin<dalcinl@...>  
> wrote:
>> On Tue, Jun 30, 2009 at 10:14 PM, Ondrej Certik<ondrej@...>  
>> wrote:
>>>
>>> Ah, I think I am wrong. Numpy's strides is exactly what I need,  
>>> right?
>>>
>>> http://docs.scipy.org/doc/numpy/reference/generated/ 
>>> numpy.ndarray.strides.html
>>>
>>> so I just take *any*  numpy array, as long as it has the right  
>>> dtype,
>>> and then just pass the pointer to .data and strides to the opengl
>>> function.
>>>
>>
>> Perhaps it works... Just in case, test it with a numpy array using
>> Fortran ordering, perhaps OpenGL does not like it?
>
> So far all functions in opengl use 1D arrays only.
>
>>
>> BTW, do arrays with more than two dimensions make sense in OpenGL? Do
>> you know exactly what numpy strides mean (any nd-array have
>> nd-strides, even the contiguous ones) ?
>
> Yes, a stride is the number of bytes you need to move your pointer to
(Continue reading)

Ondrej Certik | 1 Jul 06:24
Picon
Gravatar

Re: [Cython] accessing ctype array's b_ptr

On Tue, Jun 30, 2009 at 10:11 PM, Robert
Bradshaw<robertwb <at> math.washington.edu> wrote:
> On Jun 30, 2009, at 7:08 PM, Ondrej Certik wrote:
>
>> On Tue, Jun 30, 2009 at 7:30 PM, Lisandro Dalcin<dalcinl <at> gmail.com>
>> wrote:
>>> On Tue, Jun 30, 2009 at 10:14 PM, Ondrej Certik<ondrej <at> certik.cz>
>>> wrote:
>>>>
>>>> Ah, I think I am wrong. Numpy's strides is exactly what I need,
>>>> right?
>>>>
>>>> http://docs.scipy.org/doc/numpy/reference/generated/
>>>> numpy.ndarray.strides.html
>>>>
>>>> so I just take *any*  numpy array, as long as it has the right
>>>> dtype,
>>>> and then just pass the pointer to .data and strides to the opengl
>>>> function.
>>>>
>>>
>>> Perhaps it works... Just in case, test it with a numpy array using
>>> Fortran ordering, perhaps OpenGL does not like it?
>>
>> So far all functions in opengl use 1D arrays only.
>>
>>>
>>> BTW, do arrays with more than two dimensions make sense in OpenGL? Do
>>> you know exactly what numpy strides mean (any nd-array have
>>> nd-strides, even the contiguous ones) ?
(Continue reading)

Chris Colbert | 1 Jul 19:52
Picon
Gravatar

[Cython] how would I wrap something like this in a .pxd file

In wrapping a C library, I come across many #define statements that I
need to use elsewhere. When they simply define a constant, I use an
anonymous enum and all is well.

But how would I wrap something like this that shown up in a header
file that i'm cdef extern'ing from:

#define CV_TREE_NODE_FIELDS(node_type)                               \

    int       flags;                \

    int       header_size;          \

    struct    node_type* h_prev;      \

    struct    node_type* h_next;     \

    struct    node_type* v_prev;       \

    struct    node_type* v_next ;

or something like this:

#define CV_IS_STORAGE(storage)  \

    ((storage) != NULL &&       \

    (((CvMemStorage*)(storage))->signature & CV_MAGIC_MASK) ==
CV_STORAGE_MAGIC_VAL)

(Continue reading)


Gmane