Re: [Discuss-gnuradio] No module named wx - another data point

[Robert W McGwier]

I am past the wx module.  It was just as suggested, I had python2.4 
first in line,
wxpython was made for python2.3 (what a dummy) and it could not find it.
Fixed here.

Now I am onto usrp stuff, trying to get the burn-basic-eeprom to run.

I got the following error message and follow on listings that might be of
interest:

macdel:/usr/local/src/gr-build/usrp/host/apps # ./burn-basic-eeprom
Traceback (most recent call last):
 File "./burn-basic-eeprom", line 23, in ?
   from usrp_prims import *
ImportError: No module named usrp_prims
macdel:/usr/local/src/gr-build/usrp/host/apps # cd 
/usr/local/lib/python2.3/site-packages
macdel:/usr/local/lib/python2.3/site-packages # ls
.   __init__.py   __init__.pyo   _usrp_prims.la  gnuradio       
usrp_prims.pyc
..  __init__.pyc  _usrp_prims.a  _usrp_prims.so  usrp_prims.py  
usrp_prims.pyo


Since they are there,  I  realized that the PYTHONHOME and PYTHONPATH 
prefixes
are both pointing to /usr/lib and not /usr/local/lib.  This was easily 
remedied by re-doing
the install directory for gnuradio python packages to the correct place 
for the site-packages

/usr/lib

macdel:/usr/local/lib/python2.3/site-packages #/usr/bin/env python
Python 2.3.4 (#1, Feb  7 2005, 15:50:45)
[GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> from usrp_prims import *
>>>

and it succeeded.

Then I proceeded to attempt to burn the RX and TX boards eeproms
again for the several-th time.
macdel:/usr/local/src/gr-build/usrp/host/apps # ./burn-basic-eeprom
You must specify at least one slot or use the -a option
usage: burn-basic-eeprom [options] (tx_a|rx_a|tx_b|rx_b)*

options:
 -h, --help   show this help message and exit
 -a, --all    initialize all d'board eeproms
 -f, --force  force init of already initialized eeproms
macdel:/usr/local/src/gr-build/usrp/host/apps # ./burn-basic-eeprom -a
Can't find fpga bitstream: usrp_fpga.rbf
Traceback (most recent call last):
 File "./burn-basic-eeprom", line 118, in ?
   ok = main (which, options.force)
 File "./burn-basic-eeprom", line 84, in main
   u = open_cmd_interface (0)
 File "./burn-basic-eeprom", line 40, in open_cmd_interface
   raise RuntimeError, "usrp_load_standard_bits"
RuntimeError: usrp_load_standard_bits

And I cannot find these bits at home, here, etc.

Bob



LRK wrote:

> On Fri, Apr 15, 2005 at 01:44:52PM -0700, Eric Blossom wrote:
>  
>
> > On Fri, Apr 15, 2005 at 02:33:38PM -0500, LRK wrote:
> >    
> >
> > > Probably a clue here somewhere.
> > >
> > > 'import wx'  fails but  'import wxversion'  works
> > >
> > > Then I can select the version and get a different error:
> > >
> > >      
> > OK.  Does the version of python that the wxPython binary was built
> > against match the version of python that you're using?  The python API
> > changes and extensions built against one version don't necessarily run
> > with another version.  I'm not sure how to check this.  On an RPM
> > based system they have different names.  E.g.,
> >
> >  wxPython2.5-gtk2-ansi-2.5.5.1-mdk101_py2.3.i586.rpm
> >
> >                        vs.
> >
> >  wxPython2.5-gtk2-ansi-2.5.5.1-mdk101_py2.4.i586.rpm
> >
> > Kind of a gnarly naming convention.
> >
> > I ran into a similar problem myself in some of my code.  My import was
> > failing, and no error was indicated. Turned out that a shared library
> > required for the import to succeed was bad or missing.  Maybe there's
> > a way to get python to increase the diagnostics during import.  I don't know.
> >    
>
> 'find' does not locate anything that looks like wxPython2.x or wx-2.x other
> than the 2.5 versions.
>
> I am building python from source code on this machine using a standard port 
> to FreeBSD installed by root.
>
> I am building wxPython as user gr.
>
>
> The user site-packages directory has these wx* files:
>
> drwxr-xr-x  4 gr  gr    512 Apr 11 23:42 wx-2.5.5-gtk2-ansi
> -rw-r--r--  1 gr  gr     19 Apr 15 14:06 wx.pth
> -rw-r--r--  1 gr  gr  14432 Apr 15 14:05 wxversion.py
> -rw-r--r--  1 gr  gr  11978 Apr 15 14:13 wxversion.pyc
>
> And wx.pth contains:
>
> wx-2.5.5-gtk2-ansi
>
>
> Python seems to ignore the *.pth files in this directory but will read
> the ones under /usr/local/lib/python2.4/site-packages, the default
> directory. The .pth files there need the full pathname for modules in
> the user site-packages directory. That still looks like the best fix for
> the moment.
>
>
> 'import wxversion' and select obviously adds the path for wx to the sys.path
> file.
>
>
> Still looking....
>
>
>