[Discuss-gnuradio] remark on custom block + python behavior on Beagleboard
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. thanks. al ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] remark on custom block + python behavior on Beagleboard
On 10/25/2010 11:38 AM, Almohanad Fayez wrote: 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. Python is supposed to delete those .pyc and .pyo files whenever you ask it to run a matching .py file, _if_ the .py file is younger. Otherwise, it assumes you haven't changed the .py file, and saves a bit of time by jumping straight to the compiled files. One time where I've seen similar behaviour is when the .py is a symlink (link.py - real.py, say). Opening and modifying link.py changes the modification time of real.py, but not link.py, so if you ask python to compile link.py, it still looks older than link.pyc that it created before you modified anything. It's possible there are other situations where this would happen, that's just the one time that I remember it happening to me. -- Patrick Yeon ThinkRF 613-369-5104 x418 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] remark on custom block + python behavior on Beagleboard
On Mon, Oct 25, 2010 at 11:38:00AM -0400, Almohanad Fayez wrote: 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. thanks. al Is there any chance that sometime you run the code as root, and sometimes as a non-root user? If so, depending on the details of your installation, you may have a situation where the non-root user cannot remove the old and out of date *.pyo and *.pyc files. I've never seen the problem you describe, thus I suspect that it may have to do with permissions on the files and/or directories involved. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
