Python Bindings Out of Sync: Which files are out of sync?

[Glen Langston]

Hello

I’m running gnuradio 3.9.x and am writing a couple simple C++ blocks.

in ~/test/lib 

I have vsum_impl.cc <http://vsum_impl.cc/> and vsum_impl.h

In ~/test/python/radio_astro/bindings

I have vsum.h

I get these messages in the build “make ..” step:

...
-- PYTHON and GRC components are enabled
-- Python checking for pygccxml - not found
-- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.9.so
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Found pybind11: /usr/include (found version "2.6.2" )
CMake Error at /usr/local/lib/cmake/gnuradio/GrPybind.cmake:221 (message):
  Python bindings for vsum.h are out of sync
Call Stack (most recent call first):
  python/radio_astro/bindings/CMakeLists.txt:39 (GR_PYBIND_MAKE_OOT)


-- Configuring incomplete, errors occurred!
See also 
"/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeOutput.log".
See also 
"/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeError.log".

Could someone remind me exactly which files are “out of sync”?

vsum.h must be one, but which is the other?   I think that vsum_impl.h and 
vsum.h are consistent
(but not, of course, identical).

Thanks!

Glen



> On Dec 30, 2023, at 8:16 AM, Marcus Müller <marcus.mueller@ettus.com> wrote:
> 
> Heyo Kimmo,
> sorry for the delayed response:
> On 29.12.23 01:00, Kimmo Lehtinen wrote:
>> I would like to make modifications to the following two GNURadio blocks:
>> 1) QT GUI number sink-------------------------------
>> I would like to modify it so that it can also display integers and strings. 
>> Currently it can display floats, shorts and bytes.
>> I raised an issue about this at the Github page of GNURadio, and I got the 
>> following reply:"A number of GR blocks infer type from item size, and that's 
>> what this block does (in its constructor). Unfortunately, float and int32 
>> are the same size, so int32 is not usable.It would be possible to add 
>> another constructor that uses an explicit type instead of item size."
> Warning: this is probably more involved than you hoped for. If you've worked 
> with C++ before: No problem, you can at any point always ask for help. It's 
> also super helpful to use "Draft PR" on github to share your current state of 
> affairs!
> If you haven't: I think this might be a bit too hard.
> Yep, you would need to copy the make function as declared in number_sink.h in 
> [0]:
>     static sptr make(size_t itemsize,
>                      float average = 0,
>                      graph_t graph_type = NUM_GRAPH_HORIZ,
>                      int nconnections = 1,
>                      QWidget* parent = NULL);
> 
> to a second make function that has a different signature, for example
>     static sptr make(item_type_t itemtype,
>                      float average = 0,
>                      graph_t graph_type = NUM_GRAPH_HORIZ,
>                      int nconnections = 1,
>                      QWidget* parent = NULL);
> where item_type_t is a "Scoped enum"/class enum [1]; something like, within 
> number_sink class,
> enum class item_type_t { FLOAT, INT32 , INT16, INT8 }; // or whatever types 
> you want to support
> Then you would actually need to implement that in number_sink_impl.cc like 
> [2]. But for that you need to modify the actual constructor to not take 
> size_t itemsize as argument [3], but item_type_t itemtype!
> You would add a field const item_type_t d_itemtype and remove d_itemsize in 
> number_sink_impl.h [4] and add it to the initializer list [5]; you'd want a 
> switch()/case construct to set the alignment_multiple [6].
> Then, you replace the switch (d_itemsize) in get_item [7] with an appropriate 
> switch(d_itemtype). 
> Test it successfully compiles!
> Now you only need to do two things to 
> gr-qtgui/python/qtgui/bindings/number_sink_python.cc 
>     • add the new class enum item_type_t to bind_number_sink [8],
>     • add the new make function:
>         • modify the existing definition and
>         • copy it to replace size_t itemsize with number_sink::item_type_t 
> itemtype
> In detail: following [9], you need to change
>     py::class_<number_sink,
>                gr::sync_block,
>                gr::block,
>                gr::basic_block,
>                std::shared_ptr<number_sink>>(m, "number_sink", D(number_sink))
> 
>         .def(py::init(&number_sink::make), 
>         …………………
> 
> into
>     py::class_<number_sink,
>                gr::sync_block,
>                gr::block,
>                gr::basic_block,
>                std::shared_ptr<number_sink>>
>         number_sink_wrapper(m, "number_sink", D(number_sink));
> 
>     py::enum_<number_sink::item_type_t>(number_sink_wrapper, "item_type_t");
> 
>     number_sink_wrapper
>         .def(py::init(&number_sink::make),
>         ……………………
> Please compile the result (make sure to make clean before, we've changed 
> bindings), and test it works, from python!
> Now, we need to tell GRC that there's a new way to create a Qt GUI number 
> sink! So, modify qtgui_humber_sink.block.yml [10] to use the new make 
> function instead of the old (both in the python templates:       directive, 
> and in the C++ cpp_templates: directive), and add the integer option to id: 
> type. Then make; make install and open GRC and try!
> Definitely make sure you also add an example GRC flowgraph to the 
> gr-qtgui/examples director.
> Then, please make a commit with a title that starts with "qtgui: ", for 
> example "qtgui: add type-based number_sink, allowing for int32", and don't 
> forget to use the -s flag with git commit, so that your commit is signed off! 
> Push to your fork of GNU Radio, and open a Pull Request against main.
> [0] 
> https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/include/gnuradio/qtgui/number_sink.h#L55-L68
> [1] https://en.cppreference.com/w/cpp/language/enum#Scoped_enumerations
> [2] 
> https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.cc#L38-L43
> [3] 
> https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.cc#L46
> [4] 
> https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.h#L28
> [5] 
> https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.cc#L50
> [6] 
> https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/lib/number_sink_impl.cc#L64
> [8] 
> https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/python/qtgui/bindings/number_sink_python.cc
> [9] 
> https://pybind11.readthedocs.io/en/stable/classes.html#enumerations-and-internal-types
> [10] 
> https://github.com/gnuradio/gnuradio/blob/86af478a88cf0521b023ad2c924c74ea38d9adcf/gr-qtgui/grc/qtgui_number_sink.block.yml
>> If displaying strings, there is no sense to have a bar graph, which is 
>> currently an option in the 'QT GUI number sink' block. Thus, there could be 
>> a separate block for displaying strings, without an option for a bar graph. 
> Qt GUI Label can already do that; since there's no possibility to send 
> strings on GNU Radio streams, the question is more: where do your strings 
> come from!
>> 2) QT GUI time raster sink-----------------------------------
>> I would like to modify it so that the parameters 'x-axis start value' and 
>> 'x-axis end value' can be changed during runtime. 
> sounds like a good idea.
>> For example, in the 'QT GUI vector sink' block the corresponding parameters 
>> can be changed during runtime. 
>> 
>> I understand that the best way to make the modifications is to change the 
>> code and then recompile the whole GNURadio.
> yes
>> 
>> The problem is that I cannot write C++ code...
> So, you really can't :( I think this really means that hopefully someone with 
> time finds this email and implements that!
>> Is there anyone willing to change the code ?   Or at least give good 
>> instructions how to do that. 
>> 
>> I think these modifications would be useful also to other GNURadio users :-)
> Ideally, you'd open a Feature Request on github,
> https://github.com/gnuradio/gnuradio/issues/new?assignees=&labels=Feature+Request&projects=&template=feature_request.yml
> You can simply copy and paste your email into feature description, and paste 
> my reply into "More information", preceded by "Marcus says:" 
> 
> Best,
> Marcus