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
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.
Best regards,
Håkon Vågsether
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio