Invalid default values resulting from parsing

[ncorgan]

More TBD

• FFT: Window parameter needs std::vector<float>, default value is "window.blackmanharris(1024)"
• Blocks needing boost::shared_ptr as parameter
  • fec_encoder
  • fec_decoder
  • fec_async_encoder
  • fec_async_decoder
  • protocol_formatter_async
  • protocol_parser
  • packet_sink
  • packet_headerparser_b
• Blocks with Rate parameter set to rate (no quotes, not a string)
  • audio_sink
  • audio_source
  • wavfile_sink
  • freq_xlating_fir_filter
  • dvb2_pilot_generator_cc
  • dvbt2_paprtr_cc
  • file_meta_sink
  • tagged_file_sink
  • throttle
  • header_payload_demux
• Blocks with empty vlen parameter
  • and
  • or
  • xor
  • not
• multiply_const: Constant parameter takes in std::vector, populates with single number
• quadrature_demod_cf: gain parameter populated with math using usual GRC variables
• burst_shaper: Window Taps populated with "([])", needs quotes removed to be valid

[guruofquality]

Blocks needing boost::shared_ptr as parameter

Any chance the recent fec factory helps with this. I cant think of a way to do this other than give it a string in the parameter box which can be converted to a fec object.

Blocks with Rate parameter set to rate (no quotes, not a string)

I guess rates not defined until someone creates a global variable "rate". Not sure, it mimics GRC here in that someone wanted those blocks to use the variable and not have a default number.

[ncorgan]

Yup, the FEC factory fix was a direct result of this. I guess I forgot to mention that in the commit log. There are a couple other things like this, but the FEC one was the easiest to knock out.

…

On Feb 25, 2020, at 21:09, Josh Blum ***@***.***> wrote:  Blocks needing boost::shared_ptr as parameter Any chance the recent fec factory helps with this. I cant think of a way to do this other than give it a string in the parameter box which can be converted to a fec object. Blocks with Rate parameter set to rate (no quotes, not a string) I guess rates not defined until someone creates a global variable "rate". Not sure, it mimics GRC here in that someone wanted those blocks to use the variable and not have a default number. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ncorgan]

This may be fixed with the shift to 3.8, as parsing is moving over from the old GRC XML files to BlockTool output. At the very least, the behavior will be changed.