Contributing

The first step to contributing to Chapel is to familiarize yourself with the language itself. The Learning Chapel page is a great resource for getting started with this. It is preferred that you start by learning about the language before diving into the compiler or runtime code. This will generally be a more rewarding experience, and will provide opportunities for tractable contributions to the project. Below are some examples of ways to contribute to Chapel while learning.

Note

Before submitting any pull requests to Chapel, be sure to fill out and send us a contributor agreement. We won’t be able to accept your pull requests without it.

Coding Challenges and Idioms

Tackle some popular coding challenges or programming idioms in Chapel. Show off your progress in a public repository. Ask for feedback from fellow Chapel developers and users. This is a chance to learn about and utilize Chapel’s unique features and strengths in productive parallel programming. Depending on the quality of the implementations, the code could be featured on Chapel’s website as a coding sample or even added to the examples directory in subsequent releases.

Some programming challenge sites:

• Project Euler
• Sphere Online Judge
• Google Code Jam

Some programming idiom sites:

• Rosetta Code
• Programming-Idioms

Code currently featured in Chapel’s release:

• Examples Directory
• Patterns Directory (work in progress, idioms can be contributed here)

Ports

Port a small application, library, or benchmark to Chapel. Take advantage of the chpldoc tool to generate HTML documentation for your code. This is a great way to get started if you are interested in pursuing a Demos project. If a benchmark is unique or important enough, a performance version of the test may be added to the test suite to track its performance across releases.

Some example benchmarks:

• IMSuite

• PRK

  • Existing Chapel PRKs (only 3 ported so far)

• Julia Benchmarks

Existing benchmarks and performance tracking in Chapel:

• Some of Chapel’s Benchmarks
• Performance Overview
• Performance Tracking Benchmarks

Bugs

Identifying bugs in code is nearly half the battle. By working on any of the other introductory tasks, you may cross paths with a bug or two. Reporting these bugs so that they can be tracked in the test system and eventually fixed is incredibly helpful to the project.

You can follow the steps outlined in the Reporting Chapel Bugs page to give a formal bug, or you can take it one step further by characterizing the bug with a small reproducible test, and contributing it to the repository in the test/ directory. See the Test System best practices for more information about tracking bugs.

Note

As shown on the Reporting Chapel Bugs page, many known bugs are tracked on our JIRA site. Bug tracking on JIRA is relatively new in Chapel and still an ongoing transition. Currently, there is no need to create an issue on JIRA for new bugs.

We do not recommend fixing bugs as an introductory task for new Chapel developers. If bugs are easy to fix, we typically fix them as soon as they are reported. This means the remaining tracked bugs are generally difficult to solve, which would likely be an unpleasant task for a new Chapel developer.

Documentation

Chapel’s documentation was originally made up of just the language specification. Since version 1.11, there has been an ongoing effort to produce online documentation meant for users rather than developers. The current documentation has come a long way since version 1.11, but there is certainly much more work to do.

If you find something unclear, or can’t find it at all, it is extremely helpful to the project to bring it to the attention of developers and/or improve the documentation.

All of the online documentation is generated as a Sphinx project. Module documentation is written in the comments of the module code and converted into restructured text (ReST) via chpldoc. All other documentation is contained within doc/release and doc/sphinx/source.

Coverity

We use Coverity to try and keep our code free of obvious coding bugs. Some issues it flags are important bugs and others are false negatives. It is a goal of the project to drive the number of open Coverity issues down to zero, either by fixing the issues, proving to Coverity that they are not issues (e.g., through assertions), or suppressing the issues.

You can view Coverity scans by visiting the Coverity Project page for Chapel and requesting access.