Hi!
I’m writing a signal processing block with gr-modtool. I’ve successfully
make. When I try ctest -V, I get the “No constructor defined” error. The
swig interface file which gr_modtool generates is like:
/* -- c++ -- */
#define myblock_API
%include “gnuradio.i” // the common stuff
//load generated python docstrings
%include “myblock_swig_doc.i”
%{
#include “myblock/myclass.h”
%}
%include “myblock/myclass.h”
GR_SWIG_BLOCK_MAGIC2(myblock, myclass);
I’ve seen some threads that said swapping the last two lines would help,
but in my case it didn’t. I’m using the latest version of gr-modtool(it
generates xx_impl.cc,xx_impl.h and xx.h), and my gnuradio version is
3.6.0.
Could anybody kindly help?
Update:
I’ve tried with the simplest gr-howto block, it failed too. So I guess
this error is not due to my c++ code?
ERROR: test_001_t (main.qa_square_ff)
2:
2: Traceback (most recent call last):
2: File “/home/gnu/gr-howto/python/qa_square_ff.py”, line 37, in
test_001_t
2: sqr = howto.square_ff()
2: File “/home/gnu/gr-howto/build/swig/howto_swig.py”, line 161, in
init
2: def init(self, *args, **kwargs): raise AttributeError(“No
constructor defined”)
2: AttributeError: No constructor defined
Regards and thanks,
Fei
On Wed, Apr 10, 2013 at 11:10 PM, LianFeier [email protected] wrote:
//load generated python docstrings
I’ve seen some threads that said swapping the last two lines would help, but in
my case it didn’t. I’m using the latest version of gr-modtool(it generates
xx_impl.cc,xx_impl.h and xx.h), and my gnuradio version is 3.6.0.
No, you should be fine with the above setup. We fixed that issue a while
ago.
Could anybody kindly help?
I’m not sure. This usually happens when swig isn’t run correctly or
installed correctly (are you testing this just with QA code or after
installing it?).
Can you write down what steps you took when building your code?
Tom
On Fri, Apr 12, 2013 at 10:40 PM, LianFeier [email protected] wrote:
I’m writing a signal processing block with gr-modtool. I’ve successfully
make. When I try ctest -V, I get the “No constructor defined” error. The swig
interface file which gr_modtool generates is like:
%{
mkdir build
cd build
cmake …/
make
make test
I only edited the xx_impl.cc, xx_impl.h, xx.h ,qa_xx.py and the .i files among
the whole bunch of files generated by gr_modtool. Is that all I should do?
Yep, that’s what you should be doing. What version of the code base
are you working with? Is it a release version or from git? If using
git, are you using the very latest?
I can now actually piggyback my codes into gnuradio-core and rebuild gnuradio to
use gr.myclass in python, but that seems to be very tedious. Not sure whether this
information helps.
Thanks,
Fei
No, that’s not what you want to be doing. One of the whole points of
this project is to allow you to write your own out-of-tree modules to
keep things simpler and more organized for your projects.
Tom
Subject: Re: [Discuss-gnuradio] New dsp block: no constructor defined
#define myblock_API
installed correctly (are you testing this just with QA code or after
make test
Fei
No, that’s not what you want to be doing. One of the whole points of
this project is to allow you to write your own out-of-tree modules to
keep things simpler and more organized for your projects.
Tom
My code base is a release version from
Index of /releases/gnuradio/ . I use gnuradio-3.6.0.tar.gz.
My gr-modtool is from GitHub - mbr0wn/gr-modtool: Keeping this repo, for now, for archeaological purposes..
Thanks,
Fei
#include “myblock/myclass.h”
Could anybody kindly help?
I’m not sure. This usually happens when swig isn’t run correctly or
installed correctly (are you testing this just with QA code or after
installing it?).
Can you write down what steps you took when building your code?
Tom
Hi Tom,
Thanks for your reply!
I haven’t installed it yet, i am testing it with the QA code.
What I did after editing the files generated by gr-modtool is:
In the directory of my block:
mkdir build
cd build
cmake …/
make
make test
I only edited the xx_impl.cc, xx_impl.h, xx.h ,qa_xx.py and the .i files
among the whole bunch of files generated by gr_modtool. Is that all I
should do?
I can now actually piggyback my codes into gnuradio-core and rebuild
gnuradio to use gr.myclass in python, but that seems to be very tedious.
Not sure whether this information helps.
Thanks,
Fei
On Mon, Apr 15, 2013 at 3:02 PM, LianFeier [email protected] wrote:
successfully make. When I try ctest -V, I get the “No constructor defined”
gr-modtool(it generates xx_impl.cc,xx_impl.h and xx.h), and my gnuradio
I only edited the xx_impl.cc, xx_impl.h, xx.h ,qa_xx.py and the .i files
Index of /releases/gnuradio/ . I use gnuradio-3.6.0.tar.gz. My
gr-modtool is from GitHub - mbr0wn/gr-modtool: Keeping this repo, for now, for archeaological purposes..
Thanks,
Fei
Ok, update to 3.6.4 and use the version of gr_modtool that comes with
that new release. Since you are just updating from 3.6.0, updating
will be easy since there are no API changes required, just bug fixes
and added features, like the inclusion of gr_modtool.
Tom
Date: Mon, 15 Apr 2013 10:18:26 -0400
To: [email protected]
while ago.
Yep, that’s what you should be doing. What version of the code base
No, that’s not what you want to be doing. One of the whole points of
Fei
Ok, update to 3.6.4 and use the version of gr_modtool that comes with
that new release. Since you are just updating from 3.6.0, updating
will be easy since there are no API changes required, just bug fixes
and added features, like the inclusion of gr_modtool.
Tom
Thank you. i’ll give it a try.
Fei