Hi, sent an email a while back about what I thought was a scheduler issue with
gnuradio on the beagleboard. Basically I've been writing custom GNU Radio
block for the OMAP's DSP and running them on the beagleboard. On occassions
when I'm running multiple blocks, GNU Radio would parse my flowgraph but then
get lost and never starts the flowgraph. I've always thought it was an issue
with my code but it turned out to be a python issue and I'm not sure if it's
specific to my platform or python in general.
python basically generates optimizied pre-interpred python files *.pyo and *.pyc. and as it happens, some
of these files are not refreshed when I make changes to my python source file I managed to debug the issue
where at the point where gnuradio calls the c++ file that handles the swig call handling
"gnuradio_swig_py_runtime.cc". This file is able to detect the python block so the
"custom_blocks.cc" file generated by the howto-write-a-custom-block auto tools. then there is a
call placed to the constructor "gr_basic_block.cc" and that's where gnuradio gets lost into
oblivion.
I was able to finally fix this problem by writing a script that deletes all of
the pyc and pyo files associated with my library and flowgraph. my question
is, is this a know python issue, an issue with the custom gnuradio block, or an
issue with the platform? I managed to recreate this problem using the custom
block 3.2.1 and 3.2.2 templates and I was also able to recreate it by using the
original how to square a number example.