fair-acc
Add templated bitwise AND block with tests
Refs #161
Ported the bitwise AND functionality from GNU Radio 3.10 to GNU Radio 4 as a templated And block, enabling support for multiple integer types via templates.
The implementation is covered by Boost.UT unit tests, validating basic operations, edge cases, and boundary conditions.
Changes:
- Added:
blocks/basic/include/gnuradio-4.0/basic/And.hpp,blocks/basic/test/qa_And.cpp - Updated:
blocks/basic/CMakeLists.txt,blocks/basic/test/CMakeLists.txt
The current tests cover key scenarios. Should I extend them to include additional bit patterns?
Updated (2025-04-18):
- Added More Blocks:
AndConst.hpp,Not.hpp,Or.hpp, andXor.hpp - Added Test for Blocks:
qa_AndConst.cpp,qa_Not.cpp,qa_Or.cpp, andqa_Xor.cpp - Updated:
blocks/basic/CMakeLists.txt,blocks/basic/test/CMakeLists.txt
@RalphSteinhagen Thank you for the feedback! Yes, I’d be happy to continue working on implementing the full set of 'Boolean Operators' for EPIC#161.
Let me know if there are any specific considerations I should keep in mind. Looking forward to contributing more!
@alexhojinpark could you perhaps rebase and (force-)push (possibly with your other additions) again? I changed the restyled bot to (hopefully) accept external public PRs. The previous rule was a bit too restrictive. To become active, you'd need to rebase to the present head in 'main' though. Thanks in advance.
@RalphSteinhagen Thanks for the update, I’ve rebased and force-pushed accordingly. No new additions yet, all tests pass locally!
@alexhojinpark thanks for the rebase ... at least shows that the restyled CI step is now also working for remote public forks...
... it also shows that you maybe need to apply the code formatter. ;-)
See here and the CI check for details:
Can be done with your next pushes though...
@alexhojinpark how did u build the gnuradio4 locally.. and set it up, can u explain ?
@codblack789 Hi, For setting up GNURadio4, I’d check the Building section in the README. It walks you through dependencies and CMake setup.
Once you’ve got the build dir ready (gnuradio4/build/), you can run make there to build it locally. Hope it answered your question!
@alexhojinpark Yeah I followed the same steps
- Clone
- cd gnuradio4 3.mkdir build 4.cd build
5.cmake -DCMAKE_BUILD_TYPE=RelWithAssert -DENABLE_BLOCK_PLUGINS=ON -DENABLE_BLOCK_REGISTRY=ON .. 6 --build . -- -j$(nproc)
After that when i open the same in VS code, I get Errors near header files !!
No idea where am I going wrong !!
@alexhojinpark Yeah I followed the same steps
- Clone
- cd gnuradio4 3.mkdir build 4.cd build
5.cmake -DCMAKE_BUILD_TYPE=RelWithAssert -DENABLE_BLOCK_PLUGINS=ON -DENABLE_BLOCK_REGISTRY=ON .. 6 --build . -- -j$(nproc)
After that when i open the same in VS code, I get Errors near header files !!
No idea where am I going wrong !!
@alexhojinpark
Hey there! I noticed the CI checks are failing for formatting (Restyled) and Sonar. Since I don’t have permission to push changes to your branch(@RalphSteinhagen :( ), I wanted to offer some pointers:
Restyled (clang-format): You can apply the suggested formatting locally by running something like:
clang-format -i blocks/basic/include/gnuradio-4.0/basic/And.hpp blocks/basic/test/qa_And.cpp
git commit -am "Apply clang-format suggestions"
git push
This should resolve the restyled check.
Sonar: Sometimes forks can’t access Sonar credentials, so it may be normal for that check to fail from an external PR. You might ask the maintainers(@mormj, @wirew0rm) if it can be ignored or if they have a workaround.
Let me know if you need more details—happy to help walk you through the steps!
@KrxGu and @alexhojinpark alternatively you can check the GitHub restyled action output that indicates what and how to apply missing restyled diff.
Small edits aside, we cannot fix remote branches (N.B. @alexhojinpark is pushing from his forked repo). That's normal ...
@KrxGu @RalphSteinhagen
Thank you for the suggestions. I'll make sure to follow the restyled format, and push with all other Boolean Operators (5 blocks) which I am working on right now. :)
@alexhojinpark do you plan to continue working on this PR? If yes, you may need to rebase against the latest main commit.
Hi @alexhojinpark - really appreciate the effort in working through the process of creating a new GR4 block. I would recommend closing this in favor of #595 as it has covered a larger number of similar blocks and pushed through a number of CI issues.
