Laboratory Exercises

CSC 213 - Operating Systems and Parallel Algorithms - Weinman

Summary:: Information about expectations for alboratory exercises and methods for preparing to submit them.

Overview

This course features weekly laboratory exercises, as listed on the course schedule.

Unless otherwise stated:

Collaboration with students outside your group is NOT allowed on laboratory exercises.
You may use language references to determine relevant C syntax and semantics. Because C syntax is standardized, we will consider C syntax and semantics to be general knowledge, and you need not cite reference sources.
You may consult only the textbook and the C syntax references for information regarding alorigthms. All non-syntax consultations (including the textbook and C references) require formal citation within the related program or exercise.
You always may consult the instructor and mentor regarding questions on labs or assignments

Programs (source code, compilation, and output) are to be submitted in the format below.

Submitting laboratory exercises

In turning in any programs for the course, please follow these directions.

The first seven or more lines of any C program should be comments containing your name, your mailbox number, your lab section, an identification of assignment being solved, and a description of the contents of the file. For example:

/*************************************************************************
* Jerod Weinman
* Box: Science Division Office
* Laboratory Section 213L.01
* Lab 1: Review of C; Sorting and Order Statistics
* arraylib.c: Definitions of useful functions to manipulate arrays
************************************************************************/
A comment is required for every definition of a C function, stating the purpose of the program unit in English. While complete 6-P documentation is not required for every method, it embodies many good practices you may wish to consider. Documenting before you write a procedure can help you plan and clarify the requirements of your implementation.
Obtain a nicely formatted PDF listing of your source code using the enscript(1) command:

$ enscript -Ec -2 -r --color -p - source.c ... | ps2pdf - prettysource.pdf

where prettysource.pdf is the name of the file in which you want the formatted source code stored (enscript generates a PostScript file, which you will pipe to ps2pdf(1) for conversion to PDF.) If your work involves several C files, list the primary program first, then list any supplementary files. Multiple source files can be placed in one call to enscript. While you may also use a wildcard such as *.c be sure this only includes the files requested for the particular assignment.
As appropriate, create a transcript of your program's compilation and output runs using the script(1) command:
1. In a terminal window, start recording output to a file called transcript with the command:
  
  $ script transcript
2. Compile your program with gcc or make as appropriate.
3. Run your program with appropriate test cases to verify its correctness.
4. When your runs are complete, stop the script session by typing Ctrl-D.
5. Convert the recorded text file to a nice, printable PDF file using enscript(1):
  
  $ enscript -2 -r -p - transcript | ps2pdf - transcript.pdf
  
  where transcript is the name of the recording file you created above, and the .pdf file is the printable version enscript(1) creates.
Concatenate (merge) your program source, transcript, and report etc.

$ pdfconcat -o submission.pdf prettysource.pdf transcript.pdf
If the assignment a PDF and source files, create an archive of your source files and PDF for electronic submission. For example,

$ tar cf submission.tar submission.pdf source.c ...

where submission.tar is the name of the archive file you want your files stored in. You may list as many source files on the line as you wish, or even use a wildcard (*.c) Please be sure you do not include any intermediate PDF files or urequested source files.
One group member should submit an electronic version of the archive (submission.tar from above, or submission.pdf if no source files are required) online via PioneerWeb by the due date. Be sure you allow enough time to construct your submission before the deadline.

Notes on grading

Requirements

Since every programming task should yield readable and carefully tested code, the grading of all programs for this course will begin with the following algorithm (expressed in C format):

: if ( (no_comments)
|| (no_evidence_of_compilation)
|| (no_test_runs) )
return (no_grade);

When a program is submitted according to the format specified above, it should be understood that the transcript reflects a complete session of program listing, compilation, and running. With this understanding, editing of any script file is strictly forbidden and will result in automatic failure on the assignment. Such editing also may raise questions of academic dishonesty; and, by College policy, any evidence of academic dishonesty must be turned over to the Academic Standing Committee for action.

Style

Because code maintainability is an important part of development, your labs will be graded in part on style, as well as correctness. After all, if I cannot understand your code (or it takes me too long to), I cannot give it a grade regarding its correctness.

Some style matters I care about:

Indentation and whitespace that help delineate code blocks. (Most editors will help you with this.)
Helpful comments on blocks of code or particularly complicated expressions
Functions that are reasonably small. A very good guideline I try to follow is getting an entire procedure to fit on much less than one screen; this makes interpreting a function's action more readable by forcing you to break it down into named steps that can be seen at once. It also promotes easier debugging and unit testing.
Code lines that are no wider than 80 characters. This makes them easier to read both on screen and on paper. (Note: If running enscript on your program code produces X lines were wrapped, where X is some number, then your lines are wider than 80 characters and you should re-format your code with additional linebreaks.)

Failure to incorporate these style considerations will lower your grade.

Acknowledgments

Adapted from Assignments for Computer Science 213, Henry Walker; and CSC213, Fall 2006 : Laboratory exercises, Janet Davis. Some of the style considerations were adapted from Marge Coahran's.