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
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
