Re: [Discuss-gnuradio] custom tagged_stream_block basetype and swig

[Marcus Müller]

Hi Miklos,

what surprises me a bit is that you're introducing a new block
scheduling semantic in an OOT – wouldn't you have to modify the
scheduler to make it do things differently when encountering a
tagged_stream_block2 ?

Also, maybe we'd want to have a short chat about what your application
needs and why a modification of the tagged_stream_block behaviour is
what you want in that case. I must admit, I'm not the biggest fan of the
technology behind TSBs myself, and if I'd be reimplementing stuff right
now, I wouldn't do it TSB-alike. Now, in fact, I'm considering how to
improve (read: in many places, rewrite) the current GNU Radio scheduler,
so I'd be very interested in the feedback you could offer about what GR
is lacking for your current use case.

Best regards,

Marcus

On 07/30/2017 11:45 PM, Miklos Maroti wrote:
> Hi All,
>
> Ok, I found the way to do it and want to report for others who run
> into this. We have to trick SWIG thinking that those virtual functions
> are not there. This is done in tagged_stream_block.i within GnuRadio
> like this:
>
> class gr::tagged_stream_block : public gr::block
> {
>  protected:
>   tagged_stream_block(const std::string &name,
>                       gr::io_signature::sptr input_signature,
>                       gr::io_signature::sptr output_signature,
>                       const std::string &length_tag_key);
> };
>
> I knew about this and I have experimented with it within my OOT
> module, but I made an error: I put the adapted version at the end of
> the mymodule_swig.i, but that is too late and gave no meaningful
> errors. When moved to the front that gave different errors, then after
> some SWIG doc reading and google foo I was able to see what was
> happening. The following worked me (and it is not enough to do the
> trick within the mymodule_swig.i file because we are reusing this
> class within the same module). I rewrote the tagged_stream_block2.h
> header like this:
>
> #ifndef SWIG
>
> class MYMODULE_API tagged_stream_block2 : public gr::block {
> protected:
>     tagged_stream_block2(void) {}
>     tagged_stream_block2(const std::string &name,
> gr::io_signature::sptr input_signature, gr::io_signature::sptr
> output_signature, const std::string &length_tag_key);
>     virtual int calculate_output_stream_length(const gr_vector_int
> &ninput_items) = 0;
>     ...
> public:
>     void forecast(int noutput_items, gr_vector_int &ninput_items_required);
>     int general_work(int noutput_items, gr_vector_int &ninput_items,
> gr_vector_const_void_star &input_items, gr_vector_void_star
> &output_items);
>     virtual int work(int noutput_items, gr_vector_int &ninput_items,
> gr_vector_const_void_star &input_items, gr_vector_void_star
> &output_items) = 0;
> }
>
> #else
>
> class MYMODULE_API tagged_stream_block2 : public gr::block
> {
> protected:
>     tagged_stream_block2(const std::string &name,
> gr::io_signature::sptr input_signature, gr::io_signature::sptr
> output_signature, const std::string &length_tag_key);
> };
>
> #endif
>
> Then you also have to add the following line to mymodule_swig.i before
> the other %includes
>
> %include "mymodule/tagged_stream_block2.h"
>
> Best,
> Miklos
>
> On Sun, Jul 30, 2017 at 2:13 PM, Miklos Maroti <address@hidden> wrote:
>> Hi All,
>>
>> It seems that no one really has the SWIG expertise. Just to reiterate,
>> if I copy tagged_stream_block from GnuRadio into my OOT, and rename
>> it, it has the exact same compile problem. Now I wonder if GnuRadio
>> has some magic with the SWIG generation, maybe the base blocks are
>> hard coded somewhere in the generator scripts? If so, I could not find
>> it.
>>
>> The problem seems to be that for OOT blocks deriving
>> tagged_stream_block the constructor is not wrapped, instead the make
>> is used as the block (not the implementation) still has pure virtual
>> functions. However, if I change the code to derive
>> tagged_stream_block2, then it wants to generate a constructor and of
>> course that fails. But why?
>>
>> Best,
>> Miklos
>>
>> On Fri, Jul 28, 2017 at 6:34 PM, Miklos Maroti <address@hidden> wrote:
>>> Dear All,
>>>
>>> For various reasons I am not happy with the tagged_stream_block
>>> implementation, and I have implemented my own version, called
>>> tagged_stream_block2 and put it into my OOT module. I can use the
>>> gr_modtool to create tagged_stream_blocks and manually change the
>>> basetype to my version. Everything seems to work fine, except with
>>> SWIG generated code. There I get undefined references error to virtual
>>> methods (e.g. work). However the C++ code compile fine and no such
>>> error is presented. In fact, before I deleted the build directory and
>>> rebuilt everything even GRC and SWIG was happy after a regular make.
>>> However, once I rebuilt everything with cmake I get these issues in
>>> the SWIG generated code. This is the layout:
>>>
>>> tagged_stream_block2.h goes into the include directory and listed in
>>> the CMakeFile.txt
>>> tagged_stream_block2.cc goes into the lib directory and listed in the
>>> CMakeFile.txt
>>> the swig directory CMakeFile is not changed
>>>
>>> Can anyone with SWIG expertise help? I have attached the complete error 
>>> message.
>>>
>>> Best,
>>> Miklos
>>>
>>> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx: In
>>> function ‘PyObject* _wrap_new_myblock(PyObject*, PyObject*)’:
>>> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:44104:85:
>>> error: invalid new-expression of abstract class type
>>> ‘gr::mymodule::myblock’
>>>        result = (gr::mymodule::myblock *)new gr::mymodule::myblock();
>>>
>>>               ^
>>> In file included from
>>> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:4412:0:
>>> ~/workspace/gr-mymodule/include/mymodule/myblock.h:36:20: note:
>>> because the following virtual functions are pure within
>>> ‘gr::mymodule::myblock’:
>>>  class MYBLOCK_API myblock : virtual public gr::tagged_stream_block2 {
>>>                     ^
>>> In file included from 
>>> ~/workspace/gr-mymodule/include/mymodule/myblock.h:26:0,
>>>                  from
>>> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:4412:
>>> ~/workspace/gr-mymodule/include/mymodule/tagged_stream_block2.h:69:3:
>>> note: virtual int
>>> gr::tagged_stream_block2::calculate_output_stream_length(const
>>> gr_vector_int&)
>>>    calculate_output_stream_length(const gr_vector_int &ninput_items) = 0;
>>>    ^
>>> ~/workspace/gr-mymodule/include/mymodule/tagged_stream_block2.h:79:15:
>>> note: virtual int gr::tagged_stream_block2::work(int, gr_vector_int&,
>>> gr_vector_const_void_star&, gr_vector_void_star&)
>>>    virtual int work(int noutput_items, gr_vector_int &ninput_items,
>>>                ^
>>> swig/CMakeFiles/_mymodule_swig.dir/build.make:68: recipe for target
>>> 'swig/CMakeFiles/_mymodule_swig.dir/mymodule_swigPYTHON_wrap.cxx.o'
>>> failed
>>> make[2]: *** 
>>> [swig/CMakeFiles/_mymodule_swig.dir/mymodule_swigPYTHON_wrap.cxx.o]
>>> Error 1
>>> CMakeFiles/Makefile2:237: recipe for target
>>> 'swig/CMakeFiles/_mymodule_swig.dir/all' failed
>>> make[1]: *** [swig/CMakeFiles/_mymodule_swig.dir/all] Error 2
>>> Makefile:138: recipe for target 'all' failed
>>> make: *** [all] Error 2
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio