This lab has two goals: To introduce the lab environment to those of you who haven't taken CSCI 235 and to give all of you some initial practice with C. If you have taken our CSCI 235, then presumably you're joining us halfway through the lab period; the sections introducing the lab environment may be useful as reference for review, but you can largely skip to the section on C.
In CSCI 245 labs (and CSCI 235 labs, too), we use a protocol called pair programming. As its name suggests, it means two people working together at one computer, programming as a two-person team. This approach is common in industrial settings, especially software groups that use modern or "agile" methodologies. But our reason for using pair programming is its usefulness as a learning experience.
By programming in pairs, you learn from each other. Your partner will help clear up simple misunderstandings you have about the recent concepts or the task at hand. You will catch each other's simple mistakes. By discussing the problem at hand and its solution, you'll notice and remember more things than if working alone.
There are two roles in pair programming: The driver and the navigator. The driver controls the keyboard and mouse and does the actual programming. The navigator talks through the current problem or task with the driver, catches the driver's simple mistakes, thinks about how to test the driver's code for correctness, and glances ahead to the next task.
The students in a pair should switch roles every ten or fifteen minutes, or between each task. It's usually better to position yourselves so all you need to do to switch roles is slide the keyboard and mouse over (as opposed to getting up and switching seats).
As tempting as it is, the navigator should not log in to the next computer over. It seems innocent enough to have the other computer logged in so that the lab instructions can be on a separate screen, but having a second computer logged in means that the navigator's eyes are not on the code being written, and the driver will psychologically feel more ownership over the computer and the code being written. In pair programming, all code needs to be considered common property of the pair, and so two eyes on the same screen.
Students are also expected to switch partners each lab session. Work with as many other classmates as possible over the course of the semester.
To give the pair neutral territory to work in, the lab machines will be logged into a "class account" (named csci245a, csci245b, etc) when you arrive to lab on most lab periods (there will be a few labs during the course of the semester when you will need to log in as yourself). This also make for convenient grading: You won't need to turn anything in---the TA will simply log into each class account and grade the work saved under that account. (So, don't forget to put your names somewhere in the files you work on.)
The computers in the Computer Science Lab run different software from what you may be most familiar with (ie, they aren't running Microsoft Windows or Apple's Mac OS). You may hear people call the operating system Unix, Linux, Ubuntu, or GNOME. Here is what each of those actually means:
At the top of the screen you'll see a panel with a pull-down menu
named Applications.
Applications you'll need to be aware of include:
Applications->Internet
you'll find Firefox and Chrome.
Either will do.
Applications->Accessories
you'll find GEdit
(where it appears as "text editor")
and GNU Emacs.
I happen to prefer another one called XEmacs, which is installed
but not listed in the Applications menu.
There's also Vim (under Applications->Accessories
as GVim), but it has a pretty steep learning curve.
Applications->Programming.
Applications->Accessories.
Feel free to poke around the rest of the desktop for a minute.
Now open a terminal.
When you're using a terminal, you are always in some folder (or "directory"---that's an old fashioned term for it that I often use out of habit), just as in the File Explorer under Windows or Mac OS's Finder. Each account in the lab (including your own account and the "class account" you're using right now) has a home directory, and that's what you're in when you first open a terminal. You should see something like this:
cs245a@cslab14:~$
The cs245a part (or whatever you have)
indicates the user id that is logged in.
cslab14 (or whatever you have)
indicates the machine being used.
The ~ indicates you are in the home folder
of the account.
The $ indicates the terminal is waiting for you
to enter some command.
The command to list the contents of the current
folder is ls.
Type this command at the terminal prompt.
You'll probably see something like this:
cs245a@cslab14:~$ ls Desktop Downloads Pictures Templates workspace Documents Music Public Videos
You can also name a folder to list the contents of. Try
ls Desktop
...but that folder is probably empty, so the terminal will simply list nothing.
The following are the commands you'll need to know (you don't need to memorize these today, but become familiar with their names; you'll get used to how to use them gradually as you see examples):
mkdir to make a new directory (folder)
cd to change into a directory
cp to copy a file
mv to move or rename a file
rm to remove a file
pwd to find out where you are, that is, the
path to the working directory
Make a folder for this lab and move into it.
mkdir lab1 cd lab1
As in most labs and projects, I am giving you some code base to work on. Copy the following files from the course directory for this lab.
cp /homes/tvandrun/Public/cs245/lab1/* .
This gives you two files:
selection.c, a file that contains a stub for
writing the selection sort algorithm (which you will need to write)
together with some helper functions
and a main function to test your code.
substring.c a file that contains a stub for
writing a substring operation (which you need to write)
together with some helper functions
and a main function to test your code.
Open selection.c in gedit, emacs, or xemacs.
You will see it contains only a basic stub
for the selection_sort function.
This function takes (a reference to) an array and the size of the array
n.
Implement the selection sort algorithm:
i be the boundary position between the sorted
and unsorted sections; the array from 0 inclusive to i
exclusive is sorted, and from i inclusive to n
exclusive is unsorted.
i
i (moving the boundary, that is,
making the sorted section grow and unsorted section shrink)
Compile your code using
gcc selection.c -o selection
Once you have fixed any compilation errors, run the driver using
./selection
Use the results of the driver program to debug your implementation of selection sort.
You should remember the Java method substring()
by which you can make a new string from a sequence of characters
from another string.
You will write a similar function in C.
The protocol for the function you will write (you'll find this protocol
at the top of substring.c and a stub at the
end of the file.
For reference, the stub is
int substring(char source[], char destination[], int start, int stop);
Note that this function takes (references to) two arrays---the first
is the array we are copying from, the second is the array we are copying
the characters to.
You don't need to know their sizes; all you care about is where the string
ends (you have to assume that the arrays are big enough to hold the
respective strings).
The function also takes a starting index (inclusive) and
stopping index (exclusive).
It copies the subsequence source[start, stop]
to destination[0, stop-start]
and adds an end-of-string marker to position
stop-start.
However, to make this function extra robust, we want to make it
work even when "bad" values for start and stop
are given.
Here are the rules:
start is negative, we will assume they meant 0.
stop is less than or equal to start
or if start comes after the end-of-string marker,
this function will copy a "trivial" string of length 0.
stop comes after the end-of-string marker,
this function will copy only to the end-of-string marker.
Don't forget that the "destination" string must end in an end-of-string marker, even if a no characters are copied.
Compile with
gcc substring.c -o substring
Test with
./substring