The students working with me on MAPs this summer will be contributing to Riker, a new software build system I am developing in collaboration with Dan Barowy at Williams College, along with two MAP students from summer 2019.
Build systems help developer turn source code, libraries, and other assets into runnable software. One widely-used build system that many Grinnell students have seen is GNU Make. Make is powerful, but it has a few issues that make it difficult to produce build systems that are both efficient and correct. Make requires users to write rules that describe how to turn a set of manually-specified dependencies into output files; getting one of these dependencies wrong will cause Make to run the wrong set of commands when you rebuild after editing your code. Make also requires users to manually break a build up into separate steps to make the build process efficient; if you don’t want to rerun the entire build any time you change even a single file, you have to give Make precise instructions on how to run just the relevant parts of the build. For large projects, both of these limitations can be a serious problem.
This summer, we’ll be working on a new build tool called Riker that uses a completely diferent approach from GNU Make.
All you need to do to describe a build to Riker is write down the commands to run the complete build in a Rikerfile – something like
gcc -o myprogram *.c.
Riker runs this build, and observes all of the commands that execute during the build, including each command responsible for compiling a .c file in your current directory.
Riker will automatically discover the dependencies for each command as the build runs.
Riker can use this information to run just the commands that depend on the files you modified.
Using Riker, it’s easy to write correct, efficient builds without manually specifying dependencies or breaking builds down into separate steps.
There are some important features I’d like to add to Riker this summer. The most significant limitation in Riker is that it doesn’t always run builds in parallel; if the full build demonstrated to Riker runs sequentially—meaning it runs one command at a time instead of running several commands at once—Riker will always perform those steps sequentially. Running independent commands at the same time could make builds run much faster. This summer, we’ll be working on an extension to Riker to identify commands that could run simultaneously, and use that information to update the build rules Riker learns to run future builds in parallel. If everything goes smoothly there are other extensions we could add, like better tracking of dependencies downloaded from internet sources or automatic packaging of build environments into portable containers.
If you’d like to see a demonstration of Riker, you can attend the CS Extra on summer research opportunities, or watch the recording of the event if you weren’t able to attend. You can find this on the CS Department Team in Microsoft Teams.
While a MAP lasts for ten weeks during the summer, you will need to put in some additional effort before and after the MAP. We will start a weekly discussion group sometime in April to cover topics that will help you prepare for work over the summer. This will require you to read a moderate amount of material on your own, along with a few small independent projects to familiarize yourself with the programming language(s), tools, and techniques we’ll need during the summer. During the summer you are expected to work 40 hours a week for the ten weeks of your MAP. We will work as a group to determine reasonable start and end dates, and to set our working hours. I expect that we will have made some reasonable improvements to Riker by the end of the summer, and I would like to submit this work for publication; my expectation is that you will contribute to the writing process as well, which may take place after the summer. I will also ask you to present to the other MAP students in the department regularly during the summer, and at least once to the entire department in a CS Extra to share the final results from our work.
Riker is written in C++, which I understand most Grinnell students will not know. That’s perfectly fine, but I’ll be looking for students who are strong C programmers and are willing to learn C++. This will be easier for students who have completed CSC 207, but CSC 161 may be fine for students who are eager to learn and can put in some independent effort to prepare for the summer. Contributing to Riker will also require that you understand processes, files, and permissions on Linux. CSC 213 is not a hard requirement to work in my group, but students who have not taken CSC 213 should expect to spend a little extra time preparing for the summer. I welcome applications from any Grinnell students, but if you have not taken CSC 161, CSC 207, or CSC 213, you should be prepared to show that you’re able to pick up relevant concepts for the project this spring and during the summer. I may ask some applicants to complete a small coding challenge as part of thier application if I need more information about your CS experience.
I expect there to be some surprising discoveries and setbacks this summer, so everyone in the research group (including me) will be learning as we work together. That means you’ll need to be prepared to be surprised, confused, or stuck, and show that you’re able to work well both individually and with a small research group to solve challenging problems.
Summer MAP applications are due on March 1, 2021. Please complete all of the steps below to apply:
I will be reviewing applications as they come in, so please apply early if you can. I will invite some applicants to schedule interviews for the position, but I can’t promise I will be able to interview everyone who applies.
If I need more information about your C programming experience, I may also invite you to complete a coding challenge in addition to your application. The challenge is not required to complete your application, but it will help me evaluate your application, particularly if you haven’t taken CSC 213 with me. I will send you an email about the coding challenge if it will help me evaluate your application, but you’re welcome to complete the challenge even if you are not explicitly invited. Everything you need to get started is available on the coding challenge page.
I won’t be making offers until after the deadline, but the sooner you send in your application the more opportunities will have to schedule an interview and cover any questions you might have about the project. If you have any questions, concerns, or just want an update, feel free to ask me for an update over email.