On Mon, Dec 04, 2006 at 04:51:30PM +0800, Jeremy Chew wrote:
Hi,
I'm using an older version as this is what that came when I downloaded GR
a
few months ago and I haven't seen a need to change what I have installed.
I'm new to GR, Linux and Python so I'm more eager to debug what I have
without introducing even newer stuff.
Anyway, the earlier problem was due to a C++ bug affecting another
thread.
This has been fixed. Now there's a problem with passing the packets
created
in the C++ extension, called sm, to Python.
The following describes what I do, which is setting the callback, and
then
calling the callback.
SETTING THE CALLBACK POINTER IN THE C++ EXTENSION
The Python call that is to receive the packet from the C++ extension is
inherited from null_mac class and is named self.fg.send_pkt(). It is
passed
from a sub-class of null_mac in Python to the extension with:
sm.settx2llecallback(self.fg.send_pkt)
The corresponding C++ call is:
static PyObject*s_pcTxDnCallback=0;
...
static PyObject*sm_settx2llecallback(PyObject*a_pcSelf,PyObject*a_pcArgs)
{...
PyObject*l_pcCallback=0;
...
if(PyArg_ParseTuple(a_pcArgs,"O:set_callback",&l_pcCallback))
{
if(PyCallable_Check(l_pcCallback))
{...
Py_XINCREF(l_pcCallback);
s_pcTxDnCallback=l_pcCallback;
...
}
When the above executes, PyCallable_Check() seems to run with no error.
OK.
PASSING PACKETS FROM THE EXTENSION TO PYTHON CODE
Later, a packet is created in the C++ extension in the form of an
unsigned
char array. To pass it to the Python IP tunneling code, I do the
following:
BOOL Tx2PyLle(unsigned char*data,UINT16 len)
{
...
PyObject*l_pcArgs=0;
...
l_pcArgs=Py_BuildValue("(s#)",reinterpret_cast<char*>(data),static_cast<INT32>(len));
if(l_pcArgs )
{...
assert(s_pcTxDnCallback);
...;
PyObject*l_pcRet=PyEval_CallObject(s_pcTxDnCallback,l_pcArgs);
...
}
This function above has a segmentation fault at PyEval_CallObject().
My queries are:
1) Is the callback to Python passed and set correctly in the extension?
Beat me. I let SWIG handle all this stuff for me.
FWIW, the latest GNU Radio code uses SWIG directors to enable C++ code
to call back into Python. It works fine as long as you are using SWIG
1.3.31.
2) Is it right to assume that in Python, the packets are Python strings?
The message payloads are strings. The gr.messages are wrapped C++
objects (not strings). I'm not sure which type you are trying to pass
to/from C++.
Eric