Labs and Projects
- Numbered labs and projects are in the course repo.
- See the calendar for their dates.
- Directions for each lab/project are in its folder's readme markdown file. View it through your browser.
- Labs and projects use C on Linux systems hosted by Duke's Containers service.
- To get started: create your container, attach to it with VSCode, use gitlab to fork lab/project folders from the course repo.
- Details in course git repository hosted on CS GitLab:see the Getting Started Guide.
- Use git/lab to fork each lab/project folder individually and push often to protect your work.
- Know the course policies on collaboration, grading, regrading, missing or late work, etc..
Labs
The labs are short hands-on tasks (1-3 hours) to apply and reinforce concepts and prepare you for the projects.
- Work individually. No teams for the labs please.
- Labs are due each Wednesday: one lab for each lecture of the prior week (usually two).
- Monday discussion sections focus on the labs due that week.
- If you complete the labs early you may use this form to be excused from the week's discussion.
- Submit each lab to gradescope using the gradescope button on gitlab.
- Add a text file (statement.txt) listing any sources of assistance and anything else you want to tell us. It is optional if there is nothing to say.
- See the calendar for their dates.
Projects
The projects build on what you have learned by doing the labs.
- You can work alone or with at most one other student on each project.
- Projects are due on certain Thursdays.
- Submit each project to gradescope using the gradescope button on gitlab.
- One student in a team submits, and adds the partner in the gradescope submit form.
- Add a text file (statement.txt or reflections.txt) that reflects on your team collaboration and lists any sources of assistance.
- See the illustrated instructions.
- See the calendar for their dates.
There are seven projects, one every two weeks on average.
- P1 Store. Bits and Bytes: Use bit-wise operations to extract and modify values.
- P2 KV. Data and Memory: Implement a hash table to store deserialized information for a key-value system.
- P3 Bomb. Reverse-engineer programs to determine correct input sequences that avoid failure in execution.
- P4 Attack. Perform simple attacks on a program through buffer overflow to i) cause some data to be overwritten and ii) cause the program to execute a specific function in the program that it should not execute.
- P5 KVcache. Caching: Build a cache of key-value pairs and provide appropriate replacement of any modified pairs.
- P6 Alloc. Memory allocation: Implement a version of malloc.
- P7 Thread. Concurrency: Implement a multithreaded program.
