Re: [Discuss-gnuradio] Costas parameter in DPSK2 grc block not in .py?

[Marcus D. Leech]

On 10/19/2010 05:45 PM, Josh Blum wrote:
>
>> There's an argument to be made for this. It'll go into the thinking
>> about the refactoring of the code.
>>
>
> blks2impl must be burned
>
> I think the structure in the gr-noaa directory is a good example of
> how to organize a set of related blocks and applications.
>
>> There is also the concept of using SWIG's XML output for the GRC
>> files. I've only played around a bit with them, but it's something to
>> look into if you haven't already. It looks like it captures _most_ of
>> the information about the blocks that is exposed in the GRC xml files.
>> It's fairly expressive output, so we'd have to see if it actually
>> covers everything necessary for GRC to use with updated parsing.
>>
>> Have you already looked at, and dismissed, this, Josh?
>>
>
> I have not looked at nor have I dismissed the possibility. There are
> certain visually appealing things you can do like hiding parameters
> that dont matter when another parameter is set, or grouping two
> similar blocks that have different outputs. I believe that there is no
> general abstraction on how to do this and that generated xml files
> will be somewhat lacking. That said, maybe generating the xml files
> might be useful for enough of the blocks that its worth figuring out.
> Maybe we can have a middle ground and find a way to generate the xml
> and leave a place to get extra block specific information into the
> generator.
>
> Basically, I will take a look at the SWIG XML when I get the chance.
>
> -Josh
>
>
I think having the XML generated automatically (mostly) from the
underlying SWIG/C++ is a very nifty idea.  But I think I agree with Josh
that
  some of the semantics are going to need to be "grafted in"
post-facto.  Unless we can come up with some clever way of deriving those
  semantics from the underlying C++ code.

But moving towards a single, "de facto" location for all of this, and
having the rest be derived by an automated build-time process would be
sweet.

-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org