What I've *done* in the past, but I can't remember how pretty that was:
GDB has python integration (essentially, a large gdb script + python debug
infos). If you
can break at a C++ function that your python work() calls, you should be able
to e.g.
py-bt into the mother frames etc.
Cheers,
Marcu
Yah, there might be some kind of hack, but you're right ... since a Python
block is being exec'd via a C++-to-Python gateway it's in a no man's land
from the debugger perspective.
On Sun, Jan 17, 2021 at 4:46 PM Nicholas Long
wrote:
> So I get the fact that GNURadio is highly parallel, that is f
So I get the fact that GNURadio is highly parallel, that is fine. I debug
C++ OOT blocks all the time and it is super easy, generally I make specific
effort to isolate the OOT block that I am currently working on in a test
flowgraph.
For C++ OOT blocks I just run the python top_block.py in gdb (vi
Python includes a debugger (pdb) and IDEs like VSCode have decent Python
debugging. This should work fine for Python scripts like those generated by
GRC. Internally, GNU Radio is highly parallel, which creates additional
challenges not related to language ... how do you stop one block when that
cha
So this is a relatively generic question about what people's processes for
writing and debugging python blocks are.
In C++ I use VScode and just run the gdb debugger - I can place
breakpoints, look at variables, and step through the program super easily.
Ideally I would like to be able to do the
