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

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.

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.

--
Glynn Clements <glynn@gclements.plus.com>

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@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.