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 previous MAP students and research assistants.
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.
My research has addressed this problem with 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 automatically discovers the dependencies for each command as the build runs by tracing the system calls issued by all commands that run during the build.
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.
A paper describing Riker appeared at the 2022 USENIX Annual Technical Conference, where it won a best paper award.
You can find the paper and a video of the conference presentation at https://www.usenix.org/conference/atc22/presentation/curtsinger.
As I mentioned earlier, Riker uses system call tracing to discover dependencies and actions during the build. This system call tracing is currently tied to Linux, but can be ported to run on other platforms. Riker’s system call tracing would also be useful for other research projects, especially systems like Riker that observe an execution to discover what a user intends. My goal for this summer is to extract Riker’s system call tracing into a seprate library so it can be ported to other platforms like macOS or Windows, and could support other reserach projects.
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 set regular meeting times and working hours. Part of your work during the summer will require you to present your work to the other MAP students in the department, 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 key operating system abstractions like processes and files. 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.
There are several steps in the application process, each with their own deadlines. Please review this section carefully as you apply.
As I review applications to my MAP application I will invite some students for an interview. I will ask you to read, write, and discuss code during the interview. We will also spend time discussing the research project for the summer and your short- and long-term interests.
Offers for MAP positions in the science division will go out on March 4, 2023. The deadline for you to respond to MAP offers will be March 15, after which point additional offers will go out for positions that are declined.
If you have any questions about the project or the application process I am happy to answer them over email.