Hi Sebastian,
(Håkon, this is half-related to your proposal; there's questions arising
from this, but I think I'd like to raise them later, if at all, after
Sebastian has enlightened me :) )
you're touching a very delicate subject here: I personally think that
GRC variables should have been for instantiation-time variability only,
but through the fact that they are actually Python variables, we've
enabled (which is a great thing) people to use them as dynamic things at
run time. (think: changing the gain using a GUI slider that calls the
generated variable setter, rather than e.g. sending a PMT message).
As far as I can tell, that cannot really work out in C++, unless we
really come up with automatic wrapping of block methods with something
like a message passing interface. We already have that message passing,
we don't have the C++ method-to-message-handler wrapping (which somehow
reminds me of a feature PR that I made quite a while ago...).
But if we demand that we can use variables at runtime, we would first
have to implement that inside the GR runtime – basically, the
servicification that Johnathan is dreaming of.+
So, we could only do this at instantiation, or, to be honest, at code
creation time – in which case a simple "eval()" might be the best option
(as little as I like that).
But that's really a rather personal, maybe not very well-backed view on
this. I'd love to hear your opinion on that; I'm biased, I'd rather lose
the ability to use raw Python in block parameters and convert the GRC
variable concept to "automatically generated subscribers and
publishers", but I know that would be a complete paradigm change, and
that's what I don't like about my idea.
Cheers,
Marcus
On 31.03.2017 16:32, Koslowski, Sebastian (CEL) wrote:
> Dear Håkon,
>
> I am very excited to see interest in this topic! A few additional
> comments:
>
> - Any new templating should be done using Mako. The new YAML format
> Martin mentioned roughly looks like this:
> """
> id: blocks_add_const_vxx
> label: Add 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:
> - dtype: ${ type }
> vlen: ${ vlen }
>
> outputs:
> - dtype: ${ type }
> vlen: ${ vlen }
>
> templates:
> imports: from gnuradio import blocks
> make: blocks.add_const_v${type.fcn}(${const})
> callbacks:
> - set_k(${const})
> """
>
> C++ specific templates could be added under "cpp_templates" or sth.
> The main part of your work would be to implement a Generator subclass.
> You maybe want to checkout my latest dev version to use as a starting
> point [0]
>
> Another issue is how to deal with parameter values:
> Say, I have a variable with "np.pi" as value. Or specify some filter
> coeffs using a list [1, 1, 1, 1,...]. Or so some calculation "2 ** 4 + 1".
> Those usually end up in the generated code somewhere. For C++ that
> would fail...
> I suggest, that at least some simple expressions should be transpiled
> for the C++ code generation.
>
> The alternative, writing all parameter values in C++ code, would
> require a separate eval, validation, .... - basically a C++ version of
> GRC.
> I'd rather do everything in Python and get the C++ output as a bonus
> on top. This means that all blocks must still be available in Python -
> even if they are just in output C++. This way we can load and
> instantiate things like filter and constellation objects during design
> time (before you hit generate) and do validation with those.
>
> Sebastian
>
> [0]
> https://github.com/skoslowski/gnuradio/blob/df1e94831c05e3b8a25e5490f50ebf9e98795182/grc/core/generator/top_block.py
>
>
>
> On 03/31/2017 02:07 PM, Håkon Vågsether wrote:
>> Hi Marcus,
>>
>> thank you for your feedback.
>>
>> Also, would kind of had preferred to read "I've not used GNU
>> Radio much before, but I've played around with the LiveDVD (or
>> whatever you'd have done)" instead of reading "I've not used GNU
>> Radio before(at all)" and seeing you use pretty dated screenshots
>> from Josh's website instead of familiarizing yourself quickly, so
>> that you could leave us with the certainty that hey, we don't
>> have to teach you how to even start GRC ... not that I really
>> think this will be any trouble for you, but the ease of getting
>> started with GNU Radio, considering ready-made packages and the
>> bootable liveDVD and the guided tutorials make me wonder much
>> more why you didn't demonstrate you've played with GNU Radio before.
>>
>> Haha, I understand what you mean, and you're right! I naturally
>> wouldn't post my proposal draft for this project without knowing how
>> to even start GRC :) I have spent the last few weeks tinkering and
>> trying to gain some familiarity with GRC and its source. I could (and
>> should) have just taken a screenshot myself! I will include this in
>> my next draft.
>>
>> Big Plus is of course that you mention Cheetah, which proves
>> you've actually looked at the source code, I guess! This is
>> probably not going to hurt at this stage, but as Ben said, we're
>> currently replacing that with Mako (Cheetah is kinda Python2
>> only, and we're making things work with Py3).
>>
>> So, I hope this is not asking too much from your time right now
>> (you might be busy with exams for all I know about studying), but
>> I'd recommend you checkout the "next" branch of the gnuradio
>> repository, and try to build it with GRC enabled, and maybe add
>> some "change <filename/directory> to include <functionality>" to
>> your timeline after getting a rough idea of how code gen works there.
>>
>> Right! I had already built it from source, but I was on the master
>> branch. I've built the next branch now, and I've noticed the addition
>> of the GRCC compiler.py in the grc/ directory. I suppose the GSoC
>> project might as well include adding the build options as command
>> line arguments to this while I'm at it.
>>
>> I like your block diagram, it clarifies a few things, and
>> generally, I prefer reading a concise chart instead of a wall of
>> text, and I think that "writing down" the current code generation
>> process in terms of who-calls-what in Python in that shape would
>> be awesome, because that would allow you to make a second,
>> modified chart that shows what you'd like to add/change to that,
>> and would also be a great starting point for the (relatively
>> compact) documentation we'd like you to deliver in the end.
>>
>> I've made another diagram to visualise this, the dotted lined objects
>> are objects that I'm planning to implement. I've tried to leave out
>> the non-essential details to reduce complexity. As Ben pointed out
>> (if I understood him correctly), it might not be worthwhile to create
>> Makefiles directly from the templates, rather just leave it all to
>> CMake. This does make sense and will save me some work.
>>
>> call_diag.png
>> <https://drive.google.com/file/d/0B1ylsmzHTJ7Ab3p6YmN6TWxfTWs/view?usp=drive_web>
>>
>>
>> Best regards,
>> Håkon Vågsether
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
