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
