Fall Semester 2005: September 8, 2005 - December 12, 2005
Out on:
September 20, 2005
Due by:
October 2, 2005 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Collaboration:
Pairs
Grading:
Packaging 10%, Style 10%, Performance 10%, Design 20%, Functionality 50%
The second assignment for 600.211: Unix Systems Programming is a potpourri of problems, all somehow related to hashing once again. You'll need a partner for this one, watch out for details on the course mailing list.
Your first task is to perform a mutual code review.
Exchange the code you submitted for Assignment 1 with your
partner.
Read it over, making notes about good as well as bad things
as you find them.
Then set up a meeting with your partner and go over the code
together.
The goal is to come to an evaluation of both implementations,
an evaluation that both of you can agree on.
If there is a point you cannot seem to agree on, simply note
that: no use fighting about it for too long.
Finally, write up your evaluations of both implementations in
a plain text file REVIEW; please be clear about
whose code and what files your comments are referring to.
Your next task is to refactor your hash table code from the previous assignment to conform to a common interface. Designing the interface is part of the assignment, and you should all do that on the course mailing list. It will be quite important that everyone implements the same interface down the road. Here are some basic hints about what should be supported:
table_new and table_delete
to create and destroy a hash table; it should be possible to
provide a size hint, select whether or not the table can be
resized automatically, and of course provide the hash function
to be used
table_insert and table_remove
to insert a new key/value pair or remove a key/value pair (by key)
table_put and table_get to
update the value for an existing key and return the value for
an existing key
The interface should be declared in a file table.h
while the implementation (including the details of how a hash
table is organized) should be in a file table.c.
Again, you are supposed to design the interface,
that is the contents of table.h,
through discussion on the course mailing list.
Once you all agree on a design I reserve a last chance to veto
it, but I hope that won't be necessary.
Once the interface is final,
you need to write table.c,
the actual implementation.
You do this with your partner, based on either of your original
implementations.
Your final task is to use your hash table abstraction to
implement sspell, a simple spell checker.
For simplicity sspell always reads the text
to be checked from standard input.
If sspell finds any words it doesn't know,
those will be written to standard output separated by
line feeds; if all words are known, no output should be
produced.
The default dictionary is the "standard" dictionary file
for the system you're running on,
e.g. /usr/share/dict/words on OS X 10.3
or
e.g. /usr/share/lib/dict/words on SunOS 5.6;
the option --dictionary or -d
should allow the default dictionary to be overridden.
indent tool can be quite helpful to ensure that
your code is formatted in a consistent way...
Please turn in a
gzip
compressed
tarball
of your assignment (the extension should be .tar.gz).
The tarball should uncompress into a directory
cs221-assignment-2-login
with login replaced by your Unix login name
(so I would use cs211-assignment-1-phf);
uncompressing should not create any other files
in the current directory.
The tarball should contain no derived files whatsoever,
but allow building all derived files with
make.
We expect that your Makefile handles "the usual" targets
like clean and test aside from all
(which is the main way we will build your program).
Include a README file that briefly explains what the
program does and contains any other notes you want us to check out
before grading; make sure the README lists
both partners in a pair!
Include other "common" files such as INSTALL describing
how to install your tool, CREDITS to pay your respects
to the people whose code you're reusing, and LICENSE
to describe copyright and distribution terms if you feel like it.
You can look at any number of "famous" open source projects to see
what kind of structure is appropriate;
gif2png
is a relatively small example, but you don't need everything in
there.
Aside from your code, what you really need is a README
and a Makefile that works. :-)
For reference, here is a short explanation of the grading criteria.
Packaging refers to the proper organization of the
stuff you hand in, following the guidelines for Deliverables above.
Style refers to C programming style, including
things like consistent indentation, appropriate identifiers,
useful comments, etc. Simple, clean, readable code is what you
should be aiming for.
Performance refers to how fast your program can
produce the required results compared to other submissions.
Design refers to proper modularization and the
proper choice of algorithms and data structures; often this can
be judged by asking "How hard would it be to add feature X?"
and "How hard is it to replace algorithm X with algorithm Y?".
Functionality refers to your program being
able to do what it should according to the specification
given above; if the specification is ambiguous and you had
to make a certain choice, defend that choice in your
README file.
If your program cannot be built you will get no points whatsoever.
If your program cannot be built using
make
we will take off 10%.
If your program cannot be build without warnings using
gcc -W -Wall -O -ansi -pedantic
we will take off 10% (except if you document a very good reason).
If your program fails miserably even once,
e.g. segfaults or runs forever,
we will take off 10%.
If you really want to impress us, add some kind of "cool" bonus
feature to your program.
We won't give you extra points, but we'll give you extra kudos. :-)
Be sure to point out any bonus features you have in your
README file.