Skip to content

GSoC 2022 Project ideas

Jump to bottom Edit New page
Jeremie Vandenplas edited this page Feb 22, 2022 · 33 revisions

Introduction

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

The list here is based on priorities identified by Fortran-Lang contributors and should inform you about 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 the repository. Please familiarize yourself with each repository before exploring the ideas here.

We are not limited to the project ideas listed on this page. If you have your own project idea that is not listed here, let us know.

Contacts for prospective mentors: Mentors list

Fortran Package Manager (fpm)

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)

Local package repository

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), Brad Richardson (@everythingfunctional), Milan Curcic (@milancurcic)

fpm-ize the Fortran ecosystem

Research the Fortran library and application ecosystem (on GitHub and beyond) and collaborate with package maintainers on making their package fpm-compatible. In this project, the contributor and mentor would research and identify a limited number of Fortran packages that would be feasible to make compatible with fpm, and that would have a relatively high impact.

Mentors: Milan Curcic (@milancurcic)

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), Jeremie Vandenplas (@jvdp1)

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)

Support for C++

Enabling fpm to compile C++ projects would make a whole number of projects available in the Fortran ecosystems, most importantly the LFortran compiler and its AST parser. This requires fpm to handle C++ headers and modules (source scanner) and being able to link Fortran and C++ correctly into executables.

Mentors: Sebastian Ehlert (@awvwgk), Ivan Pribec (@ivan-pi)

Tree shaking

Building a large dependency (such as stdlib, for example) is both slow and increases the size of the produced object and executable binaries. "Tree shaking" is an optimization technique commonly used in the JavaScript ecosystem. It allows a build system to exclude unused modules and procedures from dependencies. For example, if a small fpm project uses only optval() from stdlib_optval, fpm should only need to build stdlib_optval and stdlib_kinds (dependency of stdlib_optval). While initially perhaps negligible, this problem will become more apparent as the fpm ecosystem grows and more large packages become fpm-compatible.

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

Fortran Standard Library (stdlib)

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), Milan Curcic (@milancurcic)

OS integration: Subprocesses

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

Related issues:

Discourse thread:

Mentors: Sebastian Ehlert (@awvwgk)

Sparse matrices

Implementing a standardized API for procedures to handle (COO and CSR) sparse matrices. Both non-OO low level API and OO API should be implemented.

Related issue:

WIP implementation:

Mentors: Ondřej Čertík (@certik), Milan Curcic (@milancurcic), Ivan Pribec (@ivan-pi), Jeremie Vandenplas (@jvdp1)

LFortran (lfortran)

Compile stdlib, fpm, and other Fortran-lang projects

In this project, the student would work on implementing LFortran features toward successfully compiling stdlib, fpm, and other Fortran-lang projects.

The project can be any one of the following,

  1. Compile with --symtab-only mode (Recommended for 18 hours/week sized projects)
  2. Compile with normal lfortran i.e., without using any extra flags - stdlib already compiles with --symtab-only mode (though stdlib/tests don't work as of now but other than that everything works). For compiling without any flags, the work is in progress. This gist contains instructions to find out the current state. You can do something similar for fpm and other Fortran-lang projects. Note that, it would be good to use a specific commit of stdlib, fpm through out the project, instead of always using the master/main branches. (Recommended for 36 hours/week sized projects. For stdlib we will consider 18 hours/week sized projects because, --symtab-only mode is already working to a great extent).
  3. Adding support to LLVM backend for stdlib - This cannot be done without significantly making progress on second idea (i.e., the above point). So, it is recommended for 36 hours/week sized projects.

Mentors - Gagandeep Singh (Gitlab - @czgdp18071)

Allow running Fortran in the browser

This project would entail working with LFortran, LLVM, Emscripten, and Webassembly to allow running Fortran in the browser.

  • use LLVM and Emscripten to compile Fortran code to Webassembly
  • create custom Webassembly backend for LFortran and compile LFortran itself to Webassembly

Parser + ASR (for F2PY)

Enhance the frontend parser to allow for more generic extensions and keywords. In particular, parsing the pyf or signature file format consumed by F2PY. This would mean that SciPy can be directly transformed to the ASR representation without a fixed form parser.

This also involves adding nodes to the ASR itself.

Mentors: Rohit Goswami (@HaoZeke)

Language Server

This project would be used to first serialize the ASR and then use it within a language server.

Other

Port fortran-lang.org to Sphinx

This project would involve porting the Fortran-lang website from the current framework (Jekyll) to Sphinx+Myst parser for internationalization support and ease of maintenance.

Mentors: Sebastian Ehlert (@awvwgk)

Build or embed online playground for fortran-lang.org

An online (in-browser) Fortran playground on the landing page of fortran-lang.org would allow visitors to try out Fortran immediately, without having to install the compiler locally. There are different possible approaches:

  • Send source code to a server that compiles and runs the code and returns the output
  • Compile and run a subset of Fortran in the browser via Webassembly and Emscripten
  • Embed a reduced version of an LFortran Jupyter notebook
  • Embed an existing playground like Repl.it or Compiler Explorer

Get fortran-lang/minpack to be used in SciPy

fortran-lang/minpack #14

The participant would work with Fortran-lang and SciPy teams toward implementing fortran-lang/minpack in SciPy.

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