Please note that there is an issue with the RC3 that has been resolved on the master branch (thanks to drmpeg for catching and fixing a cmake build order dependency that prevented the grc files from being installed).
The current master branch has this fixed and will be the basis of 3.10. Please raise the alarms if you run into any other issues either here or on #development Josh On Sat, Jan 8, 2022 at 9:23 PM Josh Morman <jmor...@gnuradio.org> wrote: > 3.10.0.0-rc3 is now available: > https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc3 > > There were a few changes since RC2, but this should be basically it for > 3.10 (hard freeze unless something critical is discovered), so please give > it a test if you have a chance. > > If things go well, the plan is to release the final 3.10.0.0 next Friday > Jan 14! Thanks to all who have been contributing and participating in the > discussions. > > Josh > > > > On Sat, Dec 11, 2021 at 8:51 AM Josh Morman <jmor...@gnuradio.org> wrote: > >> >> 3.10.0.0-rc2 is now available: >> https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc2 >> and you can see the current changelog here: >> https://github.com/gnuradio/gnuradio/blob/master/CHANGELOG.md >> The plan is to make a final release mid-January, so this may involve one >> more RC if there are any more major issues to sort out. >> >> Have a great weekend! >> >> Josh >> >> On Sat, Nov 27, 2021 at 10:29 AM Josh Morman <jmor...@gnuradio.org> >> wrote: >> >>> Greetings GNU Radio Community! >>> >>> Release 3.10 is expected to drop sometime in the new year, but to get >>> the ball rolling with testing and packaging - we are expecting a longer >>> than usual Release Candidate cycle, and likely there will be *at least* >>> one more RC, so here is v3.10.0.0-rc1 >>> <https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc1> >>> >>> We have been fortunate this year to have extremely active backporting >>> and consistent maintenance releases from co-maintainter Jeff Long - so many >>> of the fixes and smaller feature (and larger ones) have already seen the >>> light of day in the 3.9.x.x and even 3.8.x.x releases. Here are some of >>> the bigger features that are bringing about this major release. >>> >>> *gr-pdu* >>> PDUs (protocol data units) in GNU Radio are a special type of PMT that >>> have a dictionary and a uniform vector type representing a burst of data >>> with some metadata. Up to this point, support of pdus has been scattered >>> throughout the codebase with minimal support for handling this type of data >>> consistently. Fortunately, Jacob Gilbert has been able to upstream much of >>> the amazing work from himself and the team at Sandia National Labs which >>> brings in-tree a suite of tools for manipulating these data objects (see >>> https://github.com/sandialabs/gr-pdu_utils). Also, many of the >>> previous PDU processing blocks that existed in other in-tree modules have >>> been migrated to this module, so there has been some block re-arrangement. >>> Please see https://www.youtube.com/watch?v=bT60hVVte48 for more >>> detailed information >>> >>> *gr-iio* >>> IIO is the industrial I/O framework that provides an industry standard >>> method for communicating with a wide-range of devices including many of the >>> ADI SDR platforms. Analog Devices has supported out of tree a gr-iio >>> module that brings this capability into GNU Radio and now upstreamed this >>> module so support for devices like the PlutoSDR are available out of the >>> box. Special thanks here to Adam Horden, Travis Collins, Dave Winter, >>> Volker Shroer, and Jeff Long for bringing this in-tree and working through >>> many of the complexities. >>> Please see https://www.youtube.com/watch?v=2gKbollW6wg for a more >>> technical description of IIO and gr-iio. >>> >>> *Custom Buffers Support* >>> NOTE: this is an advanced "experimental" feature that if not actively >>> employed will not affect normal GNU Radio usage. >>> David Sorber from Black Lynx has introduced a feature that enables >>> streamlined data movement between GNU Radio blocks and hardware >>> accelerators. By creating a "custom buffer" class (or using one that is >>> provided by someone else), blocks can be made to abstract the data movement >>> behind the scenes so that when the `work` function is reached, data already >>> exists in the device memory. >>> Let me give a quick example - previously if you wanted to write a GPU >>> accelerated block with CUDA, you would have to get into the work function, >>> move the data from the GNU Radio circular buffers to GPU device memory, >>> execute the CUDA kernels, then move the data back to GR buffers. Now that >>> data movement is done behind the scenes if the block is set up right so >>> that when the work function is hit, the data is in GPU device memory and >>> will get transferred back to CPU memory behind the scenes as well. This >>> allows back to back HW accelerated blocks to not have to ingress/egress in >>> and out of GR memory unnecessarily. Also, the single mapped buffer >>> abstraction brings huge performance benefits as can be seen here: >>> https://www.youtube.com/watch?v=VO1zMXowezg for a much better >>> description >>> For examples of this in action, please see the following repositories: >>> https://github.com/BlackLynx-Inc/gr-cuda_buffer >>> https://github.com/BlackLynx-Inc/gr-blnxngsched >>> This out of tree support will soon find its way into the gnuradio github >>> repo as a set of CUDA buffers and blocks. >>> >>> *Logging Infrastructure* >>> Log4CPP has previously been our logging backend library, but has become >>> a troublesome dependency. A huge thanks to Marcus Müller for fixing all of >>> this up, replacing Log4CPP with spdlog - a more modern logging library. >>> This also opens up the door for more modern logging statements that don't >>> rely on Boost.format, and libfmt (which is now also a dependency) can be >>> used for general string manipulation as well. All the previous methods and >>> macros still exist (except for the log4cpp specific ones), but there is now >>> new capability to log in a more convenient way using the libfmt statements. >>> >>> Old: GR_LOG_INFO(this->d_logger, boost::format("this happened: %d") % >>> code) >>> New: this->d_logger->info("this happened {:d}", code) >>> >>> As always, please reach out here or on chat.gnuradio.org if you have >>> any questions - and file GitHub issues if you find bugs or problems with >>> the release. The step from 3.9 should be pretty minimal, but if you are >>> migrating your OOTs - please update the porting guide if you come across >>> differences that need to be documented: >>> >>> https://wiki.gnuradio.org/index.php/GNU_Radio_3.10_OOT_Module_Porting_Guide >>> >>> Have a happy Holiday season and much thanks to all who have contributed >>> toward this next major release. >>> >>> Josh >>> >>> >>>
