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

[Glen Langston]

Thanks Josh for your quick response.

I’ve written c++ code for gnuradio successfully before.   I’m not
sure what is different about this, very simple, code.

What does “out of sync” mean specifically?   I’ve got the same calling
arguments in both files, modulo the different programming styles for
python and c++.  

Is there an “ignore this error” flag in “cmake”?

Thanks

Glen
> On Jan 4, 2024, at 4:52 PM, Josh Morman <jmorman@gnuradio.org> wrote:
> 
> Hi Glen,
> 
> The file that is out of sync is 
> vsum_python.cc
> 
> This can be updated using 
> gr_modtool bind vsum
> 
> This ensures that changes in vsum.h are reflected in the python bindings.
> 
> Josh
> 
> On Thu, Jan 4, 2024 at 2:05 PM Glen Langston <glen.i.langston@gmail.com> 
> wrote:
> 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
> 
>