This does appear to be broken for embedded python blocks. GRC assumes the list style of signature. I'll put in an issue describing this.
On Thu, Feb 4, 2021 at 3:15 PM Tim Huggins <huggins.timo...@yahoo.com> wrote: > I am using 3.8.2 and was trying to quickly test it in an embedded python > block (the block was displaying that error). If I get a chance I'll compare > with a full OOT block. > > On Thursday, February 4, 2021, 3:06:58 PM EST, Jeff Long < > willco...@gmail.com> wrote: > > > The line > > in_sig = gr.io_signature(3,3, gr.sizeof_gr_complex) > > just worked for me on both 3.8 and master. Are you using an older version? > > On Thu, Feb 4, 2021 at 2:48 PM Tim Huggins <huggins.timo...@yahoo.com> > wrote: > > I do not believe that you want to encapsulate the call with [ ], even so > there may be an issue with that command. I am unsure what the issue is but > when I make the call: > > in_sig = gr.io_signature(3,3, gr.sizeof_gr_complex) > > The error message is: Can't create an instance of your block: object of > type 'io_signature_sptr' has no len() > > Instead try this: > > in_sig = 3*[np.complex64], > > Where 3 will end up being your variable for number of inputs. > > Tim > > On Thursday, February 4, 2021, 1:23:35 PM EST, George Edwards < > gedwards....@gmail.com> wrote: > > > Hi Tim, > > Thanks for your suggestion! I just tried it and it does not work. The > Python OOT def __init__(self, ....) method requires that one fills in in_sig > = xxx and out_sig = xxx. > I tried your suggestion above for variable number of inputs and set: > in_sig = [gr.io_signature(1, -1, gr.sizeof_gr_complex)] > > and I leave the yml file as is when I had the static number of inputs (in_sig > = [complex64, complex64, complex64]) shown below > inputs: > - domain: stream > dtype: complex > multiplicity: '3' > It gives a TypeError: data type not understood > I tried a bunch of combinations based on the above change you suggested, > but GRC kept failing when I tried to run it.! > > Thanks again for your suggestion! > Regards, > George > > > > On Thu, Feb 4, 2021 at 8:01 AM Tim Huggins <huggins.timo...@yahoo.com> > wrote: > > George, > > I would recommend taking a look at some of the existing blocks that have > variable inputs to accomplish this (especially for the YML file). A YML > example for a variable input can be found here: > > > https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_multiply_xx.block.yml > > I haven't run a test using this line in a python block yet, but two > different examples are shown below that I believe should work (or should > with some minor tweaks). The first doesn't limit the number of inputs while > the second one does (at 8). > > gr.io_signature(1, -1, gr.sizeof_gr_complex)) > > gr.io_signature(1, 8, gr.sizeof_float) > > I don't know if there is a complete python reference for GNURadio 3.8, but > this should be helpful to get you close as well: > https://www.gnuradio.org/doc/sphinx-v3.7.9.2/ > > Good luck, > > Tim > > On Thursday, February 4, 2021, 12:01:07 AM EST, George Edwards < > gedwards....@gmail.com> wrote: > > > Hi Gavin, > > Thanks for the information! > > Does this mean that if I wanted 3 inputs and 5 outputs and all floating > point values, then inside the Python code, I simply set > in_sig = [numpy.float32] > out_sign = [numpy.float32] > > And, in the yml file I set: > inputs: > - domain: stream > dtype: float > multiplicity: '3' > > outputs: > - domain: stream > dtype: float > multiplicity: '5' > > Would this be correct? > Thanks again for your help! > > Regards, > George > > On Wed, Feb 3, 2021 at 5:26 PM Gavin Jacobs <apriljunk...@hotmail.com> > wrote: > > In 3.7, you would use the <nports> tag, but in 3.8 the trick to setting > multiple ins/outs in the YML file, is the keyword "multiplicity". You can > see the details of how to configure here: > https://wiki.gnuradio.org/index.php/YAML_GRC > > YAML GRC - GNU Radio <https://wiki.gnuradio.org/index.php/YAML_GRC> > Starting with release 3.8, YAML replaces XML as the file format for GNU > Radio Companion. This is triggered by switching from Cheetah to Mako as the > templating engine, since Cheetah does not support Python 3. > wiki.gnuradio.org > >
