Policies for the Labs

We expect you to know this information.

About the autograder (AG)

The autograder (AG) is a server that checks and grades your work and maintains the group database. You will hate the AG at first, but eventually your hatred will give way to grudging appreciation.

However, the AG is not perfect. A few things to know:

You will have to use the git revision control system to prepare your code repository exactly the way AG wants it. AG compiles, runs, and grades your code exactly as it is in your repository, and it expects you to follow the rules for what files you modify and where they are in your repository. If your repository is out-of-date, corrupt, or deformed, then the AG will give you a zero and will not tell you why.
The AG runs on a machine maintained by Prof. Landon Cox. Sometimes it fails in some way and doesn't get fixed until he gets to it. So you may just have to be patient.
The AG builds and runs your code on a specific version of Ubuntu Linux. If you develop on a different system, then it is possible that your observed behavior may differ. This is rare, but we suggest that you test/debug on a VirtualBox Virtual Machine running the same version of Ubuntu (see instructions below).
The AG has a bit of a clunky interface for group management. If we want to change the group assignment after the semester starts, we have to edit the database manually. So please don't request any changes to your groups unless the circumstances truly warrant it.
The AG limits the work it will do for you. Each group may submit to the AG at most once per day (calendar date / resets at midnight). In addition, for each project you have three bonus submissions that you may use at any time. See below for more detail.

Setting up your group environment

AG group server page. This page tells you your current group and how to set up your group's code repository on gitlab.oit.duke.edu. Note: all group members must create an account on gitlab.oit.duke.edu before joining a group. Log into gitlab.oit.duke.edu using Shibboleth: your GitLab username must be the same as your NetID.

Instructions for group setup. This is a local copy of the instructions on the AG group server page, for use if AG is not available.

Handing in your work

Submit your code through the AG submit page. The autograder pulls the latest code from your git repository (be sure to push your changes to your repository!), compiles/builds it, runs some tests on it, and reports a result to you. The result is a thumbs-up/thumbs-down (pass/fail) for each test. The specific tests and specific observed behavior under each test are secret. Autograder limits. Each group may submit to the AG at most once per day (calendar date / resets at midnight). In addition, for each project you have three bonus submissions that you may use at any time. Occasionally we grant additional bonus submissions. In particular, the autograder and tests are undergoing continuous enhancement. We will grant additional bonus submission if there is any problem with the autograder: please bear with us.

Using other people's code

We all know that there are various fragments of code available on the web that are relevant to the assignments. You are not prohibited from looking at material on the web. We believe that we have provided you with enough to start with that it will not benefit you to import source code from anywhere else. The point of the lab is to learn, and we want to make it easy for you to learn!

When you hand in the lab, we expect that your code is your own. If you incorporate source code from some external source, you must add a comment indicating the imported code and the source of that code. You must note all sources of imported code in your submitted README file. You should be able to explain any part of your code in detail, and why you chose to do it that way and not some other way. If you encounter code from some external source that diminishes your opportunity to learn by doing the lab, please inform us (we may not be aware of it).

Academic dishonesty. Be sure that you are familiar with the policy on collaboration and other policies. In particular, sharing of code among groups is not allowable. Do not obtain code from previous semesters. Take care to acknowledge any sources of code or assistance in your README.

Resources

About C. The first labs ask you to program in the C programming language. We will discuss some aspects of C in lectures and recitations, and we will provide relevant examples, but we do not teach C. If C is unfamiliar to you, you will need to read up from some other sources, or spend more time with the sample programs. You should take the time to look through some of the supporting materials on the resources page. We find that the students who struggle most have not taken the time to read up, and as a result they have found themselves spending more time debugging.

About Unix. To do the labs you will need a Unix development environment. If you are a CompSci or Engineering major then you have access to Unix systems in those departments (e.g., login.cs.duke.edu). We can create term accounts to get access to Unix systems in the CompSci department if you need it. Duke also runs a virtual machine service that can give you a private Unix system for your use. You are welcome to use your own machine if it provides a suitable Unix development environment. Apple provides a good environment for Macs, and there is software that purports to provide a usable Unix environment over Windows (but be warned that may be more trouble than it's worth).

If you are using Mac OSX. Go download and install Xcode from developer.apple.com.

Note also that the gdb debugger has been replaced with lldb in OSX.

If you are using Windows. You need a Unix development environment, and Windows does not provide one (see above). But you can create an Ubuntu virtual machine using VirtualBox.

Once you have a command-line shell on a suitable system. You can compile C code with the gcc compiler, and/or build programs with the make utility. You can use the man command to learn about any C builtin library API and/or system call API or command. E.g., try man malloc or man strcpy.