[GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]

Andrew MacIntyre Andrew.MacIntyre at acma.gov.au
Mon May 10 21:33:17 EDT 2010


> From: Glynn Clements
> 
> Andrew MacIntyre wrote:
> 
> > > > In the case where SWIG is using its own objects to contain
returned
> > > > pointers, then I expect pyobj_to_ptr() needs to be changed to
use
> > > > SWIG_ConvertPtr() rather than PyCObject_AsVoidPtr() to retrieve
the
> > > > actual pointer, or the output typemaps for returned pointers
need to be
> > > > changed to use Python's CObjects rather than native SWIG wrapper
> > > > objects.
> > >
> > > So, what do you suggest? Remove the PyCObject_Check() call,
explicitly
> > > check for string, read buffer, write buffer, and sequence, then
call
> > > SWIG_ConvertPtr() on anything which is left over?
> >
> > That's what I would try.
> 
> Except ... SWIG_ConvertPtr() seems to require that you have access to
> the type descriptor. The documentation seems to suggest (although, as
> usual, it's unclear) that you need to know the actual type.

From the SWIG examples I inferred the following type references for 
the pointers in question:

CELL*  =>  SWIGTYPE_p_CELL
FCELL*  =>  SWIGTYPE_p_FCELL
DCELL*  =>  SWIGTYPE_p_DCELL

provided that CELL*/FCELL*/DCELL* are typedef'ed.

So I expected that in pyobj_to_ptr() you could do something like

	int rc;
	void *ptr;
	...
	switch (type_parm) {
		case CELL_PTR:
			rc = SWIG_ConvertPtr(PyObj, &ptr,
SWIGTYPE_p_CELL, SWIG_POINTER_EXCEPTION);
			break;
		case FCELL_PTR:
			rc = SWIG_ConvertPtr(PyObj, &ptr,
SWIGTYPE_p_FCELL, SWIG_POINTER_EXCEPTION);
			break;
		case DCELL_PTR:
			rc = SWIG_ConvertPtr(PyObj, &ptr,
SWIGTYPE_p_DCELL, SWIG_POINTER_EXCEPTION);
			break;
	}
	if (rc == -1)
		return NULL;
	...

"type_parm" is the type code parameter passed in to pyobj_to_ptr() - I
don't 
have a link to the swig file to check the actual parameter name.

> > I don't think you need to get rid of the typemap - I suspect you
might
> > have to expand it to distinguish between the different types of
pointers
> > though (see below)...
> 
> > I get the impression from the above linked documentation that, for
> > example, there should be an explicit typemap reference for CELL
pointers
> > (as returned by Rast_allocate_c_buf()) and that the typemap for CELL
> > pointers as an input argument should use SWIG_ConvertPtr(), which
will
> > set an exception if the inbound object is not a suitable input
> 
> GRASS uses "void *" to refer to any of CELL*/FCELL*/DCELL* quite
> extensively.
> 
> I think that I'm not going to put any more effort into the SWIG
> wrapper unless usable documentation materialises. In the meantime, I'm
> going to look for alternatives.

If you decide to investigate using ctypes, the following links might be
of interest:

- http://starship.python.net/crew/theller/ctypes/old/codegen.html

- http://www.language-binding.net/pygccxml/pygccxml.html

The latter seems more focussed on C++.  I haven't used either so can't
give 
any guidance.

Cheers,
Andrew.

-------------------------> "These thoughts are mine alone!" <---------
Andrew MacIntyre           Operations Branch
tel:   +61 2 6219 5356     Communications Infrastructure Division
fax:   +61 2 6253 3277     Australian Communications & Media Authority
email: andrew.macintyre at acma.gov.au            http://www.acma.gov.au/


If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents.
 
Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.


More information about the grass-user mailing list