-
-
Save haakov/fb381bf3de1dd6a02b697c9d92d7dae5 to your computer and use it in GitHub Desktop.
id: blocks_multiply_const_vxx | |
label: Multiply Const | |
parameters: | |
- id: type | |
label: IO Type | |
dtype: enum | |
options: [complex, float, int, short] | |
option_attributes: | |
const_type: [complex_vector, real_vector, int_vector, int_vector] | |
fcn: [cc, ff, ii, ss] | |
hide: part | |
- id: const | |
label: Constant | |
dtype: ${ type.const_type } | |
default: '0' | |
- id: vlen | |
label: Vec Length | |
dtype: int | |
default: '1' | |
hide: ${ 'part' if vlen == 1 else 'none' } | |
inputs: | |
- domain: stream | |
dtype: ${ type } | |
vlen: ${ vlen } | |
outputs: | |
- domain: stream | |
dtype: ${ type } | |
vlen: ${ vlen } | |
asserts: | |
- ${ (len(const) == vlen) if str(const).strip().startswith('[') else (vlen == 1) } | |
- ${ vlen > 0 } | |
templates: | |
imports: from gnuradio import blocks | |
make: blocks.multiply_const_v${type.fcn}(${ str(const) if str(const).strip().startswith('[') else ('[' + str(const) + ']') }) | |
callbacks: | |
- set_k(${const}) | |
file_format: 1 |
Some observations:
I see a difference between 3.7 and 3.8
If I open the property window of multiply const and move my mouse to the constant value I get displayed 'Type real vector ' for float in 3.7 and raw value in 3.8. No idea why.
If I enter the constant value ( Im working with floats ) followed by a trailing , the expression (len(const) == vlen) evaluates to true,
but the generated code is not correct.
in 3.7 it's
self.blocks_multiply_const_vxx_0 = blocks.multiply_const_vff((0.5,)) -- correct
while in 3.8
self.blocks_multiply_const_vxx_0 = blocks.multiply_const_vff(0.5,) -- not correct
In 3.7 I may enter the trailing , but I must not. Shouldn't the constant type be real vector instead of raw in 3.8 ?
I think, the type substitution for the constant dtype entry does not work. If I replace the dtype of const by real_vector the type of constant is now displayed as real_vector and the assertion does not fail any longer.
So why does the type of the constant keep raw and does not change depending on the selected type ?
So far as I can see the dtype entry in the constans parameter recognizes ${type} but not ${type.const_type}. ${type.const_type} seems to evaluate to '' !
Hm, looks like you're right!
Okay so I've found the problem.
This namespace property ignores the option_attributes. This is why type
is recognized but not type.const_type
.
Pull request created: gnuradio/gnuradio#1925
Not too happy about doing the whole
('[' + str(const) + ']')
thing either, but I kept ending up with['0']
in the generated code otherwise