Thank you for the advice, I have gotten this working now. It was a user
error in that I was not including the gnuradio/digital/constellation.h file
in the swig .i. Also to note for anybody in the future, I also had to link
the libgnuradio-digital.so into the CMakeLists.txt file in the lib
directory at the end of the target_link_libraries line. This was due to a
runtime python error about not being able to find the constellation object
in the OOT .so object.
Thank you very much,
Michael Berman
On Thu, Sep 26, 2013 at 8:14 AM, Tom Rondeau <t...@trondeau.com> wrote:
> On Tue, Sep 24, 2013 at 7:56 PM, Michael Berman <mrberma...@gmail.com>
> wrote:
> > Upon looking at the generated *_swig.py files, I am seeing more of the
> > differences. For some reason my OOT module is not generating the python
> > wrapper for the constellation_theta class, it is only creating the
> wrapper
> > for the shared pointer object. I am curious now as to what the gnuradio
> > swig interface files are doing elsewhere that are causing that build to
> pick
> > up the object files when only the shared pointer is called out in the
> swig
> > .i file.
> >
> > Thank you very much for the help,
> >
> > Michael Berman
>
> All I can suggest right now is to make sure your .h file is properly
> included in the swig.i file. Notice that in digital_swig.i, it's
> included twice, once in line 51 (#include inside the %{ and %}) and
> line 121 (as %include).
>
> But also note the %include of constellation.i. This is needed to
> Python-ize some of the interfaces.
>
> Tom
>
>
>
> > On Tue, Sep 24, 2013 at 1:16 PM, Michael Berman <mrberma...@gmail.com>
> > wrote:
> >>
> >> I am having issues implementing what was discussed previously. I have
> >> created an OOT module (constellation_theta), and placed it within the
> >> gr::digital namespace. All of the cpp code is written and working
> fine. As
> >> I am attempting to add a custom constellation, I used the existing
> instances
> >> of constellations (bpsk, qpsk, etc.) as an example for my constellation
> >> object as far as the swig .i files and the cpp files from the gr-digital
> >> section of the gnuradio gr-digital source for my new module. When I
> attempt
> >> to run this module, I get the following python runtime error:
> >>
> >> ........
> >> File
> >>
> "/usr/local/lib/python2.7/dist-packages/constellation_theta/constellation_theta_swig.py",
> >> line 102, in <module>
> >> constellation_theta = constellation_theta.make;
> >> NameError: name 'constellation_theta' is not defined
> >>
> >> This line is driven directly from the swig .i file, of which I copied
> the
> >> format from the .../gnuradio/gr-digital/swig/constellation.i file.
> >> Comparing the generated .py files from the installed swig generated
> code, I
> >> also do not understand why I have so many differences from this. The
> >> gnuradio code has the cpp class laid out inside the .py file perfectly,
> with
> >> all of the exposed methods; however, my code has none of that, just the
> >> basic constructor (which I don't even want exposed to preserve the
> shared
> >> pointer structure).
> >>
> >> I am not sure where to go from this point on getting this up and
> running,
> >> any help would be greatly appreciated.
> >>
> >>
> >> Thank you very much,
> >>
> >> Michael Berman
> >>
> >>
> >> On Mon, Sep 23, 2013 at 9:21 AM, Michael Berman <mrberma...@gmail.com>
> >> wrote:
> >>>
> >>> Tom,
> >>>
> >>> Thanks for the response. This is what i was thinking was the
> appropriate
> >>> action, I just wanted to make sure. As for the header, I didn't
> realize I
> >>> didn't add one until after I sent the email out; I'll try to not let
> that
> >>> one happen again.
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Michael Berman
> >>>
> >>>
> >>> On Sat, Sep 21, 2013 at 8:09 AM, Tom Rondeau <t...@trondeau.com> wrote:
> >>>>
> >>>> On Fri, Sep 20, 2013 at 7:55 PM, Michael Berman <mrberma...@gmail.com
> >
> >>>> wrote:
> >>>> > I am attempting to add a custom constellation class to be used with
> >>>> > the
> >>>> > generic_mod_demod object for digital PSK. I have the code working
> as
> >>>> > a
> >>>> > simple addition to the gnuradio source with a re-compilation,
> however
> >>>> > I
> >>>> > would like to set this up similar to an Out Of Tree module (although
> >>>> > it
> >>>> > isn't entirely a standalone module). Would the way I go about
> >>>> > approaching
> >>>> > this be the same as the adding an Out Of Tree module tutorial on the
> >>>> > gnuradio website? Or would there be a preferred method than the
> >>>> > gr_modtool.
> >>>> > I would like to set this up so that the code I add sits in the
> >>>> > gr::digital
> >>>> > scope and have everything look as though it all sits in the
> >>>> > constellation.{cc, h, i} files. Does anybody have recommendations
> for
> >>>> > attacking this task?
> >>>> >
> >>>> >
> >>>> > Thank you very much,
> >>>> >
> >>>> > Michael Berman
> >>>>
> >>>> Hi Michael,
> >>>> Please use a proper subject line in the future to help us sort and
> >>>> keep track of things.
> >>>>
> >>>> As to your question, that shouldn't be a problem. You should be able
> >>>> to create a class in your OOT module and inherit from
> >>>> gr::digital::constellation (or one of it's children). And just putting
> >>>> it inside the gr::digital namespace. This will obviously now exist in
> >>>> your own lib<yourlibrary>.so and not in libgnuradio-digital.so. So I'm
> >>>> not sure what you mean by "sits inside constellation.{cc,h,i}". If you
> >>>> are in an OOT project, you wouldn't be able to add this directly to
> >>>> the gnuradio-digital library or Python module (ok, there's a way to do
> >>>> the latter by smashing it in during install, but that's seriously ugly
> >>>> business that you want no part of).
> >>>>
> >>>> And use gr_modtool. Definitely the best, easiest, and preferred way of
> >>>> setting things up. When creating your new class, use 'gr_modtool add'
> >>>> and for the 'code type' use 'noblock.'
> >>>>
> >>>> --
> >>>> Tom
> >>>> GRCon13 Oct. 1 - 4
> >>>> http://www.trondeau.com/grcon13
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
