Re: [Discuss-gnuradio] Reorganization and restructuring on 3.6 (master) and 3.7 (next) branches
On Fri, May 11, 2012 at 10:37 PM, Andrew Davis wrote: >> free weekend > I had one once! > > So any plans for the application specific top-level blocks ( noaa, > pager, atsc )? I feel these could be moved to the CGRAN, or better yet > there could be a separate top-level folder for projects like this and > some of the GCRAN projects could be merged back into the main Gnuradio > git for better maintenance. ( A lot still use USRP instead of UHD and > even more still use autotools, this is giving me non-stop problems, > I'm working on updating a few ) Never hurts to have some well working > example projects showcasing Gnuradio! Andrew, We discussed this a bit on our last developers's call. I think your last point is one of the main reasons we won't move projects like gr-noaa or gr-pager out of GNU Radio. We want to keep some well-coded, working apps in the main source tree as references for people to use or look to. Second, CGRAN was built as a way around copyright issues of an FSF project. Since all code in GNU Radio must assign the copyright to it over to FSF, some projects wouldn't/couldn't do that, so CGRAN came about to solve it. That means that many of the projects there are not able to be moved back into GNU Radio. I'm afraid that with those, I don't see any way of avoiding bitrot issues unless someone is willing to take up the cause of maintaining them. As for a top-level apps directory in GNU Radio. I'm not opposed to it, but neither do I feel like it's important enough to move the current apps to something like that. If you have a really compelling argument for it, though, I'd like to listen. Tom > On Thu, May 3, 2012 at 12:10 AM, Marcus D. Leech wrote: >> On 03/05/12 12:07 AM, Josh Blum wrote: >>> >>> Just another free weekend, and I will have VOLK capable of generating >>> code to handle head and tail cases. >>> >>> >>> >> I once heard tell of this mythical "free weekend". I don't believe in >> it. It must be some kind of >> fairy tale. >> >> >> >> -- >> Principal Investigator >> Shirleys Bay Radio Astronomy Consortium >> http://www.sbrac.org >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reorganization and restructuring on 3.6 (master) and 3.7 (next) branches
> free weekend I had one once! So any plans for the application specific top-level blocks ( noaa, pager, atsc )? I feel these could be moved to the CGRAN, or better yet there could be a separate top-level folder for projects like this and some of the GCRAN projects could be merged back into the main Gnuradio git for better maintenance. ( A lot still use USRP instead of UHD and even more still use autotools, this is giving me non-stop problems, I'm working on updating a few ) Never hurts to have some well working example projects showcasing Gnuradio! On Thu, May 3, 2012 at 12:10 AM, Marcus D. Leech wrote: > On 03/05/12 12:07 AM, Josh Blum wrote: >> >> Just another free weekend, and I will have VOLK capable of generating >> code to handle head and tail cases. >> >> >> > I once heard tell of this mythical "free weekend". I don't believe in > it. It must be some kind of > fairy tale. > > > > -- > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reorganization and restructuring on 3.6 (master) and 3.7 (next) branches
On 03/05/12 12:07 AM, Josh Blum wrote: > > Just another free weekend, and I will have VOLK capable of generating > code to handle head and tail cases. > > > I once heard tell of this mythical "free weekend". I don't believe in it. It must be some kind of fairy tale. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reorganization and restructuring on 3.6 (master) and 3.7 (next) branches
It sounds like gnuradio is going to finally become completed. cool! > * gnuradio-runtime - top block and friends and runtime scheduler, very > small number of blocks for QA testing of runtime (vector source/sink, > null source/sink, etc.) > This will be awesome. That way someone could easily swap out runtime with an alternative. Or maybe if the classes are are virtual, it would be possible to swap the library itself with an ABI compatible one. * Consider removing gruel and splitting it into PMT as its own library, and take the straggly 2 or 3 things that remain into gr-runtime (we dont need that gruel inet thing either). * And replacing all of those vmcircbuff implementations with just a boost one. So far I have been hearing positive results: https://github.com/guruofquality/gnuradio/commit/eaa67d294b7b7f8aa13473a985ea56e0b59796b9 > Finally, during all this, as we implement the new block structure, > we're going to pay special attention to: > > - Reimplementing functionality using libvolk vector optimization where > possible Just another free weekend, and I will have VOLK capable of generating code to handle head and tail cases. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reorganization and restructuring on 3.6 (master) and 3.7 (next) branches
Some of you may have noticed recent check-ins that have added new top-level components (like gr-fft), or duplication of blocks (such as into gr-digital.) I'd like to explain the master plan Tom and I are working from and what to expect over the next few weeks. Essentially, we are making two things happen at the same time: - libgnuradio-core is going away, and its blocks are being reorganized into several new, smaller libraries - The C++ API is changing to use pure virtual interface classes, C++ namespaces, and segregated header files These two transitions will occur in such a way that as much work as possible will be completed on the master branch but without requiring any changes to your existing code, and the rest will happen on the next branch. The gnuradio-core component has accumulated hundreds of blocks over the last 10 years. In order to simplify and organize things, we are creating several new top-level components to replace it. The first step of this was done when gr-digital collected much of the digital modulation/demodulation code up into its own component. The second step was to create gr-wavelet and move the wavelet blocks into that. When we are done, the following top-level components will hold all the code that used to be in gnuradio-core: * gr-blocks - "basic" blocks used widely across many flowgraphs, like math operations, type conversions, stream/vector manipulation, file/message/network sources/sinks, etc. * gr-analog - analog waveform processing blocks such as signal sources, AM/FM modulation/demodulation, AGC, squelch, power measurement, etc. * gr-digital - digital waveform processing blocks such as PSK and OFDM modulation, scramblers, timing and carrier recovery, channel equalization, bit packing/unpacking, framers, deframers, CRC, etc. * gr-fec - Reed-Solomon and convolutional coding, future development * gr-fft - blocks that wrap the external FFTW library * gr-filter - FIR and IIR filters, filter design, resampling, channelizers, channel models * gr-vocoder - voice processing codecs * gr-wavelet - wavelet processing blocks, future development * gnuradio-runtime - top block and friends and runtime scheduler, very small number of blocks for QA testing of runtime (vector source/sink, null source/sink, etc.) The process we are following to get this done is to create the new top level components on the master branch and copy the existing blocks into them, then remove the old blocks from gnuradio-core *on the next branch only*. In this way, developers can, if they wish, start migrating their applications to use the new block hierarchy in their applications as they become available, without having to do it all at once. Existing code, however, can also be left alone without any impact as gnuradio-core itself will remain unchanged until the 3.7 release. Part of this process is already done--gr-vocoder, gr-digital, and gr-wavelet are part of the current release. The new gr-fft was merged into master recently. Soon, gr-filter will be added in, and then we will remove all fft and filter blocks out of gnuradio-core on the 3.7 branch only. Today, several more blocks from gnuradio-core were copied into gr-digital, and again, we'll soon delete those blocks out of gnuradio-core on the 3.7 branch only. Since we're touching so much code, we're taking the opportunity make a change to the C++ API to implement pure virtual interface classes for API visible code. This was discussed on the mailing list March 12. In addition, we're reorganizing the API to use C++ namespaces, which shortens filenames, simplifies the Python wrapper generation, and eliminates some redundancies in class naming. You can see an example of this in the new gr-fft directory on the master branch, or in the gr-wavelet directory on the next branch. The same process for dividing the work between the master branch and next branch applies here. Where possible, when we copy over blocks from gnuradio-core to the new top-level components, we'll convert them to use the new C++ coding style. This won't affect any existing user's code, as the old blocks will stay in gnuradio-core. For all the rest of GNU Radio outside of gnuradio-core, we'll be making the C++ changes on the next branch, again so as to not disturb existing user's code. Finally, during all this, as we implement the new block structure, we're going to pay special attention to: - Reimplementing functionality using libvolk vector optimization where possible - Updating or adding missing header file documentation - Converting code where needed to conform to the GNU Radio coding style guide - Adding QA test code if missing - Creating GRC block wrappers if missing - Removing obsolete code or other cruft Few of these changes will impact Python or GRC users, except that most blocks that once lived in the 'gr' namespace imported from gnuradio will instead import from a different namespace under gnuradio, such as is already done for gr-audio, gr-digital, g
