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
>
>

Reply via email to