Project List¶

This is the project list for Google Summer of Code with Chapel. The list is constantly growing and evolving, but it should remain relatively static during the Google Summer of Code application phase. For more information about applying, see Steps to Apply.

Student Submitted Projects¶

The project ideas in this list have been compiled by Chapel developers. Students may submit proposals based on existing ideas here or new ideas altogether.

Compiler¶

Incremental Compilation

Expected results:
Status:	Available
Description:	Right now, re-compiling a Chapel program means re-compiling even the parts that haven’t changed, such as functions that haven’t been altered since the last compilation. We’d like to adjust our compiler to reuse some of the information it already has. Steps envisioned: move away from using integers to disambiguate things with the same name, for everyone’s sanity create some kind of code cache (which could be stashed in a .o file) that perhaps uses hashes of fn ASTs or perhaps uses appropriately mangled names with module names adjust function resolution/generic instantiation to not instantiate a function that is already compiled in the cache adjust code generation not to compile a function that is already present in the cache adjust exe building to link in the symbols from the cache
	Either a working prototype of this functionality, or the work is in a state where a core team member could pick it up and finish the job without devoting a similar amount of time to the project. We think that best case scenario, this could improve compile time by 2x.
Required knowledge:
	C/C++
Optional knowledge:
	Chapel Familiarity with compilers, especially code generation/generics Familiarity with the Chapel compiler
Mentor(s):	Lydia Duncan

Begin expressions

Expected results:
Status:	Available
Description:	The Chapel language already provides a rich set of constructs for creating parallel tasks and synchronizing between them. However, these constructs are mostly statements, which reduces their convenience. This project adds “begin expressions” as a way to introduce parallelism within a single expression. For example, instead of writing funA()+funB() with the two functions executed sequentially, the programmer will be able to say: begin funA() + begin funB() Such an expression will compute the two functions in parallel. The consumer of the result will block until both functions have completed.
	Begin expressions are available in Chapel. Bonus result: the runtime library supports begin expressions for increased performance.
Required knowledge:
	C/C++
Optional knowledge:
	Chapel Familiarity with compilers Familiarity with parallel programming Familiarity with the Chapel compiler
Mentor(s):	Vassily Litvinov

Enum bug hunting

Expected results:
Status:	Available
Description:	Work through some known odd bugs with our enum type, improving user experience and compiler correctness. The relevant bugs can be found in the top level STATUS file in our main repository by searching for the word “enum”, but are listed here for completeness: Declaring enum types in a function body can cause compile time errors Enum types always represented using the smallest integer type available, even if the enum values require a larger integer. Compile time integer operations on enum values may result in non-param values Implicit conversions of enums to uint not supported. Casts and relational operations involving enum constants may fail to compile or produce incorrect answers. Unable to resolve return type for casts between an enum type and string if the enum is declared in the function and the string is passed in as a type parameter. Other bugs may be found and addressed during this work, either on enums or in areas related to the above mentioned bugs.
	Though the hope is that all of these bugs will be addressed in the 12 week timeframe, such a goal may be unreasonable due to the complexity of individual bugs. It seems reasonable to expect more than half to be complete, and best case scenario is that all are complete plus a few extras.
Required knowledge:
	C/C++ Familiarity with enums as a concept
Optional knowledge:
	Chapel Familiarity with the Chapel compiler
Mentor(s):	Lydia Duncan

Improved Argument Parsing

Expected results:
Status:	Available
Description:	Chapel currently has a fairly robust built-in argument parsing system for ‘config’ variables. This project would aim to mature the argument parsing and bring and even more modern features, such as: Help information about arguments Argument checking functions (formal name?) Allow arbitrary argument names for a given variable These are some primary goals of this project, but the list may evolve or extend with ideas produced by the student along the way. It would be preferable to extend the existing built-in argument parsing functionality, but building an argument parsing library from the ground up is also a viable option for this project.
	Extended argument parsing features ready for public use.
Required knowledge:
	Experience with argument parsing libraries in any language
Optional knowledge:
	Chapel
Mentor(s):	Ben Albrecht

Compile time warnings for use after free of stack var.

Expected results:
Status:	Available
Description:	Chapel’s “begin” statement creates an asynchronous task. Today the Chapel compiler allows such a task to reference stack-allocated variables of the lexically-enclosing function(s), if any. This is problematic, however. Once such a function returns, its stack-allocated variables are deallocated. If the asynchronous task continues executing and accesses that memory, it will likely read incorrect values and/or overwrite some other function’s variables. Leading to incorrect results, program crashes, etc. This project adds an analysis to the Chapel compiler to generate a warning or an error when the source program may exhibit this behavior. This analysis can be simple and cover just the most obvious cases. It can also be advanced, taking into account the call graph, parallelism and synchronization. Having such an analysis in the Chapel compiler will contribute to improving robustness of Chapel programs.
	The above warning has been implemented within the Chapel compiler.
Required knowledge:
	C/C++ Familiarity with compilers
Optional knowledge:
	Chapel Familiarity with the Chapel compiler Familiarity with IR and analyses
Mentor(s):	Vassily Litvinov

Warning control

Expected results:
Status:	Available
Description:	The Chapel compiler today offers a very coarse control over the warnings it emits: a single option enables or disables all warnings. As one of the unfortunate consequences of that, we have avoided enabling a few informative warnings by default because they may be more annoying than useful for many users. This project will give users finer control over which warnings the Chapel compiler emits. One such control is a compiler option to enable or disable a particular kind or category of warnings. For example, such an option could tell the compiler to disable warnings that assignments have been serialized. Another control is an annotation in Chapel source code telling the compiler to suppress warnings for the given source code line. Such an annotation could tell the compiler to suppress “this assignment has been serialized” warning at a particular spot in the source code, while allowing such warnings in the remainder of the source. Such controls will allow the Chapel compiler to be more aggressive in informing the user about potentially-unintented situations in the source code.
	The warning controls have been implemented within the Chapel compiler.
Required knowledge:
	C/C++
Optional knowledge:
	Chapel Familiarity with the Chapel compiler Familiarity with compilers
Mentor(s):	Vassily Litvinov

Runtime¶

Memory tracking improvements

Expected results:
Status:	Available
Description:	Memory management in the Chapel runtime is typed, in that each allocation specifies the kind of information the memory will hold. Memory management has a tracking feature that can report on memory usage, either on a detailed per-allocation basis, by memory kind, or in aggregate. This can be used to see overall allocation patterns, identify memory leaks, etc. Currently when memory tracking is turned on, a program execution-time setting determines whether all memory kinds are tracked, or all kinds except a predetermined fixed subset representing strictly internal uses. Such limited control often results in much more tracking overhead and output than would be ideal. This project will provide for enabling and disabling memory tracking of each memory kind individually, improving the usefulness of the tracking by allowing unnecessary overheads and undesired reporting output to be removed.
	User interface and underlying runtime memory management changes to allow controlling memory tracking on a per-kind basis.
Required knowledge:
	C
Mentor(s):	Greg Titus, Elliot Ronaghan

Reporting stack traces on halt

Expected results:
Status:	Available
Description:	The halt function allows a Chapel programmer to cause a Chapel program to exit with an error. This function is called when an assert failure is encountered, for example. It would improve Chapel programmer productivity if such halt calls printed out a stack trace in addition to an error message. This project will investigate stack trace libraries, and if a license-compatible stack-trace library is available, integrate that into Chapel’s C runtime handler for exit-on-error. If no such stack trace library exists, this project would investigate alternative approaches, such as attaching a debugger to get the stack trace or implementing a stack trace mechanism in the Chapel runtime. This initial stack trace mechanism might not function on all platforms or compilers supported by Chapel. When it does work, it should print out Chapel source code line numbers.
	Support for printing Chapel stack traces on halt and a demonstration program.
Required knowledge:
	C
Optional knowledge:
	Understanding of calling conventions and program stacks
Mentor(s):	Michael Ferguson

Performance¶

Investigate and improve LLVM backend performance

Expected results:
Status:	Available
Description:	Investigate the performance of the LLVM backend and make changes to improve performance. Changes might include emitting good type-based alias analysis metadata and indicating (possibly using struct-path aware TBAA); adding loop vectorization hints; indicating when a load is from ‘const’ data; experimenting with the Polly optimizer; and using LLVM best practices for performance.
	Improvements in the Chapel’s LLVM IR generator and performance improvements to Chapel programs built with –llvm.
Required knowledge:
	C++
Optional knowledge:
	LLVM Experience with an language front-end generating LLVM IR
Mentor(s):	Michael Ferguson

Libraries¶

Plotting library

Expected results:
Status:	Available
Description:	Build or port a plotting library in Chapel.
	There are a plethora of potential features that could be built into a plotting library. A minimal plotting library might be characterized by the following feature set: 2D plotting: scatter, lines, and bars Plotting multiple sets of data, with distinguishable representations Plotting functions Labeling axis, data sets, and graph titles
Required knowledge:
	Experience with a plotting library or framework e.g. matplotlib, plotly, orgnuplot
Optional knowledge:
	Chapel
Mentor(s):	Ben Albrecht

Develop a basic GUI toolkit library in Chapel

Expected results:
Status:	Available
Description:	A library containing a set of graphical control elements (widgets) used to construct a graphical user interface (GUI). This project will involve designing a rendering engine or creating Chapel bindings for an existing engine, then building a widget toolkit on top of that engine.
	Object oriented interface for basic GUI support.
Required knowledge:
	Experience with a GUI library or framework
Optional knowledge:
	Chapel
Mentor(s):	Ben Albrecht

Compatibility¶

Try Chapel online

Expected results:
Status:	Available
Description:	Build a web service that compiles Chapel code online and returns the output. Alternatively, this could be done as a contribution to an existing website that supports other languages. Some examples of this are: https://ideone.com/ https://www.remoteinterview.io/online-c-compiler http://cpp.sh/
	A web service that compiles and runs Chapel code online.
Required knowledge:
	Bash HTML CSS Javascript
Optional knowledge:
	Chapel Node.js
Mentor(s):	Ben Albrecht

Jupyter kernel for Chapel

Expected results:
Status:	Available
Description:	Currently, the Chapel interpreter is in its early infancy. We fully expect to contribute a Jupyter kernel with our interpreted version. In the meantime, we would like to contribute a Jupyter kernel for the compiled implementation, laying the groundwork for the future interpreted Chapel kernel. More information can be found here: http://bollwyvl.github.io/jupyter.github.io/kernels/
	A functioning Jupyter kernel for Chapel
Required knowledge:
	Python Bash Experience with IPython Notebook / Jupyter
Optional knowledge:
	Chapel
Mentor(s):	Ben Albrecht

Improve Windows support in Chapel

Expected results:
Status:	Available
Description:	Chapel currently supports Windows through Cygwin. While this way of supporting windows builds on the existing Linux support, it presents some technical challenges and may be problematic for commercial users for licensing reasons. The goal of this project would be to create more native support for Windows in the Chapel runtime. This runtime is written in C. One possible approach is to pursue libuv integration with the Chapel runtime.
	Cygwin may still be required to run the Chapel compiler, but Cygwin would no longer be required to run a program that was built with the Chapel compiler.
Required knowledge:
	C/C++ basic knowledge of Windows development
Optional knowledge:
	Windows libraries for threading and I/O libuv
Mentor(s):	Michael Ferguson

Demos¶

Your favorite application or library in Chapel

Expected results:
Status:	Available
Description:	Build any application in Chapel that might show off its productivity, performance, and/or elegance. This could be anything from a port of an email client library to a standalone molecular dynamics engine. The world is your oyster, and we’re excited to mentor you along the way to building your application in Chapel.
	Expectations will be tuned specifically to project. In a general sense, the application or library should reach a state that is ready for public use.
Optional knowledge:
	Chapel
Mentor(s):	Vassily Litvinov, Ben Albrecht

Write a web-server in Chapel

Expected results:
Status:	Available
Description:	Write a simple web-server in Chapel. Investigate how Chapel’s I/O support can enable multiple tasks to be multiplexed over the same polling loop, while at the same time supporting hardware parallelism within a process. One possibility is libuv integration. Build out Chapel’s support for Sockets. Then, as a demonstration, build a webserver using the sockets support and measure its performance.
	Task-aware socket library and web-server demonstration application
Required knowledge:
	C Basic familiarity with socket/network programming
Optional knowledge:
	Chapel libevent, libev, libuv, or similar library HTTP
Mentor(s):	Michael Ferguson