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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
