“Software is like entropy: It is difficult to grasp, weighs nothing, and obeys the Second Law of Thermodynamics; i.e., it always increases.” — Norman Augustine
Welcome everyone, this is your host Nikhil Maan aka Sc0rpi0n101 and we will talk all about the Fortran Parser this week. I have passed the second evaluation and Fortran Parser pull request is complete.
The Week
This week began with me working on the C parser to finalize that. The Fortran Parser was passing all the tests except one. Then, I and the mentors focused on the Fortran parser and finishing the debugging before moving on to the C parser. So, the rest of the week was spent on debugging the Fortran parser and getting it to pass al the tests.
Fortran Parser
The Fortran Parser has finally been completed and the Pull Request passes all the tests. The sub-module fortran of SymPy’s parsing module contains the implementation for the Parser in SymPy. The module will only handle the beck-end operations of Expression conversions and will not have any part to play in the Application Program Interface(API).
The module consists of a Visitor Class ASR2PyVisitor which handles visiting the Abstract Syntax Representation(ASR) for the Fortran source code. The ASR is generated by LFortran and it’s API is used to extract the ASR and visit its nodes. The different nodes present are processed and converted into the respective nodes in SymPy’s Codegen AST. The nodes are stored in a list chronologically.
The list is then stored as a SymPy Expression object to be used in SymPy.
SymPy Expression
The SymPyExpression class is a part of the sym_expr module in SymPy’s Parsing module. It handles the API and all the interactions of the expressions present.
The class is initialized either by providing the source code and mode as attributes which are used to generate the expressions from the provided source code. The class can be initialized without any source code and an empty list of expressions is created. Expressions can also be generated using convert_to_expr. The expressions can be converted to different languages’ source code using the provided functions like convert_to_c, convert_to_python, and convert_to_fortran.
Travis Tests
Travis was set up for the parser and LFortran was packaged for conda-forge so that it could be installed in Travis. After completing the setup and installation, the build was passing most of the tests except one. The failing test was the sphinx test which was not able to identify SymPyExpression when lfortran was not installed. Multiple fixes were tried and the best solution was to use the decorator doctests_depend_on.
Then, after that test was fixed and started passing, another test started failing. The build report showed the source of the error unrelated to changes in the pull request. A few of the last commits were reverted and rewritten and the test started passing. The error just vanished in thin air, I couldn’t figure out why it occurred and what the source of error was.
The C Parser
Now that the Fortran Parser is completely ready to be merged, it’s time to finalize the C Parser pull request. I have been adding sym_expr to the C parser and modifying the parser to be compatible with SymPyExpression. I have also started adding some expression comparison tests for the parser.
The most important requirement right now is to get clang installed in Travis for the tests and revise the documentation.
The Meeting
The meeting took place at the regular time this week and the problems with the Fortran parser were discussed. The Travis builds and the tests were discussed. The tests that passed and the new error were discussed and different ways to fix the errors were also discussed. Most of the meeting was focused on finishing the work in progress which was the Fortran Parser, then shift the focus to the C parser.
