Welcome everyone, this is your host Nikhil Maan aka Sc0rpi0n101 and this time we will be talking about the second evaluation for GSoC. The main objective of the week was to get the Fortran parser ready.
The Fortran Parser
The Fortran parser is finally complete after shifting to using SymPy’s codegen AST. It can now parser all the stuff that the parser could do before shifting. The assignment and binary operations transformations have also been implemented. All the files have been documented and revised, examples and doctests have been added to help new users. Appropriate tests have also been prepared to cover all the conversions of the parser. The implementations for numbers are also ready, but commented out and can be used as soon as numbers are represented in the ASR. The last thing left to do before merging the Pull Request to get the tests passing through Travis CI.
Travis and the Tests
Travis is currently not passing the doctests as lfortran does not seem to be imported correctly in the sphinx tests. The rest of the tests are passing successfully both on Travis and on my local machine.
The tests were initially written using regex to compare the Expression statements. But, regex tests are found to be fragile and hard to write and have to be dependent on how they are printed. So, the tests now consist of testing if the expressions belong to the right classes and comparing the whole expressions with the desired results. The expression comparison is more robust and can be used to test all the aspects of the expression without being dependent on how the expressions are printed.
LFortran
LFortran has been packaged for the conda-forge and can be installed on Travis successfully as a conda package. The current version of LFortran(v 0.1.15) with all its present features can be installed on any system using Anaconda.
While working with Functions in LFortran, I also encountered a new bug. The Function Definitions ignore the return type of the function and the return variable. The return variable defaults to integer in every case. It was reported at the LFortran issue tracker. You can check out the issue at #138
Evaluation!!!
The primary goal of the project before the second evaluation was to complete the Fortran parser and get it ready to be merged in SymPy’s master repository. As apparent from the above discussion, the parser has been completed including the documentation, tests, and examples for users; and LFortran has been packaged for conda-forge which completes all the requirements for the pull request being merge-ready.
All that’s left are a few Travis errors, including importing error that can be fixed soon and the pull request can be merged. So, completing all the requirements of the project, I have successfully passed the second evaluation.
The meeting
The weekly meeting took place at the regular time this weekend and the progress for the week and Phase 2 was discussed. The Fortran Parser pull request was reviewed and the changes and the tests were discussed. The regex tests were determined to be not efficient and comparing expressions was decided as the better alternative. The current progress of the lfortran packaging and Travis tests were also discussed along with SymPy’s fcode printers and how it prints the expressions and statements. Then, the next week’s plan was discussed. Here’s the summary of the next week’s plan:
- Fix the problems with Travis and merge the Fortran Parser
- Repeat the same for the C parser and get that completed and merged.
- After both the PRs are merged, focus on extending the parser features.
What Now
Now, the first step is to fix the errors in Travis and get the pull request finally merged. Then, repeat the same for the C parser. Revise the documentation for the parser, write some new examples, examine the previous tests, and create some new tests. The code for the parser can also be refactored to reduce redundant code and improve the efficiency of the parser. Then, get the C parser pull request merged too.
After both the parsers are successfully merged into SymPy, the next step would be to expand on the features available to the parsers. It would also include getting some feedback from the users and improving the parsers and their API based on how the users feel it would be more comfortable to use.
