discuss-gnuradio
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]