Projects

Project 2: The final frontier

posted Dec 19, 2016, 6:51 AM by JonAlf Dyrland-Weaver   [ updated Jan 23, 2017, 8:20 AM ]

PROJECT DUE: 8am Tuesday, 1/24

PROPOSAL DUE: 8am Friday, 1/6

Important note: In order for me to modify your design document, you must add me to your github repo. Please use the account stuydw. 

Description
The final project is to be a significant piece of work that illustrates many of the ideas and techniques studied in the class. Highlights include:
  • Allocating memory.
  • Working with files.
  • Finding information about files (stat and such).
  • Processes (forking, exec etc.).
  • Signals
  • Pipes (named and unnamed).
  • Shared memory, semaphores.
  • Networking.
You should work with at least one partner, groups of 3 are acceptable. Larger groups require my approval.

Documentation Specifications
In addition to your code files, you will have to include the following documents:
  • Makefile This should build the project when I type make.
  • README This should list project members, how to compile and use your project and a list of all the files that should be in the repository.
  • DESIGN The design document
  • DEVLOG
Design Document
Each student or group must create a file in their repository named DESIGN. The file should be a plain text file and it should contain the following.
  • The names of the people in the group.
  • A statement of the problem you are solving and/or a high level description of the project.
  • A description as to how the project will be used (describe the user interface).
  • A description of your technical design. This should include:
    • How you will be using the topics covered in class in the project.
    • How you are breaking down the project and who is responsible for which parts.
    • What data structures you will be using and how.
    • What algorithms you will be using, and how.
  • A timeline with expected completion dates of parts of the project.

Proposal Stage:
  1. Put together an initial design document with all the parts that are required.
  2. Upload your design document to github
  3. I will read the design documents, and when I approve them I will put at the very top of the file: DW APPROVED
  4. After that point you can go ahead and work on the project.

Project Notes
You can use any external libraries you'd like, for example, gtk for windowing, sdl for games, etc. but you must do the following:
  • Make sure to mention any libraries in the README where you describe compiling instructions.
  • Check with me to make sure we can install them.
  • Make sure your program will run in the cs lab computers.
  • Make sure they don't trivialize a systems programming aspect of the project.
  • If you are doing networking, make sure to specify the IP address and port in an include file. You should test with 127.0.0.1. That's the "loopback" address, it connects to itself. You can use that to test even if your machine isn't connected to the internet.

Project 1: Getting out of your shell

posted Nov 21, 2016, 6:42 AM by JonAlf Dyrland-Weaver   [ updated Dec 1, 2016, 8:48 AM ]

Project Due: Friday 12/2 11pm

You (and up to 2 partners) are to write a shell. The shell should implement as many of these features as possible. The first being the most basic up to the last which is the most complex.
  1. Read a line at a time, parse the line to separate the command from its arguments. It should then fork and exec the command. The parent process should wait until the exec'd program exits and then it should read the next command.
    1. Note: exit and cd cannot be run through a forked child process, you will have to implement these commands on your own.
  2. Read and separate multiple commands on one line with ;. That is, the line ls -l ; echo hello should first run the command ls -l and thenecho hello. I would recommend parsing the line on ; and then calling whatever you wrote for part 1 on each command. 
  3. Implement simple redirection using > (redirecting stdout) and < (redirecting stdin). - This will be explained in class on Tuesday, 11/22
  4. Implement simple pipes, that is: ls | wc would run ls and use the output from ls as the input for wc. - This will be explained in class on Tuesday, 11/22. 
All of these commands work in bash, so use it to check out the functionality of each feature if you are unclear about anything.

Specific requirements
  1. Every function you write must have a function header describing the arguments, return value and what the function does.
  2. You should have a readme file with the following:
    1. A description of what features your shell implements
    2. A description of what features you attempted to implement but were unsuccessful
    3. Any bugs or things you want me to know about your program
    4. A copy of every function header
    5. An example of the readme file can be downloaded from this page (see "Attachments" below)
  3. This project should use separate C files as necessary.
  4. The project should be built using make and a makefile, I will only compile by using make. 
Project hints (If you're having trouble)
  1. To make your life easier, you could require that all items on the command line are to be separated by a single space.
  2. When parsing the line, it might help to count the number of tokens (individual pieces), before using strsep (remember the strchr function?)
  3. You can restrict the locations and ordering of > and <. 
  4. You can limit piping (|) to a single pipe. 
If you would like to implement other features after getting these ones down, please do. Look at what bash does and see what else you can implement!

Github links (one directory per group):
https://github.com/mks65/shell.git

Project 0: myTunez

posted Oct 13, 2016, 6:41 AM by JonAlf Dyrland-Weaver   [ updated Oct 19, 2016, 7:23 PM ]

PROJECT DUE: 8am Friday 10/21

You may work with up to 1 other person. Create only one git directory per group, put both names in the directory name.

Write a program in C that implements a music library organizer. The data structure should consist of an array of 26 slots, one for each letter from 'a' to 'z' (you can convert everything to lower case to make comparisons easier). Each slot will contain a linked list of all the artists that have names with the corresponding letter. When you add a song, it should go on to a linked list at the appropriate array slot in the correct position alphabetically. Assume no duplicates..

Your nodes/links should be able to hold a song's title and artist. You might use structures like the following:
typedef struct song_node{ 
  char name[256];
  char artist[256];
  struct song_node *next;
} song_node;


//and later:

song_node *table[26];

You should start by making your linked lists work with the following functionality:
  • insert nodes at the front
  • insert nodes in order
  • print the entire list
  • find and return a pointer to an individual song based on song name
  • find and return a pointer to the first song of an artist based on artist name
  • Return a pointer to random element in the list.
  • remove a single node from the list
  • free the entire list
Then create your array of linked lists for the full program and have the following functions:
  • Add songs.
  • Search for a song.
  • Search for an artist.
  • Print out all the entries under a certain letter.
  • Print out all the songs of a certain artist
  • Print out the entire library.
  • Shuffle - print out a series of randomly chosen songs.
  • Delete a song
  • Delete all the nodes.
Files you should have:
  • A .c file that contains the main function you use to test all your work
  • At least one set of .h/.c files
    • For example, you can put your struct definition and your linked list headers in a .h file
    • You may also want to set up a .h/.c set for the playlist specific functions and a separate set for the linked list functions.
  • A makefile that will compile all the parts of your code and generate a single executable program
Git clone link:
https://github.com/mks65/tunez.git

You must test all the functions in your main function in order to receive full credit!!!

Example of reasonable testing output:

Testing find:
p artists: pearl jam - alive pearl jam - even flow pearl jam - yellow ledbetter pink floyd - time 
looking for *pearl jam - alive*
pearl jam - alive
looking for *pearl jam - time*
song not found

Testing find_artist2:
looking for *pearl jam*
pearl jam - alive pearl jam - even flow pearl jam - yellow ledbetter pink floyd - time 
looking for *pink floyd*
pink floyd - time 
looking for *pusa*
artist not found

Testing print_letter
p list
pearl jam - alive pearl jam - even flow pearl jam - yellow ledbetter pink floyd - time 

Testing print_library
a list
ac/dc - thunderstruck 
p list
pearl jam - alive pearl jam - even flow pearl jam - yellow ledbetter pink floyd - time 
r list
radiohead - paranoid android radiohead - street spirit (fade out) 

Testing remove_song
removing: *pearl jam - alive*
a list
ac/dc - thunderstruck 
p list
pearl jam - even flow pearl jam - yellow ledbetter pink floyd - time 
r list
radiohead - paranoid android radiohead - street spirit (fade out) 

removing: *pearl jam - yellow ledbetter*
a list
ac/dc - thunderstruck 
p list
pearl jam - even flow pink floyd - time 
r list
radiohead - paranoid android radiohead - street spirit (fade out) 

freeing node: ac/dc - thunderstruck
freeing node: pearl jam - even flow
freeing node: pink floyd - time
freeing node: radiohead - paranoid android
freeing node: radiohead - street spirit (fade out)
Testing print_artist:
pearl jam - alive
pearl jam - even flow
pearl jam - yellow ledbetter
pink floyd - time

Testing shuffle
pink floyd - time
pearl jam - alive
pearl jam - even flow

1-3 of 3