On 14 Mar, 02:08, Aaron Brady <castiro...@gmail.com> wrote: > On Mar 13, 5:42 pm, Matteo <tadweles...@gmail.com> wrote: > > > > > On 13 Mar, 22:35, Aaron Brady <castiro...@gmail.com> wrote: > > > > On Mar 13, 1:34 pm, Matteo <tadweles...@gmail.com> wrote: > > > > > hmmm... looks like SWIG has a problem with double pointers. I googled > > > > around a bit and found: > > > > >http://osdir.com/ml/programming.swig/2003-02/msg00029.html > > > > > anyone knows how to write a small wrapper to do the appropriate > > > > dereferencing? > > > > 'ctypes' may be able to do it. I've done something like this in the > > > past: > > > > double_ptr= ctypes._cast( PyObject, sing_ptr ) > > > > Up your alley? > > > Thanks for your suggestions, but still no luck here. > > > ctypes appears to work only with its own types, I tried its cast, > > byref and pointer functions, but only received TypeError exceptions > > such as: > > TypeError: byref() argument must be a ctypes instance, not 'list' > > TypeError: _type_ must have storage info > > > This is getting really annoying :( > > > The following link may contain useful info, but I find it somewhat > > obscurehttp://embedded.eecs.berkeley.edu/Alumni/pinhong/scriptEDA/pyTypemapF... > > I'm on my last one (suggestion). To get a pointer to the actual > address of an mmap instance, (and access it's 'data' attribute), I > used the following: > > from _ctypes import _cast_addr > from ctypes import * > _mmap_cast= _data_cast= PYFUNCTYPE(py_object, py_object, py_object, > py_object)(_cast_addr) > _offset_cast= _record_cast = PYFUNCTYPE(py_object, c_void_p, > py_object, py_object)(_cast_addr) > > class MMAP(Structure): > _fields_= [ > #("next",c_int), > #("prev",c_int), > ("refcnt",c_int), > ("type",c_int), > ("data",c_long) > ] > > def pdata( map ): > a= _data_cast( map, None, POINTER( MMAP ) ) > return a.contents.data > > It worked on my machine in 2.5, no promises. It was a workaround for > the '_type_ must have storage info' error. Lo and behold, > 'a.contents' was an MMAP, so '.data' was a 'c_long' interpretation of > the 'char* data' member of the C structure, PyMmapObject or > something. I found it by studying the 'ctypes.cast' code. Well good > luck and sorry for the suggestions.
Umph... couldn't get this to work either. I'm starting a new thread, reproducing the problem with the minimum amount of c++ and python code, now that I know where the problem lies. Again, thanks for your time. -- http://mail.python.org/mailman/listinfo/python-list
