[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Recent development activity, upcoming plans

From: Josh Blum
Subject: Re: [Discuss-gnuradio] Recent development activity, upcoming plans
Date: Sun, 01 Apr 2012 23:17:45 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

> - Removal of dependency on gsl for gnuradio-core. The wavelet blocks
> that were in gnuradio-core, which depend on the GNU Scientific Library

I would make a similar argument for the FFTW dependency on
gnuradio-core. I'm not volunteering, but that would bring gnuradio-core
down to gruel, boost, and cppunit as dependencies. Even cppunit could be
replaced with boost unit test.

> - Preparation to to merge the 'next' branch back in to 'master', after
> the 3.5.3 release.  The 'next' branch is the long-running development
> branch where we implement things that are either somewhat unstable, or
> more often, make changes to the API such that user code might break.

There was this idea of loadable modules for gr-audio. That way one could
build gr-audio for all the audio development environments, but when
deploying, you only install the modules that the OS has runtime support
for. Think deb packaging, where each module becomes a package with
specific requirements like libjack, libalsa... Would this merge event be
a good time to implement something like that?

Also, for those of us who are interested in gnuradio's PMT library:

1) Would this be a good time to fix the tag/PMT mutability issue? This
would prevent multiple downstream blocks from being able to manipulate a
shared resource, but it is a slight API change for the tags:

2) I would love to see the concept of tag/PMT based message passing make
it into the scheduler. The basic idea is to pass tags (without samples
associated) between blocks as a form of out-of-band
communication/control-plane. Here is here squashed into a single
changeset: https://github.com/guruofquality/gnuradio/tree/msg_passing

3) I would also like to purpose some extensions to the PMT library to
make PMTs more intelligent about memory management and allocation
overhead. Also, the work is squashed into a single changeset:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]