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, Marcus On 17.01.21 22:52, Jeff Long wrote: > 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 <nicholaslon...@gmail.com > <mailto:nicholaslon...@gmail.com>> wrote: > > 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 (via > vscode), and place a > breakpoint in my C++ OOT block, and it works. > > If I want to debug the python flowgraph, (generated from GRC or custom), > I can do that > via the python debug tool, I cannot step through the internals of blocks, > but can see > if things are hooking up correctly. > > my problem, (and I personally don't think that there is a solution, but > am happy to be > wrong) is that there is no way to place a breakpoint inside a python > block, like I do > in the c++ blocks. presumably the swig (I'm still on 3.8) process removes > all the > information?. > > As for specific use cases, the more complex blocks I write are all C++, > but sometimes > it is useful to write a quick and dirty python block which I can then use > for > debugging purposes. However when I do this I have to resort to using > print statements > to make sure everything is working like I expect. It's ok and workable, > but I am not > that good of a programmer and tend to do guess and check, which a > debugger, rather > than adding/removing print statements really speeds up. > > So I guess there is nothing in particular to debug, but If there is a > more efficient > way to work I would love to know. > > Nick > > On Sat, Jan 16, 2021 PM Jeff Long wrote: > > 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 changes > the behavior > of, or crashes, the whole framework? > > Anything in particular you are trying to debug? > > On Sat, Jan 16, 2021 at 6:51 PM Nicholas Long > <nicholaslon...@gmail.com > <mailto:nicholaslon...@gmail.com>> wrote: > > 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 same with python > blocks, but am not > sure if it is possible. > > Thanks, > Nick >