[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] remark on custom block + python behavior on Beagl
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] remark on custom block + python behavior on Beagleboard |
Date: |
Mon, 25 Oct 2010 16:50:51 -0700 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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