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 (jcor...@gnuradio.org) 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 <marcus.muel...@ettus.com> 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 > > > > _______________________________________________ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
