Skip to content

GSoC 2021 Project ideas

Jump to bottom Edit New page
Ondřej Čertík edited this page Mar 31, 2021 · 41 revisions

Introduction

Welcome to the Fortran-Lang ideas page for students applying for Google Summer of Code (GSoC). If you are student interested in applying for GSoC, see the Student instructions page for more information on how to apply.

The list here is based on priorities identified by Fortran-Lang contributors and should inform students as to the state and direction of each project. If you are interested in an idea on this page, please contact us on our Discourse to ask any questions and get the latest information about the project idea. Please read the existing discussion(s) in any linked issues.

The project ideas on this page are grouped by parent repository. Please familiarize yourself with each repository before exploring the ideas here.

Contacts for mentors: https://github.com/fortran-lang/fortran-lang.org/wiki/GSoC-2021-Mentors

Contents

Fortran Package Manager (fpm)

Local package registry

Fpm currently supports decentralized package dependencies whereby dependencies are specified without a central registry. A long-term goal for Fortran-Lang is to host a community-supported registry of fpm packages and for fpm to support interfacing with this and other registries to simplify dependency management.

This project idea aims to accomplish a major step towards a central package registry by implementing support in fpm for a locally hosted package registry. In particular, this project will entail:

  • Defining the manifest syntax to use dependencies from a registry
  • Implementing support for looking up and loading a (local) registry
  • Allowing fpm to manage a local registry by fetching it from a remote registry

Related issues:

  • fpm#321: Implement support for a local registry
  • fpm#35: Full package registry

See also:

Mentors: Laurence Kedward (@lkedward), Milan Curcic (@milancurcic)

Version constraint resolution

The current decentralized package system in fpm allows dependencies to be fetched via a git repository URL. As part of this, a git tag or commit can be given to require a specific version of a dependency. There is however no way of specifying version compatibility requirements (e.g. >= 1.0.0, <2.0.0) and no way to resolve such requirements across a dependency tree.

This project will involve:

  • Defining a manifest syntax for version compatibility matching
  • Implementing support in fpm for solving a set of version compatibility constraints

A possible approach would be to to interface with an existing satisfiability solver such as:

  • libsolv: interface via iso_c_binding as a separate fpm package

See also: existing options for version matching syntax:

Mentors: Brad Richardson (@everythingfunctional), Sebastian Ehlert (@awvwgk)

Handling compiler arguments

Fpm currently has limited support for specifying the command line arguments supplied to the compiler and linker. This is an important functionality when compiling Fortran and C code and is a high-priority item for fpm. Once implemented this functionality also paves the way for supporting features such as OpenMP and MPI.

Compiler argument handling must account for:

  • Different compilers (e.g. gfortran, ifort)
  • Different build profiles (e.g. release, debug, custom)
  • Different argument types (e.g. link-time, local-project, project-wide, ...)

This project will involve:

  • Implementing manifest syntax for abstracting common compiler options (e.g. fast-math)
  • Implementing manifest syntax for manually specifying compiler flags for different build profiles / different compilers
  • Implementing logic for how compiler arguments propagate between dependencies

Related issues:

  • fpm#112: Thread about managing flags
  • fpm#223: Compiler support and recognizion
  • fpm#350: Proposal for manifest syntax

Mentors: Laurence Kedward (@lkedward), Ondrej Certik (@certik), Brad Richardson (@everythingfunctional)

Preprocessor support

Adding support for both built-in compiler preprocessors and external third-party preprocessors is important for fpm due to the additional flexibility they provide when building complex packages. In particular, the Fortran-lang stdlib project exploits the powerful fypp preprocessor for code generation and we intend for stdlib to eventually be compatible as an fpm package.

This project will require:

  • Implementing a manifest syntax for defining preprocessor variables in a preprocessor-independent manner
  • Passing defined preprocessor variables to built-in preprocessors if necessary
  • Defining a manifest syntax for specifying a third-party preprocessor and the corresponding file suffixes
  • Modifying fpm to optionally invoke a third-party preprocessor before compiling sources

Third-party preprocessors should be specified on a per-project basis, i.e. multiple preprocessors might be required, and fpm should be able to report useful errors for missing third-party preprocessors.

Related issues:

  • fpm#78: support for third-party preprocessors (e.g. fypp)
  • fpm#308: Fortran-based smart code generation in fpm

Mentors: Laurence Kedward (@lkedward), Milan Curcic (@milancurcic)

Extended Testing Support

The aim of this project is it to create a manifest specification to provide defaults to executable targets in fpm projects. Information can be passed as environment variables, command line arguments or as runner. Desired features include:

  • Programs should have a way to find resources of which the relative position within the project source directory is known.
  • The current binary directory to access other targets within a project.
  • Default runners like mpirun/cafrun or scripts from test frameworks should be usable to launch programs.
  • A general syntax to define environment variables and command line arguments should be defined.

Some features should be implemented directly in fpm, while more elaborated functionality could be implemented in a separate fpm package as and official Fortran-lang fpm package.

Related issues:

Related discussions:

  • fpm#328: Example which requires external data

Mentors: Sebastian Ehlert (@awvwgk), Brad Richardson (@everythingfunctional)

Source Code Distribution with Foreign Build Systems

The aim of this project is to enable fpm to create source code distributions of itself that can be bootstrapped without fpm. Desired features include:

  • Allow fpm to generate source code distributions with non-fpm build systems.
  • Generated source code distribution should allow to build fpm project without fpm, git or internet access.
  • Potential third-party build systems are CMake and Meson.
  • Allow easier distribution and packaging of fpm via various packaging ecosystems.

Related issues:

  • fpm#69: Have CMake and Make backends
  • fpm#70: Have a Conda backend

Mentors: Sebastian Ehlert (@awvwgk), Laurence Kedward (@lkedward)

Standard Conformance Suite

Fortran compilers' support for ISO Fortran standards generally lag the publication of the standard by several years or longer. Fortran consultants Ian Chivers and Jane Sleightholme periodically publish a paper containing a table detailing the standard features supported by 10 compilers. Gathering the tabulated data requires a considerable amount of effort on the part of the authors and the compiler developers. The chosen venue for publishing the table also puts it behind a paywall: access requires a subscription to ACM SIGPLAN Fortran Forum. The project will automate the generation of the table, make it more detailed and empower the community to contribute to by submitting small tests to an open-source conformance test suite.

Prior work:

Mentors: Damian Rouson (@rouson), Arjen Markus (@arjenmarkus), Ondřej Čertík (@certik)

Fortran Standard Library (stdlib)

Strings

Traditionally, Fortran has had limited capabilities for strings and working with text data in general. Things have somewhat improved with Fortran 2003 that introduced deferred-length strings, however the core language still doesn't permit arrays of variable-length strings. Further, functions for splitting, joining, and sorting strings that are common in many other languages are not available in Fortran out of the box. This project will entail designing, implementing, and testing a suite of string functions and data types in the Fortran stdlib.

Related issues:

Prior work:

WIP:

Mentors: Brad Richardson (@everythingfunctional), Milan Curcic (@milancurcic)

Containers

Fortran offers all the ingredients needed for building a library of abstract data types, such as linked lists, heaps or binary trees. There is quite a lot of material available already, but the aim of this project is to provide a standardized implementation that can be used "off the shelf". Requirements include storage of arbitrary types of data and flexible API, so that all common uses are covered, open to further expansion.

Implementing a whole library would be ambitious, and given the historical focus of Fortran on performance, it may be more appropriate to restrict this project to one particular type, for instance a linked list, and examine a number of implementations and their performance characteristics. This would include timing under various usage scenarios, memory use (amount and fragmentation), and other aspects.

Related issues:

Mentors: Arjen Markus (@arjenmarkus), Milan Curcic (@milancurcic)

OS integration: File system

Currently, file system operations such as listing contents of directories, traversing directories, and similar, are restricted to 3rd party libraries and compiler extensions that are platform-specific and not portable. This project will entail designing and implementing a cross-platform solution for file system operations.

Related issues:

  • stdlib#201: File system operations
  • stdlib#220: API for file system operations, directory manipulation

WIP implementation:

Mentors: Arjen Markus (@arjenmarkus), Marshall Ward (@marshallward)

OS integration: Subprocesses

Cross-platform solution to abstract POSIX and Windows API for creating subprocesses.

Related issues:

Discourse thread:

Mentors: Sebastian Ehlert (@awvwgk), Milan Curcic (@milancurcic) Marshall Ward (@marshallward)

LFortran

Here we list some of the main projects, see https://gitlab.com/lfortran/lfortran/-/wikis/GSoC-2021-Ideas for more ideas.

Feel free to propose any project idea that you like to improve LFortran, for example by browsing open issues:

https://gitlab.com/lfortran/lfortran/-/issues

We list the project ideas sorted by priority that we would like to see them implemented.

Finish AST generation

LFortran has a Bison based parser implemented in the parser.yy file that can parse most of Fortran. Not all the grammar rules there are converted to AST yet. The purpose of this project would be to systematically go over the parser.yy file and ensure AST is always generated for all grammar rules. AST.asdl contains a list of AST nodes. You can read the comment there that explains the background and design motivation behind AST. The AST nodes are constructed from the grammar actions (specified between the { ... } in parser.yy) using macros that are defined in the semantics.h file.

The project would add all missing AST nodes into AST.asdl, add macros to semantics.h and use them in parser.yy.

If you have any questions, please do not hesitate to ask, we can discuss or provide more details.

Mentors: Ondrej Certik (@certik)

Implementation of features on the ASR and LLVM level

The roadmap https://gitlab.com/lfortran/lfortran/-/issues/272 issue contains a list of Fortran features that we want implemented. Each feature should be implemented at the ASR level and in the LLVM backend to be complete. If AST is missing for a given feature, then it has to be implemented also.

Here you can pick a feature or a set of features from the list and propose it as a GSoC project. In other words, this project idea can accommodate multiple student projects.

List of resources for more information and background:

If you have any questions, please do not hesitate to ask, we can discuss or provide more details.

Mentors: Ondrej Certik (@certik)

Improve x86 code generation

LFortran has a very fast x86 code generation backend implemented in asr_to_x86.cpp which allows very fast compiling (many times faster than going via LLVM). The x86 backend does not do any optimizations, so it is meant to be used in Debug mode only. As every backend in LFortran, the backend receives the code as ASR, and it recursively walks over each ASR node and generates x86 machine code.

The purpose of this project would be to extend this backend to cover more Fortran features.

If you have any questions, please do not hesitate to ask, we can discuss or provide more details.

Mentors: Ondrej Certik (@certik)

Automatic Fortran to Python wrapping

Add a backend to LFortran that automatically exposes (eventually all) Fortran module contents to Python. Similar to how f2py works, but using a robust production level parser and semantic analysis from LFortran.

Related issues:

Mentors: Ondrej Certik (@certik),

Finish the automatic formatter (lfortran fmt)

Here is a list of issues that should be fixed in order to make automatic formatting via lfortran fmt more useful: https://gitlab.com/lfortran/lfortran/-/milestones/2. This project could work on fixing those and implement other improvements in order for lfortran fmt to work on some projects such as stdlib.

Mentors: Ondrej Certik (@certik)

Allow to use gfortran compiled module files

There is a prototype parser for gfortran module files here: https://gitlab.com/lfortran/lfortran.py/-/blob/7a3b356122174d291562a5c47f0d2c9dc3b183da/lfortran/adapters/gfortran/mod.py. Port it to C++ and the current LFortran, and then allow such modules to be "used" in LFortran.

Related issues:

  • lfortran#52: Allow to "use" modules compiled by gfortran

Mentors: Ondrej Certik (@certik),

Parsing and Tokenization

Roundtrip Parser

Modify one of the following Fortran parsers as a roundtrip parser, which can recreate the original source code by fully capturing formatting data (case-sensitive variable names, whitespace, comments, etc.) alongside the syntactically essential content. The goal would be to develop code that both LFortran and Flint could use.

Mentors: Ondrej Certik (@certik), Marshall Ward (@marshallward)

Documentation tools

Maintenance of the FORD project

  • Check and organize the issue tracker
  • Sort and review pull request
  • Ping pull request authors and merge patches

Mentors: Brad Richardson (@everythingfunctional), Sebastian Ehlert (@awvwgk)

Use fpm package manifest as FORD project file

  • extract meta data from fpm.toml file instead of FORD project file

Mentors: Sebastian Ehlert (@awvwgk), Brad Richardson (@everythingfunctional)

Submitting your own idea

You are welcome to apply with your own idea if there is something not on this page that you are interested in and that you think would be a good addition to one of the repositories listed here.

As with the ideas listed here, please discuss your novel idea with us on our Discourse before making your application. This allows us to give feedback on the suitability of your idea as a Fortran-Lang GSoC project and identify potential mentors.

Add a custom footer
Add a custom sidebar
Clone this wiki locally