Hello :)

The result of various incompatibilities has left me needing to somehow
extract the address that a null pointer is pointing to with the null
pointer being exposed to python via PyCObject_FromVoidPtr

the code that creates the PyCObject is as follows:
tmp = PyCObject_FromVoidPtr (info.info.x11.display, NULL);
PyDict_SetItemString (dict, "display", tmp);
Py_DECREF (tmp);

which is exposed to python via a dictionary (the 'display' key). python
identifies that its a PyCObject but doesn't give any way to expose the
functionality. Essentially I am after the address that the void pointer
'info.info.x11.display' points to (as a long type)

As far as I can tell ctypes will only expose the pyObject type to me and
not actually let me deal with the data I am after, but being rather new
to ctypes I'm not sure weather this is correct.

--
Gord Allott (gordallott@gmail.com)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI7y2SlVw7T9GIvRsRArcbAKCjmewtdkEiahPXTHhhCU My9D7NEgCfYTIQ
dE7a69MTHmR/3WUUSCzoSmc=
=Outo
-----END PGP SIGNATURE-----

On Oct 10, 5:24*am, Gordon Allott <gordall...@gmail.comwrote:

Hello :)
>
The result of various incompatibilities has left me needing to somehow
extract the address that a null pointer is pointing to with the null
pointer being exposed to python via PyCObject_FromVoidPtr
>
the code that creates the PyCObject is as follows:
* * tmp = PyCObject_FromVoidPtr (info.info.x11.display, NULL);
* * PyDict_SetItemString (dict, "display", tmp);
* * Py_DECREF (tmp);
>

Did you try:

tmp= PyLong_FromLong( ( long ) info.info.x11.display );
PyDict_SetItemString (dict, "display", tmp);
Py_DECREF (tmp);

Or also try:

PyCObject_AsVoidPtr( tmp );

Aaron "Castironpi" Brady wrote:

Did you try:

tmp= PyLong_FromLong( ( long ) info.info.x11.display );
PyDict_SetItemString (dict, "display", tmp);
Py_DECREF (tmp);

Or also try:

PyCObject_AsVoidPtr( tmp );
--
http://mail.python.org/mailman/listinfo/python-list

the problem is that I can't edit the C code - well I can and might
submit a patch to the project but I also need a solution that works from
the python side of things.


--
Gord Allott (gordallott@gmail.com)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI74sQlVw7T9GIvRsRAtw+AJ4i0lte6DnzeJ6Nm+BbaY GUCDDEIQCeIW4m
rlzxbYBLYI4j3hFceifTuLM=
=nfIm
-----END PGP SIGNATURE-----

On Oct 10, 12:04*pm, Gordon Allott <gordall...@gmail.comwrote:

Aaron "Castironpi" Brady wrote:

>

>

>

>
the problem is that I can't edit the C code - well I can and might
submit a patch to the project but I also need a solution that works from
the python side of things.
>

I see. If I understand, you have a PyCObject in a dictionary.

Look at the 'ctypes' module and try calling PyCObject_AsVoidPtr. Its
return type should be 'c_void_p', and you can use 'result.value' to
get the original pointer.

Aaron "Castironpi" Brady wrote:

I see. If I understand, you have a PyCObject in a dictionary.

Look at the 'ctypes' module and try calling PyCObject_AsVoidPtr. Its
return type should be 'c_void_p', and you can use 'result.value' to
get the original pointer.
--
http://mail.python.org/mailman/listinfo/python-list

I have a hard time following that, if using ctypes you used PyDLL to
call PyCObject_AsVoidPtr on the PyCObject I already have surely it would
give me back a pointer (void for sake of simplicity) but it would be a
pointer to a new PyCObject and thus calling result.value on it would
only return the memory address of the new PyCObject?
--
Gord Allott (gordallott@gmail.com)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI78YSlVw7T9GIvRsRAm3eAJ0c9k7HFhXbEcq3O3jGYl MsziKIHACfS09u
5QTYKVR/SH6fPqToXhK9WVA=
=uL6v
-----END PGP SIGNATURE-----

On Oct 10, 4:16*pm, Gordon Allott <gordall...@gmail.comwrote:

Aaron "Castironpi" Brady wrote:

>

>
I have a hard time following that, if using ctypes you used PyDLL to
call PyCObject_AsVoidPtr on the PyCObject I already have surely it would
*give me back a pointer (void for sake of simplicity) but it would be a
pointer to a new PyCObject and thus calling result.value on it would
only return the memory address of the new PyCObject?
--
Gord Allott (gordall...@gmail.com)
>
*signature.asc
< 1KViewDownload

Yes, well said. But no, not true, not necessarily. You can choose/
change return types with your code. If the call is defined already
and you can't change the return, just define a new one that returns
long.

Aaron "Castironpi" Brady wrote:

Yes, well said. But no, not true, not necessarily. You can choose/
change return types with your code. If the call is defined already
and you can't change the return, just define a new one that returns
long.
--
http://mail.python.org/mailman/listinfo/python-list

the problem is that the pointer or long or whatever it is thats returned
won't be the data I am after. the code for PyCObject_FromVoidPtr is as
follows:

PyObject *
PyCObject_FromVoidPtr(void *cobj, void (*destr)(void *))
{
PyCObject *self;

self = PyObject_NEW(PyCObject, &PyCObject_Type);
if (self == NULL)
return NULL;
self->cobject=cobj;
self->destructor=destr;
self->desc=NULL;

return (PyObject *)self;
}


it obviously creates a new PyObject and returns that, which has already
happened once (the address I am after is passed to python via
PyCObject_FromVoidPtr(adress_i_am_after, NULL), doing that puts the
address I am after into the .cobject attribute of a new pyobject
structure and passes that to the python script via the 'display' key in
a dictionary.

If I were to then take the pycobject in this display key and pass it via
ctypes into PyCObject_FromVoidPtr it would simply create a new pycobject
and put a pointer to the old pycobject in the new pycobject's .cobject
attribute. it just means that I am getting further and further away from
where I want to be surely? if I were to take the current pointer at this
stage, to get to the address I actually want in C it would have to
follow something along the lines of
long address_i_want = (long)(new_pycobj->cobject->cobject);

What would be great is if there is some easy simple way of accessing the
.cobject attribute of the first pycobject thats passed via the
dictionary to python.

--
Gord Allott (gordallott@gmail.com)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI7/p9lVw7T9GIvRsRAr2rAJ9gxOUnLb8olXN6siH88ZLMwv2erwCf WD1q
+Y5jmOl0PrUzLTvmc3nMK/U=
=rL5l
-----END PGP SIGNATURE-----

On Oct 10, 7:59*pm, Gordon Allott <gordall...@gmail.comwrote:

Aaron "Castironpi" Brady wrote:

>
the problem is that the pointer or long or whatever it is thats returned
won't be the data I am after. the code for PyCObject_FromVoidPtr is as
follows:
>
PyObject *
PyCObject_FromVoidPtr(void *cobj, void (*destr)(void *))
{
* * PyCObject *self;
>
* * self = PyObject_NEW(PyCObject, &PyCObject_Type);
* * if (self == NULL)
* * * * return NULL;
* * self->cobject=cobj;
* * self->destructor=destr;
* * self->desc=NULL;
>
* * return (PyObject *)self;
>
}
>
it obviously creates a new PyObject and returns that, which has already
happened once (the address I am after is passed to python via
PyCObject_FromVoidPtr(adress_i_am_after, NULL), doing that puts the
address I am after into the .cobject attribute of a new pyobject
structure and passes that to the python script via the 'display' key in
a dictionary.
>
If I were to then take the pycobject in this display key and pass it via
ctypes into PyCObject_FromVoidPtr it would simply create a new pycobject
*and put a pointer to the old pycobject in the new pycobject's .cobject
attribute. it just means that I am getting further and further away from
where I want to be surely? if I were to take the current pointer at this
stage, to get to the address I actually want in C it would have to
follow something along the lines of
long address_i_want = (long)(new_pycobj->cobject->cobject);
>
What would be great is if there is some easy simple way of accessing the
.cobject attribute of the first pycobject thats passed via the
dictionary to python.
>
--
Gord Allott (gordall...@gmail.com)
>
*signature.asc
< 1KViewDownload

You are hard to follow. There is the 'cast' function, which I've had
some success with, even in adding pointers and offsets. It took a
look at the code for it though, and calling an undocumented version of
it. I can post that later if you don't have luck the same. You can
write extension modules to do that as well, and there's always a
Google search which personally I forget half the time too. Last, you
haven't mentioned an attempt with PyCObject_AsVoidPtr yet:

void* PyCObject_AsVoidPtr(PyObject* self)
Return the object void * that the PyCObject self was created with.

Where does that get you?

Aaron "Castironpi" Brady wrote:

You are hard to follow. There is the 'cast' function, which I've had
some success with, even in adding pointers and offsets. It took a
look at the code for it though, and calling an undocumented version of
it. I can post that later if you don't have luck the same. You can
write extension modules to do that as well, and there's always a
Google search which personally I forget half the time too. Last, you
haven't mentioned an attempt with PyCObject_AsVoidPtr yet:

void* PyCObject_AsVoidPtr(PyObject* self)
Return the object void * that the PyCObject self was created with.

Where does that get you?
--
http://mail.python.org/mailman/listinfo/python-list

sorry yes you were right, I was reading PyCObject_AsVoidPtr as
PyCObject_FromVoidPtr :)

using AsVoidPtr is a little confusing, this is the code I am using:
display = pygame.display.get_wm_info()['display']
pyobj = py_object(display)
ref = pointer(pyobj)

print pythonapi.PyCObject_AsVoidPtr(ref)

it produces the following traceback:
Traceback (most recent call last):
File "pygametest.py", line 125, in <module>
app = PyGameOGREApp()
File "pygametest.py", line 33, in __init__
self._createWindow(width, height, fullscreen)
File "pygametest.py", line 64, in _createWindow
print pythonapi.PyCObject_AsVoidPtr(ref)
TypeError: PyCObject_AsVoidPtr with non-C-object

- I think that's because its a pointer to the ctypes py_object() rather
than the PyCObject we are dealing with but I have no idea how to create
a pointer to that.

--
Gord Allott (gordallott@gmail.com)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI8CN1lVw7T9GIvRsRAuo0AKCSzSQgnnRPanYLStdBLG GIA669rQCeJsm7
G/Dnr2uDs8CaZJ988UnF2kU=
=/HxT
-----END PGP SIGNATURE-----

On Oct 10, 10:54*pm, Gordon Allott <gordall...@gmail.comwrote:

Aaron "Castironpi" Brady wrote:
snip

>

>

>
sorry yes you were right, I was reading PyCObject_AsVoidPtr as
PyCObject_FromVoidPtr :)
>
using AsVoidPtr is a little confusing, this is the code I am using:
* * * * display = pygame.display.get_wm_info()['display']
* * * * pyobj = py_object(display)
* * * * ref = pointer(pyobj)
>
* * * * print pythonapi.PyCObject_AsVoidPtr(ref)
>
it produces the following traceback:
Traceback (most recent call last):
* File "pygametest.py", line 125, in <module>
* * app = PyGameOGREApp()
* File "pygametest.py", line 33, in __init__
* * self._createWindow(width, height, fullscreen)
* File "pygametest.py", line 64, in _createWindow
* * print pythonapi.PyCObject_AsVoidPtr(ref)
TypeError: PyCObject_AsVoidPtr with non-C-object
>
- I think that's because its a pointer to the ctypes py_object() rather
than the PyCObject we are dealing with but I have no idea how to create
a pointer to that.
>

My pygame install just returns an integer in get_wm_info. Take a
look:

{'window': 1180066, 'hglrc': 0}

1180066

c_void_p(1180066)

You're suggesting yours looks like this:

{ ... 'display': ctypes.py_object( 1180066 ), ... }

What does type( display ) give you?

Aaron "Castironpi" Brady wrote:

My pygame install just returns an integer in get_wm_info. Take a
look:

{'window': 1180066, 'hglrc': 0}

1180066

c_void_p(1180066)

You're suggesting yours looks like this:

{ ... 'display': ctypes.py_object( 1180066 ), ... }

What does type( display ) give you?
--
http://mail.python.org/mailman/listinfo/python-list

yes its different on windows and linux, windows only has a few items
where linux has many more. 'window' is just the window 'id' at any rate
which is not the data I am after (which is internally an address to an
xlib structure)
this is what pygame.display.get_wm_info() returns on linux:
{'fswindow': 31457283, 'wmwindow': 31457284, 'window': 31457294,
'lock_func': <PyCObject object at 0x89dfa70>, 'unlock_func': <PyCObject
object at 0x89dfa88>, 'display': <PyCObject object at 0x89dfa58>}

note how the display object is a PyCObject, thats got the address I want
inside it.


--
Gord Allott (gordallott@gmail.com)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI8LwNlVw7T9GIvRsRAixJAJwIe97b5eJ3tUrfolqZ7D 15DCsV8ACgp4UL
idODQg3cBrUXy5BxEezExtM=
=Jvca
-----END PGP SIGNATURE-----

On Oct 11, 9:45*am, Gordon Allott <gordall...@gmail.comwrote:

Aaron "Castironpi" Brady wrote:
>

>

>

>

>

>
yes its different on windows and linux, windows only has a few items
where linux has many more. 'window' is just the window 'id' *at any rate
which is not the data I am after (which is internally an address to an
xlib structure)
this is what pygame.display.get_wm_info() returns on linux:
{'fswindow': 31457283, 'wmwindow': 31457284, 'window': 31457294,
'lock_func': <PyCObject object at 0x89dfa70>, 'unlock_func': <PyCObject
object at 0x89dfa88>, 'display': <PyCObject object at 0x89dfa58>}
>
note how the display object is a PyCObject, thats got the address I want
*inside it.
>

What does print pythonapi.PyCObject_AsVoidPtr(display) give you?

Aaron "Castironpi" Brady wrote:

What does print pythonapi.PyCObject_AsVoidPtr(display) give you?
--
http://mail.python.org/mailman/listinfo/python-list

Traceback (most recent call last):
File "pygametest.py", line 125, in <module>
app = PyGameOGREApp()
File "pygametest.py", line 33, in __init__
self._createWindow(width, height, fullscreen)
File "pygametest.py", line 65, in _createWindow
print pythonapi.PyCObject_AsVoidPtr(display)
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: Don't
know how to convert parameter 1


--
Gord Allott (gordallott@gmail.com)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI8PeLlVw7T9GIvRsRAhJyAJ9BtoEeYhpXOPe6jtcFYQ kfccdrTwCcCLbj
FIJ4SeuH1lwP+F5IV3JoV+A=
=uwxx
-----END PGP SIGNATURE-----

On Oct 11, 1:59*pm, Gordon Allott <gordall...@gmail.comwrote:

Aaron "Castironpi" Brady wrote:
>

>
Traceback (most recent call last):
* File "pygametest.py", line 125, in <module>
* * app = PyGameOGREApp()
* File "pygametest.py", line 33, in __init__
* * self._createWindow(width, height, fullscreen)
* File "pygametest.py", line 65, in _createWindow
* * print pythonapi.PyCObject_AsVoidPtr(display)
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: Don't
know how to convert parameter 1
>
--
Gord Allott (gordall...@gmail.com)
>
*signature.asc
< 1KViewDownload

If anyone knows this better, feel free to step in.

Put this before the call:

ctypes.pythonapi.PyCObject_AsVoidPtr.restype = ctypes.c_void_p
ctypes.pythonapi.PyCObject_AsVoidPtr.argtypes = [ ctypes.py_object ]

The reason is that this is the default signature, which is wrong:

<class 'ctypes.c_long'>

There are other ways to prototype it if you like, too.

Aaron "Castironpi" Brady wrote:

<class 'ctypes.c_long'>

thank you so much, this works perfectly :)


--
Gord Allott (gordallott@gmail.com)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI8QEJlVw7T9GIvRsRAuK2AJ9DmCWrRbpirVX3412i5q g6rQpOYQCfRDmw
eBbJD28vTEPZYch0jz2f8hM=
=yEi0
-----END PGP SIGNATURE-----