On 06/14/2013 07:41 AM, Yogesh Dahiya wrote: > Am i getting this right > With gr.block, each block has bunch of stream ports (vector<vector> > ins,vector<vector> outs) and some message port(which we use to specify > earlier in signature and there numbering use to start after stream ports ) > > With gras.block, each block has bunch of ports with bulk_data buffer and > message queue(which will be posted msg from upstream). So when I am taking > len(ins[0]) its the length of bulk_data buffer(which buffering stream data > i guess) so its returning 0. >
Yes thats correct. You see, in the old grextras architecture, the messages support was sort of hacked in. It worked, but it always felt like it was separate. With GRAS, a port is more generalized, it can have any type of data. What type data is available from a port is a question of how the port is used. I have been calling this "port duck-typing", like the duck-typing used in some programming languages. This notion is particularly powerful because you can make blocks which are totally agnostic about the port's type. For example these serialization blocks dont care what type a port is, messages, buffers, tags, you just give them ports and they can serialize/deserialize: https://github.com/guruofquality/grextras/wiki/Blocks#wiki-de-serialization-io-blocks > Some more doubts > 1.when we take length of output buffer m i asking length of output buffer > available for use (so i don't overwrite previous produced data). Yes, all of the length is available for you use > 2. tags are messages(associated with particular bulk_data) so are they > posted in message queue.(which must be different from actual message queue) Thats correct. There is actually a separate queue for tags, buffers, and async messages. > 3.when we are calling produce we are basically posting buffer data > downstream and when we consume we free up the input buffer > Thats correct. -josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio