[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++
From: |
Martin Braun |
Subject: |
Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code |
Date: |
Wed, 29 Mar 2017 13:01:42 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
There's another thing: On 3.8, we'll be going to a different model of
writing GRC bindings (YAML-based). It's difficult to summarize the
changes, but basically, don't assume that we'll be using XML files forever.
-- M
On 03/29/2017 08:52 AM, Ben Hilburn wrote:
> Hi Håkon -
>
> Welcome! I'm really excited to see someone tackling C++ Code Generation.
> As Marcus said, it's something that people have been asked about for
> years, and it would be great to get it implemented. A few questions /
> suggestions on your proposal:
>
> * As Marcus mentioned, simple proposals are great, but I do think you
> need a bit more detail. Marcus covered this well in his e-mail, so I
> won't add anything to that point.
> * This is the sort of functionality that would be best upstreamed
> rather than existing in an OOT module. We should discuss how this
> process might work, as it requires a CLA to the FSF. If you aren't
> familiar with this, please e-mail me & Johnathan
> (address@hidden <mailto:address@hidden>) so that we can
> describe it further.
> * One of the big differences between generating Python and generating
> C++ is that a C++ flowgraph will need to be compiled before being
> executed. Laying out how you plan to handle that flow from GRC, I
> think, will be really important.
>
> Again, welcome, and I look forward to seeing where this work goes =)
>
> Cheers,
> Ben
>
> On Sun, Mar 26, 2017 at 10:48 AM, Marcus Müller
> <address@hidden <mailto:address@hidden>> wrote:
>
> Dear Håkon,
>
> cool! The C++ output option for GRC has been on many wishlists for a
> long long time.
>
> I do like the brevity of your proposal, however I miss a bit of you
> describing /how/ exactly you want to do things, and what to focus on
> in which order. We're well aware of this specific idea being
> displayed very generally in the ideas list; that has the purpose of
> letting you pick and discuss your focus very freely. If I understand
> your timeline properly, your order of things is
>
> 1. Add GUI elements to GRC to make it to connect functionality later
> 2. C++ code generator
> 3. Build system infrastructure
>
> Having the UI interface as first item seems like a positive approach
> to get to know the Python code of GRC a little better. I do think it
> kind of could wait until you'd actually be able to generate C++ code
> – that'd give you the chance to get a lot of feedback early and
> change directions of how you do things; GRC in it's current
> situation is relatively well split between the GUI and the (Python)
> code generation.
>
> I assume you've had a rough look at how Python generation in GRC
> works right now (block_name.xml files describe the GRC blocks,
> including the code that has to be called to instantiate an instance
> of the GNU Radio block class, and how these blocks are set up and
> connected is described in flow_graph.grc files; the actual python
> code is a template filled with the info from these).
>
> Now, in a first approach, this would "only" (as if) be a matter of
> adding new templates for the generated code, and new tags to the
> .xml files that describe which C++ code to call – but it would still
> be great to see you reflect a bit on whether you deem the same
> (Python-generation) templating infrastructure suitable for this use
> case (really, doesn't have to be in-depth – this is just a proposal)
> or whether you'd think there's things to change.
>
> Same goes for the "Makefile" generation. We really won't nail you
> down on what you propose now, but you giving a vision (maybe in a
> quick block diagram) of how the Makefile (or build system, in
> general – we use CMake in GNU Radio, and if you'd have another idea
> how to generate an executable from the C++ you generate, don't be
> shy, we can and will gently criticize if we found that necessary ;)
> ) will come together, and give maybe a list of infos on what info
> comes from where and ends up in the C++ header and the main source
> file and the Makefile, it'd give me a fuzzy warm feeling about you
> having a plan how to approach things.
>
> So: I like your project proposal, but I like it so much that I'd
> want to see more of a proposed idea here. I think both Felix and
> Sebastian don't want to mentor you as a "code monkey" – the whole
> project would very much value you as active critic and architect of
> "how things are done" in GRC and GNU Radio in general, so it's kind
> of important to us that you emphasize how your plan is more than
> what the Idea from the GSoC Ideas List already defines.
>
> Best regards,
>
> Marcus
>
> On 03/26/2017 02:20 PM, Håkon Vågsether wrote:
>> Hello!
>>
>> My name is Håkon Vågsether, and I am a first year MSc student in
>> Cybernetics and Robotics at NTNU's (Norwegian University of
>> Science and Technology, Trondheim). I am very interested in
>> participating in GSoC 2017 for GNU Radio and I have added a link
>> below to my proposal draft for the GRC C++ output idea for this
>> year's GSoC. I believe I have added everything that was required,
>> but I suppose I will have to be more specific with the
>> deliverables and milestones in the final proposal. I would love
>> some feedback, and if I have misinterpreted or neglected
>> something, please tell me so I can fix it for the final proposal!
>> :) I am really excited to get in touch with you all and
>> (hopefully) get started with this project.
>>
>> Thanks a lot!
>>
>> Best regards,
>> Håkon Vågsether
>>
>>
>> https://drive.google.com/file/d/0B1ylsmzHTJ7AQ01lNDYzMHZweVk/view?usp=drivesdk
>>
>> <https://drive.google.com/file/d/0B1ylsmzHTJ7AQ01lNDYzMHZweVk/view?usp=drivesdk>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden <mailto:address@hidden>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden <mailto:address@hidden>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
- [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code, Håkon Vågsether, 2017/03/26
- Message not available
- Message not available
- Message not available
- Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code, Håkon Vågsether, 2017/03/31
- Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code, Koslowski, Sebastian (CEL), 2017/03/31
- [Discuss-gnuradio] Dealing with GRC variables and GRC callbacks (was: GNU Radio Companion Extensions: Output C++ Code), Marcus Müller, 2017/03/31
- Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code, Martin Braun, 2017/03/31
Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code, Håkon Vågsether, 2017/03/29