|
From: | Jacqueline . Walker |
Subject: | Re: [Discuss-gnuradio] Module attribute error in C++ guided tutorial - solved for now! |
Date: | Fri, 27 Jan 2017 14:34:09 +0000 |
Update to the issue. Trying to solve the module attribute not found error, experienced doing guided tutorial 4 viz: Traceback (most recent call last): File "tutorial_four_1.py", line 210, in <module> main() File "tutorial_four_1.py", line 198, in main tb = top_block_cls() File "tutorial_four_1.py", line 68, in __init__ self.tutorial_my_qpsk_demod_cb_0 = tutorial.my_qpsk_demod_cb(True) AttributeError: 'module' object has no attribute 'my_qpsk_demod_cb' Following this up the initial cause of the error does seem to be a path problem. Details: The import tutorial at the top of tutorial_four_1.py wasn’t allowing it to find “__init__.py “
and once this was corrected by adding an explicit path to the file it proceeded to generate another error because it couldn’t find the ‘pure python’ modules (which were in the same directory it is). If this means I shouldn’t be doing the tutorials one after
the other in the same directory structure please let me know. Anyway fixing this error with more brute force path direction in init.py changes the error to one from tutorial_swig.py: Traceback (most recent call last): File “tutorial_four_1.py”, line 34 in <module> Tutorial = impl.load_source(“tutorial”,”/home/Jacqueline/gnuradio/tutorials/work/gr-tutorial/python/__init__.py”) File ”/home/Jacqueline/gnuradio/tutorials/work/gr-tutorial/python/__init__.py”, line 33 in <module> from tutorial_swig import * File ”,”/home/Jacqueline/gnuradio/tutorials/work/gr-tutorial/build/swig/tutorial_swig.py”, line 477 in <module> my_qpsk_demod_cb = my_qpsk_demod_cb.make; AttributeError: ‘function’ object has no attribute ‘make’ And this proves to be because the tutorial_swig.py has the following lines repeated twice at the end of the file hence causing the error – but presumably not causing the original error obviously. Once that is corrected it all works! my_qpsk_demod_cb_sptr.__repr__ = lambda self:”<gr_block %s (%d)>” % (sefl.name(),self.unique_id()) my_qpsk_demod_cb = My_qpsk_demod_cb.make; Any comments would be welcome. Presumably those two lines are not supposed to be repeated – this is an automatically generated file. The directory structure is as follows: /home/username/gnuradio/tutorials/work/ contains the tutorial python files. Following the instructions in tutorial 3 gr_modtool created the gr-tutorial directory with sub-directories including python which is
where init.py is located and build which is where all the other stuff is located (in swig, python etc. sub-directories) as per tutorial 4. So what is going wrong? Is this path structure wrong? Thanks, Regards Jacqueline From:
Discuss-gnuradio [mailto:discuss-gnuradio-bounces+address@hidden]
On Behalf Of Jacqueline.Walker Hi Marcus, Thanks for the detailed instructions (and don’t worry I understood the SWIG comment ;-) ) I did as you suggested and the Boost warning DID disappear – and it was only necessary to put the new FindBoost.cmake file in the gr-tutorial/cmake/Modules directory.
However, unfortunately that didn’t – so far – stop the Attribute Error. Maybe I should scrap tutorial 4 and rebuild the flowgraph from scratch, as I first of all actually opened the grc with it already loaded
(that was unfortunate and just because that was how I closed it on Friday actually) and got some library/program conflict messages, please see in attached ‘output run grc’ file, but I suppose that’s just due to the Boost changes? Then I did replace the module in the flowgraph but still get the Attribute error when I try to run it. I am using QT gui – I don’t understand why it is mentioning ‘wx-python’ in the warnings but that may not
be an/the issue ? I will be grateful for any suggestions although I may not be able to try any of them out until Wednesday. Regards Jacqueline From:
Discuss-gnuradio [mailto:discuss-gnuradio-bounces+address@hidden]
On Behalf Of Marcus Müller Hi Jacqueline, first of all: thanks for the excellent report! It's rare that we get such well-defined and -researched problem descriptions. So, regarding SWIG, I guess "everyone" is about as smart as you are. I don't get that warning, though I'm using the same version of SWIG as you are – also, the same version of GCC. What differs between our systems (mine is a fedora 25) is that you're using
a more recent Boost version – as we see from the errors, somethings amiss with that.
Now, Boost has a history of not having good autoconf and CMake scripts, and that could be exactly what's hurting us here – the FindBoost in my /usr/share/cmake/Modules has exactly the warning displayed at exactly the code line (744), but it also as a terrible
long list of elseifs() before that simple ends for 1.62 – it seems that at least for my CMake Version, no one had the time to fix Boost detection. Luckily, that seems fixed upstream [1]! Can you do two things: 1. go into your /usr/share/cmake-3.7/Modules/FindBoost.cmake , line 744, and verify the last elseif is "NOT Boost_VERSION VERSION_LESS 106100 AND Boost_VERSION VERSION_LESS 106200" ¹ 2. if 1. is the case, go to [1], replace (maybe backup) your FindBoost.cmake with that (maybe putting it in your gr-tutorial/cmake/Modules directory suffices, here, but I'm not sure in which order cmake goes through the different directories) , empty your
build dir (really, rm -rf gr-tutorial/build/*) and do things again. Does the Boost warning disappear? If it does, would be a nice time to let the upstream maintainer of Arch's Boost or Arch's cmake package know that this file needs updatin'.
3. Try again with tutorial 4. Best regards, Marcus [1]
https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L745
On 01/20/2017 04:37 PM, Jacqueline.Walker wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |