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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
