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 > (jcor...@gnuradio.org <mailto: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 <mailto: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 >> >> <https://drive.google.com/file/d/0B1ylsmzHTJ7AQ01lNDYzMHZweVk/view?usp=drivesdk> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <https://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