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 <[email protected]> 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
