Hi,

2010/12/1 renaud blanch <rndbl...@gmail.com>

> > i'm trying to make some pyopengl [0] -based code [1] run on top of pypy.
> > this is partially successful, but i need some advice to progress further.
> > pyopengl 3.x makes use of ctypes to provide the opengl binding, and it
> > works out of the box for simple functions (those that do not takes
> > c-pointer to buffers of data as arguments).
> > for the rest, the first issue is that pyopengl use two functions from
> > the ctypes.pythonapi lib, namely PyString_AsString and
> > PyBuffer_FromMemory.
> > any advice on how to replace those functions to make them compatible with
> > pypy?
> >
> > Mike Fletcher (pyopengl author) gave me some hints about that point:
> >> For the first issue, those are going to require some reworking, in
> >> essence those are "C" implemented code that happens to use Python/ctypes
> >> as the implementation language and makes assumptions about the
> >> data-storage for the objects (e.g. that a string is internally a
> >> contiguous series of bytes, which is *not necessarily* true in PyPy).
> >> We'd need to find a mechanism in PyPy that would give us that direct
> >> memory-pointer access to be able to use it.  Note: a compacting garbage
> >> collector (or anything else that can move memory locations) will cause
> >> problems there, so we may need to find a way to signal PyPy not to move
> >> a given object, and to use contiguous data-arrays for their storage.
>

Don't worry, with PyPy's ctypes you'll never get the address of a moving
object.
c_char_p makes a non-moving copy of the string.

But IMO the call to pythonapi.PyString_AsString could be removed in
OpenGL/arrays/strings.py:

def dataPointer(value):
    return ctypes.cast(ctypes.c_char_p(value), ctypes.c_void_p).value

I don't know about the other function, though.

-- 
Amaury Forgeot d'Arc
_______________________________________________
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Reply via email to