Week 12: Add API support to the GUI

Just the final week things! ūüė¶

As planned for Week 12, an API support has been added to the GUI of the gr_modtool. The work on the GUI is in progress but it can still be used an alternative for the CLI commands since the API has been integrated. The work on the GUI can be followed in my GitHub repository, modtool_gui.

The push-button, run, on every command’s tab firstly calls the functional definition for the setup of the common parameters¬†like directory, --skip-lib, scm-mode, and then instantiate an object of the corresponding API class with these parameters. After that, the class members in the __init__¬†take their values from the user input and the method run¬†of the particular class is executed.

I have also tried to enhance the code quality by splitting the QtDesigner generated code into several functional definitions.

Next Task

This might be the final blog post on this website but there will be another blog post with the condensed work of the entire GSoC period soon on the GNU Radio website.

I would still like to contribute to the gr-modtool, the magical tool that enhanced my knowledge of python multiple folds. I will try to complete the GUI with decent code quality as soon as possible. I will also try my level best to sort out the issues that come up with the code I produced, or modtool in general.

Acknowledgement

I knew very little about Python and the idiosyncrasies with its versions when I started off with the programme but with the immense support of my mentors, Sebastian Koslowski and Nicolas Cuervo, I was able to cope-up with the project demands. I learnt about several awesome python libraries and the methodology of writing good quality python code. I would like to thank my mentors for such high degree of support throughout the GSoC programme.

I would also like to thank¬†Marcus M√ľller for reviewing the PRs and briefing me about the first issue that I can work on.¬†I would also like to thank Martin Braun for reviewing the PRs as well as the GSoC proposal. I would also like to thank Andrej Rode for helping me with the branch rebase on GitHub and providing me with the rights for editing the GNU Radio wiki. I would also like to thank¬†H√•kon V√•gsether for helping me with the XML to YAML conversion. I would also like to thank Kartik Patel for suggesting me to work with the GNU Radio Community this summer. I would also like to thank Felix Wunsch for providing me the overall GSoC updates.

I would like to thank Ben Hilburn and the GNU Radio Community for inviting me to the GNU Radio Conference 2018. A special vote of thanks to Ben Hilburn for booking my flight tickets, Derek Kozel for booking the hotel for my stay, and Neel Pandeya for his support during the VISA application.

Thank You!

 

 

Advertisements

Week 11: Updated GUI

GUI begins!

As planned for Week 11, I have created a GUI for the modtool‚Äč.¬† Currently, the GUI has not been integrated with the API. The design for GUI has been updated to make it more user interactive. There is a proper space for common parameters‚Äč, logger output‚Äč, and auto-completion candidates.

Here are some of the images of the modtool GUI:

Screenshot from 2018-07-28 22-36-19.png

Screenshot from 2018-07-28 22-36-35.png

Screenshot from 2018-07-28 22-36-08.png

Any kind of suggestion or feedback will be highly helpful!


Tasks for Week 12

  1. Add an API support to the modtool GUI.
  2. Work on logger output and candidates auto-completion for the GUI.
  3. Bug fixes of the PR, if any.

The code for the GUI can be followed in my repository modtool_gui.

Week 10: Mock GUI

As planned for Week 10, I have created a mock GUI for the modtool. I have also added the commits from the branch yaml, which contained the cli and core modules for the XML to YAML conversion, into the branch¬†swapnil_next‚Äč. I have also condensed all the remaining work of the other PRs into the main PR.

I have designed the GUI for the modtool using the QtDesigner. In the current design, the screen is split into 3 vboxes. The first contains the commands for the modtool, the second contains the user_input window while the third contains the candidates for auto-completion, if any. The second vbox is totally dependent on the first, while the third  vbox is totally dependent on the input field of the second vbox. There is a space for logger output in the second vbox. The GUI looks like:-

Screenshot from 2018-07-20 19-25-19.png

Note: Block Candidates is just for mock display.

Now, the branch swapnil_next contains the most recent version of modtool including the option for XML to YAML conversion.


Tasks for Week 11

  1. Complete the GUI with basic features.
  2. Bug fixes of the PR, if any.

I have updated the GitHub project and the code can be followed in the forked repository swapnil_next branch.

Week 9: XML to YAML Converter

As planned for Week 9, an XML to YAML generator has been added to the modtool. A new CLI command, update, has been added to the existing modtool commands that serves the purpose of conversion of XML scripts to YAML scripts. The functionality can also be achieved through the API class, ModToolUpdate. I would like to thank my mentors and Håkon Vågsether for helping me throughout.

The feature of XML to YAML conversion of grc scripts has been achieved by using the existing grc converter. The conversion utilises the functional definition load_block_xml of the class Converter of the grc converter.

The command update¬†also comes with a special option --all¬†that converts all the existing XML scripts to YAML. There is also a feature for auto-completion of candidates for conversion. The list of candidates is generated by traversing the grc¬†directory of the module. There are proper checks on the existence of¬†blockname¬†entered by the user. The blockname¬†is a mandatory argument unless --all¬†option is specified (there are no checks on the blockname in this particular case). The mandatory changes in the CMakeLists.txt¬†is also handled by the core¬†ModTool class ModToolUpdate‚Äč with proper warnings on more than 1 or 0 substitutions.

In the meantime, I also worked on learning PyQt5 for the GUI¬†of the modtool. I learned about the various QtWidgets‚Äč, layouts, setting up connections, creating menu bar, etc.¬† I also worked on the basic GUI design on paper.


Tasks for Week 10

  1. Work on the GUI of the ModTool.
  2. Bug fixes of the PR, if any.

I have updated the GitHub project and the code can be followed in the forked repository yaml branch.

Week 8: Add YAML Generator

As planned for Week 8, YAML Generator has been added to the ModTool and the basic grc_xml template has been replaced with the grc_yaml template.

Since, the branch next¬†contains YAML¬†only, the grc_xml_generator¬†has been replaced with a grc_yaml_generator. The CLI command has been changed from makexml¬†to makeyaml. Similarly, the API or the core class has been changed from ModToolMakeXML¬†to ModToolMakeYAML‚Äč. The python library pyyaml¬†has been used to dump the dictionary into YAML data‚Äč. The generated YAML scripts¬†are in strict correspondence to the existing YAML files¬†in the next.

Since it is not possible to manage the order of entries using the traditional dictionary which stores the entries in the sorted manner according to the keys‚Äč, I have used an OrderedDict¬†to manage the dictionary entries. For implementing an OrderedDict¬†with pyyaml, I have added a special representer¬†to the traditional Dumper. The data_flow_style¬†has been kept as False‚Äč.

The template grc_xml has been replaced with the template grc_yml which gives the brief description of the YAML file that needs to be added for grc support.

Moreover, I have slightly modified the CMakeLists and the directory structure. The modtool configuration file has been moved to the base modtool folder. The CMakeLists.txt of the base modtool folder adds the sub_directories for the installation. The README.modtool has also been updated.

I have also replaced all possible %s, %d with str.format() in the python modules of the core as well as tools.

The entire work for gr_modtool overhaul has been rebased to the branch next from  the branch python3 and the pull request with current work status has been made.


Tasks for Week 9

  1. Bug fixes of the PR (if any).
  2. Create an XML to YAML converter (CLI option as well as API support).
  3. Start working on the GUI.

I have updated the GitHub project and the code can be followed in the forked repository swapnil_next branch.

Week 7: Logger Colors and Pylint Tests

As planned for week 7, the logger has been updated with ANSI colors, the modtool tests have been updated with Pylint tests (currently errors only) and the issue with the rename module has been solved (PR has been submitted).

ModTool tests for the API classes ModToolNewModule and ModToolAdd have been updated with the Pylint tests. They use the function py_run of the module epylint of the pylint package. To silence the configuration file alert as well as silently run the tests, the pylint_stderr is stored but not printed. For verbose testing, it can also be printed (not aware of the use case).  Currently, only the error messages of the pylint_stdout are printed as stdout for testing the ModTool generated scripts. The only issue is that the Pylint tests usually take a lot of time.

The logger¬†gnuradio.modtool is now equipped with ANSI colors. The work has been done by overriding the StreamHandler¬†class method emit. Even the input statements have ANSI colors. Now, there is a separate ModToolException¬†for the CLI modules which raises the exception in red‚Äč color. The redundancy in similar styling of input has been sorted with a separate function cli_input¬†in the base CLI module. The colors are emitted using click.style¬†which comes with an optional dependency colorama. So, no colors appear if colorama is not installed.

The issue regarding the renaming of the regex pattern instead of the entire blockname has been sorted by generating a list of block candidates for renaming. A special feature of alternative suggestions¬†has been added so that the user faces minimum difficulty. The pull request also includes the py3k compatible Sequence Completion of the¬†blocknames¬†for the modules rename, rm‚Äč, makexml¬†and disable.

I have also made a pull request regarding the lint fixes in the generated python scripts and a pull request for relative import of modules in python scripts. All the PRs have been moved to the next.

In the meantime, I also read about YAML serialization‚Äč and also went through some of the blocks in the next¬†for clear understanding.


Tasks for Week 8

  1. Add a YAML generator as a CLI command.
  2. Bug fixes, if any.

I have updated the GitHub project and the code can be followed in the forked repository core_cli branch.

Week 6: Modify API, Add logger

As planned for Week 6, the modtool tests have been added in-tree and all the print statements have been replaced by the logger. A major change to the API structure has also been made. All the raw open() statements have been replaced by with open(filename) as f.  The CLI modules have been modified to enhance the developer readability as well as the user experience.

API

Now, the ModTool API does not have any mandatory positional arguments for any of the in-tree modules. In the function __init__, the parameters are assigned the values passed by the user without any validation. The user has the liberty to pass the values later. The validation of values occur when the run method of a class is called. The run method calls the validate  method followed by the assign method (if required) of the particular class. The validate method initially calls the _validate method of the base module, except for the classes ModToolInfo and ModToolNewModule, for the validation of common parameters and then validates the parameters for the particular modules. The _assign method of the base module and the assign method of other modules assign the values of arguments based on the user input (eg:- fullblockname). The _assign method also calls required methods of the base module. For the CLI commands, the methods _validate and _assign are called from the  __init__ function itself.

The ModTool tests have also been changed as per the above-mentioned changes with tests on API calls via list-unpacking as well as object instantiation. They have been pushed in-tree.

A global logger gnuradio.modtool¬†has been configured in the base module. All the loggers in the core¬†as well as tools¬†are created based on their respective module’s name. Since all the modules are packaged in the package gnuradio.modtool‚Äč, they inherit the configuration of the logger in the base module. Currently, the logger level has been set to info¬†for the CLI commands whereas error¬†for the API calls.

The CLI modules have been changed to facilitate the developer experience while changing a particular portion of the CLI interface. Moreover, until the value of block name or the module name is not specified, the user is prompted to fill its value which is followed by the usual regex check.

I have updated the pull request for the grc_xml_generator.


Tasks for Week 7

  1. Run pylint against the generated modules. This involves fixing of current pylint issues in the templates.
  2. Add ANSI colors to the logger as well as the CLI. This involves configuring the logger such that it works differently for the commands through different interfaces.
  3. Fix the issue with the core rename module.
  4. Read for adding a YAML generator in-tree plugin.

I have updated the GitHub project and the code is available at the forked repository core_cli branch.