Adding Accessor Methods in GR 3.7

I’ve recently converted to GR 3.7, and am currently on 3.7.3.

I have created and run a new block in C++, but now want to add
an accessor method to the block’s class. I defined it in
<new_class_name>_impl.h , in the public part of the
class declaration as follows:

   float get_samples_per_second(void)
     {
       return d_samples_per_second;
     }

This compiles fine, but when I try to access it from
GRC via a function probe, I get:

AttributeError: ‘acq_test_1_cc_sptr’ object has no attribute
‘get_samples_per_second’

Is there some additional 3.7 swig magic I have to go through
to make this accessor available from python?

@(^.^)@ Ed

On 06/06/2014 07:44 PM, Ed Criscuolo wrote:

I’ve recently converted to GR 3.7, and am currently on 3.7.3.

Welcome :slight_smile:

This compiles fine, but when I try to access it from
GRC via a function probe, I get:

AttributeError: ‘acq_test_1_cc_sptr’ object has no attribute
‘get_samples_per_second’

Is there some additional 3.7 swig magic I have to go through
to make this accessor available from python?

You also need to add the accessor in the include/*.h file as a virtual
member function.

M

On 6/6/14 1:50 PM, Martin B. wrote:

You also need to add the accessor in the include/*.h file as a virtual
member function.

Thanks Martin. That did it, although I had to rerun cmake to get it
to propagate into the swig files.

@(^.^)@ Ed

On Fri, Jun 6, 2014 at 3:02 PM, Ed Criscuolo
[email protected]
wrote:

to propagate into the swig files.
Prior to this change, I had been moving this OOT module
back and forth successfully between the two systems.

@(+.+)@ Ed

Can you post more of the output so we can see where this is being
generated
(maybe post the build log to pastebin or something)? Off the top of my
head, that doesn’t look familiar.

Tom

On 6/6/14 2:30 PM, Ed Criscuolo wrote:

On 6/6/14 1:50 PM, Martin B. wrote:

You also need to add the accessor in the include/*.h file as a virtual
member function.

Thanks Martin. That did it, although I had to rerun cmake to get it
to propagate into the swig files.

Guess I spoke too soon. :frowning: Although it worked fine on my OSX platform,
as soon as I moved it to an Ubuntu 12.04LTS platform and tried to
build it in a fresh build directory, the cmake ran ok but the make
failed somewhere in the swig stuff, on a cryptically named xml file
“_8__acq__test__1__cc_8h.xml” with the error

" ‘NoneType’ object has no attribute ‘compounddef’ "

Prior to this change, I had been moving this OOT module
back and forth successfully between the two systems.

@(+.+)@ Ed

On Fri, Jun 6, 2014 at 3:37 PM, Ed Criscuolo
[email protected]
wrote:

        You also need to add the accessor in the include/*.h file as

platform,
@(+.+)@ Ed

[ 21%] Built target test-tdrss
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/swig_doc.py”, line
self._parse()
line 203, in check_parsed
self._parse()
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/doxyindex.py”,
line 163, in _parse
self.set_descriptions(self._retrieved_data.compounddef)
AttributeError: ‘NoneType’ object has no attribute ‘compounddef’
make[2]: *** [swig/tdrss_swig_doc.i] Error 1
make[1]: *** [swig/CMakeFiles/_tdrss_swig.dir/all] Error 2
make: *** [all] Error 2
[email protected]:~/Gnu-Radio/gr-tdrss/build$

Ok, looks like your swig files weren’t updated correctly. I’m not sure
here
what the exact reason is. When you were converting over to the new 3.7
api,
did you use gr_modtool to create the project space or did you start with
your current one and modify it? If the former, we’ll have to take a
closer
look. If the latter, I’d suggest looking at the swig/tdrss_swig.i and
swig/CMakeLists.txt files to see that they were updated correctly.

My guess with why it worked on OSX is that you don’t have doxygen on
your
OS X box. If you do -DENABLE_DOXYGEN=False, that might get passed this
immediate issue.

Tom

On 6/6/14 3:20 PM, Tom R. wrote:

        member function.
"_8__acq__test__1__cc_8h.xml"  with the error

Can you post more of the output so we can see where this is being
generated (maybe post the build log to pastebin or something)? Off the
top of my head, that doesn’t look familiar.

Tom

It’s not real long, so I’ll post it here

================================================
[email protected]:~/Gnu-Radio/gr-tdrss/build$ make
Scanning dependencies of target gnuradio-tdrss
[ 5%] Building CXX object
lib/CMakeFiles/gnuradio-tdrss.dir/acq_test_1_cc_impl.cc.o
Linking CXX shared library libgnuradio-tdrss.so
[ 10%] Built target gnuradio-tdrss
Linking CXX executable test-tdrss
[ 21%] Built target test-tdrss
[ 26%] Built target _tdrss_swig_swig_tag
[ 31%] Built target _tdrss_swig_doc_tag
[ 36%] Generating tdrss_swig_doc.i
Error in xml in file
/home/edwardc/Gnu-Radio/gr-tdrss/build/swig/tdrss_swig_doc_swig_docs/xml/_8__acq__test__1__cc_8h.xml
Traceback (most recent call last):
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/swig_doc.py”,
line 255, in
make_swig_interface_file(di, swigdocfilename,
custom_output=custom_output)
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/swig_doc.py”,
line 198, in make_swig_interface_file
blocks = di.in_category(Block)
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py”,
line 140, in in_category
self.confirm_no_error()
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py”,
line 206, in confirm_no_error
self.check_parsed()
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py”,
line 203, in check_parsed
self._parse()
File
“/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/doxyindex.py”,
line 51, in _parse
self._members += converted.members()
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py”,
line 174, in members
self.confirm_no_error()
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py”,
line 206, in confirm_no_error
self.check_parsed()
File “/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py”,
line 203, in check_parsed
self._parse()
File
“/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/doxyindex.py”,
line 163, in _parse
self.set_descriptions(self._retrieved_data.compounddef)
AttributeError: ‘NoneType’ object has no attribute ‘compounddef’
make[2]: *** [swig/tdrss_swig_doc.i] Error 1
make[1]: *** [swig/CMakeFiles/_tdrss_swig.dir/all] Error 2
make: *** [all] Error 2
[email protected]:~/Gnu-Radio/gr-tdrss/build$

================================================

On 6/6/14 3:50 PM, Tom R. wrote:

    the make


[ 21%] Built target test-tdrss
custom_output=custom_output)
line 206, in confirm_no_error
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/doxyxml/__base.py",
   File

Ok, looks like your swig files weren’t updated correctly. I’m not sure
here what the exact reason is. When you were converting over to the new
3.7 api, did you use gr_modtool to create the project space or did you
start with your current one and modify it? If the former, we’ll have to
take a closer look. If the latter, I’d suggest looking at the
swig/tdrss_swig.i and swig/CMakeLists.txt files to see that they were
updated correctly.

Nope, I started fresh with gr_modtool for that very reason.
And when I moved the OOT module to the Ubuntu box, I deleted the build
directory, recreated it empty, and ran cmake …/ from within it.

My guess with why it worked on OSX is that you don’t have doxygen on
your OS X box. If you do -DENABLE_DOXYGEN=False, that might get passed
this immediate issue.

Nope, I have Doxygen 1.8.5_3 installed on the Mac. But I’ll try
disabling Doxygen on the Ubuntu box and see if it gets me past
this point.

@(^.^)@ Ed

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs