@rolledankle1000

ubuntu terminal on my laptop

Is this a Windows Subsystem for Linux terminal? That's where I've usually seen that message. If so I recently added some additional information to our install guide. https://wiki.gnuradio.org/index.php/WindowsInstall#WSL_.7C_Ubuntu

This is a windows subsystem of linux. Such as Ive downloaded Ubuntu from the microsoft store app

Hi, has there been any progress on this? If not, how hard would it be for someone new to the project (but not to C++) to implement it?

Just like in GR, but fit into the modular buffer design - are they all individual buffers, or is there one vmcircbuf that chooses the right factory like in gr

They are going to be like GR - wouldn't want the user having to select the underlying available implementation

Adds the CPU version of single mapped buffers

QA still fails sometimes which needs to be investigated

Signed-off-by: Josh Morman [email protected]

I had some errors installing the latest version of GNU radio earlier and did not manage to try the feature. I pushed the suggested code to the Github branch without extensively testing it. I'm a bit caught up with something else at the moment and will circle back once I get it working.

On Mon, May 17, 2021, 20:37 mormj ***@***.***> wrote:

Hi @tjeng https://github.com/tjeng - any regarding Marcus's concern?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gnuradio/gnuradio/pull/4559#issuecomment-842580338, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG5RM5JTDFFTIRHLCTOTDV3TOFV7LANCNFSM435MWFGA .

Hi @tjeng - any regarding Marcus's concern?

Looks like __init__.py is still referencing crc.py:

2021-05-17T16:06:32.8604558Z Scanning dependencies of target pygen_gr_digital_python_digital_471c2
2021-05-17T16:06:32.8646413Z make[2]: *** No rule to make target '/__w/gnuradio/gnuradio/gr-digital/python/digital/crc.py', needed by 'gr-digital/python/digital/__init__.pyc'.
2021-05-17T16:06:32.8649106Z make[2]: Target 'gr-digital/python/digital/CMakeFiles/pygen_gr_digital_python_digital_471c2.dir/build' not remade because of errors.
2021-05-17T16:06:32.8650644Z make[1]: *** [CMakeFiles/Makefile2:6887: gr-digital/python/digital/CMakeFiles/pygen_gr_digital_python_digital_471c2.dir/all] Error 2

Looking at the diff, I can see how this would fixe problems with validating raw string parameters. The cost, however, is re-running every single raw param eval. This is a pretty steep cost considering that evals always run just before check in the rewrite stage. So, if there is an error, it should happen during Param.rewrite(). Why doesn't it show up after validation?

A quick glance over the code shows a call Element.validate() in Param.validate(). This clears previous errors on the node, which is why after validate() all seems well. In order to fix this,

• either rewrite() must do the clearing of errors before running and validate() must not, or
• the error state must be passed some other way between the two stages.

i'm building a system with an X310 as the frontend receiver. i'd like to be able to use RFNoC blocks to split the stream from RX2 (RFA) into a high-rate(200Msps) stream and a decimated low-rate(5Msps) stream, sending high rate over SFP+ Port 0 and low-rate over SFP Port 1. Is that possible using stream args (channel=0,1 maybe?) in the rx streamer block? I can't seem to get any valid stream args to take. I'm working on building the splitstream block into my image, so for now I have been able to get RFA-RX2 and RFB-RX2 streams into gnuradio using 2 rx streamers (flowgraph attached), but according to tcpdump/iftop the streams are muxed onto one interface?

can you help?

Changes:

15543919f (Martin Braun, 6 minutes ago)
   digital: Gut packet_utils.py

   This module is a deprecated module and is used nowhere in GNU Radio, with
   the exception of a single variable (default_access_code). We keep that
   variable and remove all the rest.

   Because this module was the only consumer of crc.py, that was also removed.

   Signed-off-by: Martin Braun <[email protected]>

991725253 (Martin Braun, 2 hours ago)
   digital: Remove crc32 utility

   This patch removes a crc32 utility that used to be used in our CRC32 
   blocks, but no longer is. Right now, all this does is expose a generic 
   CRC32 function to the user (both via Python and C++), but there are enough
   other libraries that let the user do that. Therefore, we'll remove this.

   Signed-off-by: Martin Braun <[email protected]>

Thank you very much Christophe!

Just a question: Why does the variable block only have the fixed type raw ? I would be easy to extend to int, float and complex .....

This is a bug currently under investigation ( see Pull Request #4629). A simple temporary workaround is to add a GUI Hint in every QT GUI Tab widget for example 0,0 in yours

Im not sure how Conda works, but sudo apt install thrift-compiler gave me the thrift binary needed for my regular build

I have made that change, tested it, and added a Note to the FG. It is in https://pastebin.com/SUDchv4K That is the one I will use for the png in the tutorial

Might as well just use your flowgraph so itll be the same as in the tutorial. I believe beginners would greatly appreciate as little difference as possible between the provided example and the screenshot in the tutorial.

In this simple flowgraph:

I'm getting the following error: Traceback (most recent call last): File "/home/aaa/Desktop/Prova.py", line 196, in <module> main() File "/home/xxx/Desktop/Prova.py", line 172, in main tb = top_block_cls() File "/home/aaa/Desktop/Prova.py", line 128, in init self.Tab_grid_layout_0.addWidget(self._qtgui_time_sink_x_0_win, 1, 1, 1, 1) File "/home/aaa/sdr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 93, in getattr return getattr(self._impl, name) AttributeError: 'top_block_sptr' object has no attribute 'Tab_grid_layout_0'

Done (return code 1)

Gnuradio Companion Version: v3.8.2.0-118-g8b2012ab (Python 3.6.9)

I have made that change, tested it, and added a Note to the FG. It is in https://pastebin.com/SUDchv4K That is the one I will use for the png in the tutorial

Hello,

I'm currently following the tutorial on the GNU Radio Wiki on how to build an OOT module. I'm now trying to use the cmake command (I'm working on a conda environnement) to build my module but I get the following error :

(gnuradio) [Nicolas@ppsle-asx-n build]$ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ../
-- The CXX compiler identification is GNU 9.3.0
-- The C compiler identification is GNU 9.3.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/Nicolas/anaconda3/envs/gnuradio/bin/x86_64-conda-linux-gnu-c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/Nicolas/anaconda3/envs/gnuradio/bin/x86_64-conda-linux-gnu-cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.27.1") 
-- Found LOG4CPP: /home/Nicolas/anaconda3/envs/gnuradio/lib/liblog4cpp.so
-- Checking for module 'gmp'
--   Found gmp, version 6.2.1
-- Found GMP: /home/Nicolas/anaconda3/envs/gnuradio/lib/libgmpxx.so  
-- Checking for module 'mpir >= 3.0'
--   No package 'mpir' found
-- Found MPIR: /home/Nicolas/anaconda3/envs/gnuradio/lib/libmpirxx.so  
-- Found MPLIB: /home/Nicolas/anaconda3/envs/gnuradio/lib/libgmpxx.so  
-- Found Boost: /home/Nicolas/anaconda3/envs/gnuradio/lib/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.74.0") found components: date_time program_options filesystem system regex thread 
-- Found Volk: Volk::volk  
-- User set python executable /home/Nicolas/anaconda3/envs/gnuradio/bin/python
-- Found PythonInterp: /home/Nicolas/anaconda3/envs/gnuradio/bin/python (found version "3.9.4") 
-- Found PythonLibs: /home/Nicolas/anaconda3/envs/gnuradio/lib/libpython3.9.so (found suitable exact version "3.9.4") 
-- Found PythonLibs: /home/Nicolas/anaconda3/envs/gnuradio/lib/libpython3.9.so
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Found pybind11: /home/Nicolas/anaconda3/envs/gnuradio/include (found version "2.6.2" )
-- Checking for module 'thrift'
--   Found thrift, version 0.14.1
-- Binary 'thrift' not found.
-- Found Git: /usr/bin/git  
-- Found Doxygen: /home/Nicolas/anaconda3/envs/gnuradio/bin/doxygen (found version "1.9.1 (ab553a81f1725c385ca98109c269b0222389b72a*)") found components: doxygen missing components: dot
-- Using install prefix: /home/Nicolas/anaconda3/envs/gnuradio
-- Building for version: v1.0-compat-xxx-xunknown / 1.0.0git
-- No C++ unit tests... skipping
-- PYTHON and GRC components are enabled
-- Python checking for pygccxml - not found
-- Configuring done
CMake Error at /home/Nicolas/anaconda3/envs/gnuradio/share/cmake/pybind11/pybind11Tools.cmake:166 (add_library):
  Target "howto_python" links to target "Thrift::thrift" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  /home/Nicolas/anaconda3/envs/gnuradio/lib/cmake/gnuradio/GrPybind.cmake:239 (pybind11_add_module)
  python/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)


CMake Error at lib/CMakeLists.txt:24 (add_library):
  Target "gnuradio-howto" links to target "Thrift::thrift" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

As you can see it seems that the target "Thrift" could not be found. Could you tell me if you have any intel on how I could fix this issue ? Thanks a lot

Nicolas

Backport https://github.com/gnuradio/gnuradio/pull/4570

I tested this under GR 3.9.1 (without the black_listed_ids parameter ). It fixes issues #4519 and #4531 in an elegant way. Moving from advanced tab and general tab , the error is always shown in red and correctly documented. (I did not tested for embedded python block)

Cleanup of the code. Actually using the mutex. Safer preference writing using atomic rename.

Backport https://github.com/gnuradio/gnuradio/pull/4504

Closing, this will be a 3.10 change.

If this if statement always returns true, then finding the theme name should not be necessary - this doesn't seem right as this theme name is not used anywhere else in the code.

The logic makes sense here in that if you have the gtk setting gtk-application-prefer-dark-theme=true then it should default to a dark them, so that

• If a user has selected a dark theme, this method will return True
• If a user has config option "prefer dark theme" then this will always return true

I don't have a good setup here with dark themes and haven't reproduced the original issue - going to get an additional set of eyes on the logic here.