On Wed, Nov 9, 2011 at 5:25 PM, Josh Blum <j...@ettus.com> wrote: > I just added a gr_basic_add_const and gr_basic_multiply_const. Nick > added the volk (and orc) implementations for the float32 and complex > float32 implementations of the multiplier. > > > > > So I like everything about this but the name. We could stuff all of this > > under the "gnuradio.gr" namespace in Python, or we could name this > > "gr-math." > > > > Actually, while I was typing this, I'm thinking we rename the directory > to > > be "gr-blocks" but put them under the "gnuradio.gr" namespace. I'm > > > Trying to avoid math so from gnuradio import math doesnt interfere with > python's math import. Thats unfortunate, but I think this will be nicer > with the python namespace changes you mentioned. > > #example import: > from gnuradio import gr > gr.filter.fir_interp(...) > gr.math.add(...) > gr.digital.costas_loop(...) > > Was that the goal? I think we can make this happen without too much trouble
Yeah, this should be easy. But I think most people are pretty used to "from gnuradio import something", so you're right about the potential problems of a collision between gr.math and math. The goal? To allow for easy development and control over properly segmented groups of blocks without driving the users crazy by constantly changing or adding new groups. That's one reason why I think stuffing everything in your gr-basic into the gr namespace, so people would still have the familiar "from gnuradio import gr" way of getting to most of the core blocks. > expecting that since you've used different names for the blocks because of > > the data-type handling that they won't collide with what's in > guradio-core > > right now. > > > > So, my thoughts were: make new blocks that replicate the functionality > in gr-core like filters, adders, etc. We dont delete the old blocks, so > the API doesn't change. But if you want the performance improvement, you > use the new blocks. > Agreed. Eventually, we'd want to get rid of the old blocks (reduce cruft, etc). Of course, that'd be a _huge_ api change since these are blocks used frequently for many tasks. > Hopefully with these new blocks, we use volk where applicable, use new > naming convention to make it easier to fit alternative data types, and > avoid generation when possible. > No disagreement there. > Eventually, gnuradio-core becomes nothing but the block framework and > runtime. gr-filter takes the filter implementations and gr-<???> takes > the very basic blocks like simple math operators, type conversions, and > stream conversions. > > Hows that sound? > > -Josh > I'd say that gnuradio-core would also contain a few blocks that are really only used for development/testing purposes (gr_nop, gr_annotator, etc.). But I otherwise agree. I'm still advocating for gr-basic to become gr-blocks as the place for all of the generic blocks to go into, but they would be installed in gr. Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
