On 03/19/2018 12:03 PM, swapnil negi wrote: > Hello everyone! > I have uploaded my proposal to the GitHub pages. So, please review and > provide me suggestions to improve the same. > Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf > Code Link: https://github.com/swap-nil7/GSoC-Proposal
Swapnil, this is a great proposal. There's a couple of typos and areas where the optics can be improved, for example, the code snippets you provide as examples are not all Python 3k compliant, and don't follow PEP8 or GNU Radio coding guidelines. But overall, this is a really good proposal. Well bound, useful, it addresses a tool we all use a lot. As for Nicolas' comments: > And I agree with this timeline, as it puts core focus on the > architectural overhaul without disregarding other details aside. > > * If I understand correctly, your first task to tackle is the > Py3k compatibility, which is great. This is definitely > something that needs to be done, as there is a continuous > effort on making the whole GNURadio Python3 compatible. But > Python2 is not EOL for little less than 2 years more, so > continuous compatibility is something that has to be kept in > mind. Let's take your proposed code for raiseException, > whose implementation won't work on Python2. There are ways > to ensure compatibility (using wrappers from 'six' for > example, which adds a dependency - which can be discussed) > I, however, see that the Python3 branch from GNU Radio > already implements the syntax that you are proposing, so I > might being just too picky on this. I expect comments on the > matter from the list. I very much agree with this. It'll need to support Py2k and Py3k (and yeah, that's annoying, but for tools like this is not too much of a hassle). > * I see that you have put efforts in contributing already to > the project by fixing some issues on the tool, and there is > hardly a better way to get used to it and contribute to the > project. No comment here apart from saying that we do > appreciate you took that path as it puts you into context > and improves the project. Win-Win! Agree very much. I have a couple of my own comments: - This may be obvious to you, but the way you've structured your timeline means you can probably submit PRs while you're coding, and the review/merge cycle can be pipelined with the development. I would encourage you to write something to the effect, e.g, you could make it a goal that the Py3k compat is *merged* into master before the midterms. - One of the many things that modtool sucks at (<= I'm allowed to say that :D ) is that it has no automated checking. At the very least, we could run PyLint against it (maybe as part of 'make check'...although that means PyLint becomes a build-time dependency... hmmm....) and then BuildBot would pick it up too. Even better would be full unit testing, although I'm not quite sure how that would work. I guess you could run newmod, add, remove in that sequence and make sure it doesn't fail. More advanced would be to check the generated code for validity, but I really don't have a good suggestion on how to do that. - The plugin architecture is *great*. Something else that modtool is missing is that it only has the CLI, and no API. Maybe you can kill two birds with one stone here: It would be nice if modtool was not only controllable from the command line, but would also be scriptable from other Python scripts. Then you could build Eclipse plugins around modtool, and stuff like that. - You mention a UI in the timeline, but not in the text (or did I miss that). Are you talking about a *graphical* user interface? Or the CLI? Other than that, this is a very good proposal. -- Martin _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
