Oleg Nikitin
Oleg Nikitin
The problem with `add_block_from_query` looks like this:  Here are the test logs from running `ctest -R grc_tests` with `QT_QPA_PLATFORM=wayland` and `QT_QPA_PLATFORM=xcb` on different systems: [Arch_Hyprland_wayland_Test.log](https://github.com/gnuradio/gnuradio/files/13550657/Arch_Hyprland_wayland_Test.log) [Arch_Hyprland_xcb_Test.log](https://github.com/gnuradio/gnuradio/files/13550658/Arch_Hyprland_xcb_Test.log) [Fedora_Gnome45.2_wayland_Test.log](https://github.com/gnuradio/gnuradio/files/13550659/Fedora_Gnome45.2_wayland_Test.log) [Fedora_Gnome45.2_xcb_Test.log](https://github.com/gnuradio/gnuradio/files/13550660/Fedora_Gnome45.2_xcb_Test.log) [Ubuntu_Gnome42.9_wayland_Test.log](https://github.com/gnuradio/gnuradio/files/13550661/Ubuntu_Gnome42.9_wayland_Test.log)...
When a block is created using `gr_modtool`, in its public header a `static sptr make()` function is generated with arguments sourced from the `--argument-list` string; so the user is responsible...
Parameter block only allows 'complex', 'float', 'int', 'long' and 'string' types. Only complex numbers are evaluated at compile time ([here](https://github.com/gnuradio/gnuradio/blob/ff61502dcca8bdc1ede3c8dfa113635c1983a2c0/grc/core/generator/cpp_top_block.py#L354-L364)). Because the Parameter's values are not evaluated before rendering the...
Tried changing the `make` [template](https://github.com/AsriFox/gnuradio/blob/97727aee79c5c3ed6db00b595002faa7d2e01838/grc/core/generator/cpp_templates/flow_graph.hpp.mako#L88) to this: ``` static sptr make(${", ".join((param.vtype + " " + param.name + " = " + param.cpp_templates.render('make')) for param in parameters)}); ``` And it...
That sounds amazing! Maybe it should be implemented as a separate plugin, though? See #87 and https://github.com/anyrun-org/plugin-applications.
Fixes [this]( https://github.com/EttusResearch/gr-doa/issues/7#issuecomment-552253169) for newer versions of oct2py
There isn't any synchronization, tearing is not avoided. I'll work on that.
No more tearing, but the image flickers on low framerates. Not sure why.
The two threads *should* not access the same buffer, this is ensured by the `d_frame_pending` flag: when it's `false`, the render thread doesn't render; when it's `true`, the main thread...
@drmpeg Thank you! This test revealed two bugs in my code: * [x] Color planes have full width and height on input, but must have only half width and height...