18-642 Project 8
Updated 8/28/2022. Changelog
Learning objective: experience cleaning up code to pass moderate static
analysis; experience creating an automated build.
The amount of time it will take to do this project will depend upon how
messy your code is with regard to static analysis warnings. If you get stuck or
need a break from cleaning up warnings, you should start working on the build
package part of the project since there are minimal dependencies between the
two project halves. In general making build packages the first time takes many,
many iterations to resolve small issues. Leave some time -- if you wait until
the last minute you'll have problems.
Hints/Helpful Links:
- Please follow the handin naming convention: every filename (before the
file extension) must end in [FamilyName]_[GivenName]_[AndrewID].
- In this and future projects, $ECE642RTLE_DIR refers to
~/catkin_ws/src/ece642rtle (or corresponding project workspace).
- Creating the build package will require a bit of shell scripting skills.
See the tutorials referenced in the project 1
starting hints section if you don't have much background in that area.
- In future projects you'll need to update your design package to reflect any
changes you make in the code. Since you're concentrating on code cleanup for
this project the result should be minimal, so we're not making you hand in an
updated design package for this project.
- This project requires some scripting and basic knowledge of running
compilers.If you are not proficient at using command line tools and scripting
or other software development processes, we suggest you watch lectures 1-8 of
the MIT "Missing Semester" class:
https://missing.csail.mit.edu/
- See the Recitation video and slides on Canvas
Procedure:
- Compile your code checking for warnings:
- Modify line 67 of $ECE642RTLE_DIR/CMakeLists.txt from
set(proj8_flags false) to set(proj8_flags true). This turns
the following compiler warnings into errors: -Werror -Wextra -Wall
-Wfloat-equal -Wconversion -Wparentheses -pedantic -Wunused-parameter
-Wunused-variable -Wunused-value -Wreturn-type -Wunused-function
-Wredundant-decls -Wreturn-type -Wswitch-default -Wuninitialized -Winit-self
-O1
- Study the following lines in ece642rtle/CMakeLists.txt:
# Warning flags for Projects 8,9,10
target_compile_options(ece642rtle_student PUBLIC
"-Werror" # Do not comment this out after Project 8!
"-Wextra"
"-Wall"
...
)
These lines turn on the corresponding warning flags. If you would like to
temporarily suppress a warning flag (to cut down on noise while dealing
with other warnings), simply comment out the line with a "#." But
un-do that later -- all warnings need to be enabled for hand-in
- Build your code using the command catkin_make ece642rtle_student
and take note of how many warnings (displayed as errors) you see.
- Fix the warnings by modifying your code as necessary.
- Hand in a version that builds clearn (i.e., ZERO warnings generated when
all warnings above are enabled, including -Werror being enabled).
- Create a build package. This is a description of how the
build package needs to work. (We understand that there are better ways to do
build and test, such as Jenkins. But we're sticking with shell scripts to avoid
throwing a bunch of additional learning curves at you.)
- You'll submit a single gzip-compressed tar file: ANDREWID_P08.tgz
(ANDREWID should be replaced with your Andrew ID, preferably in all lower case
for this and other files listed below.)
- We'll copy that .tgz file into the home directory on a fresh copy of the
virtual machine. (The home directory is the directory you're in when you first
log in. By "fresh" we mean a copy of the VM downloaded from the
course web site that has never been mounted and never been run before. That way
everyone knows exactly what is there and what has been done to the VM before we
run your project on it.)
- We'll execute the command: tar -zxvf ANDREWID_P08.tgz
- This will unpack your submission and put it into various directories.
- Every file that needs to be added or modified needs EITHER to be in
the .tgz file OR to be created by the next step.
- From that same home directory we'll execute the command:
./ANDREWID_build.sh
- This shall do all the setup and building required to build and prepare the
VM and your code for execution. This is run exactly one time.
- This shall leave the user in the home directory when done.
- From that same home directory we'll execute the command
./ANDREWID_run.sh k
- This runs maze number k
- "k" is a small integer corresponding a maze number (e.g.,
ANDREWID_run.sh 1 runs maze #1)
- We'll enter control-C into the launching terminal when the maze has
completed
- We'll run this command as many times as necessary for grading on various
mazes, so it must clean up any messes it creates so it can be re-run multiple
times. That includes cleaning up background tasks, any other open windows, and
so on.
- This shall leave the user in the home directory when done.
- All files EXCEPT the .sh files shall be in a single tarball file named:
ANDREWID_files.tgz
- This means there is an outer tgz that has the entire submission
- INSIDE that outer tgz are some .sh files and another tgz that has
everything else
- The build.sh script should clean up files that come with the VM you don't
want and then expand the inner .tgz to set up your project file system.
- Be sure to check the hints section at the end of this assignment.
- All future projects will have this same hand-in format as a build package,
with additional commands or content added in to the above process based on the
project deliverables.
- Non-code hand-ins such as the writeup are included in a different file
package.
- Using alternate shell variants are permitted so long as you handle invoking
the correct shell processor in your scripting. Don't ask TAs to switch shells
before running your scripts.
- Answer the following questions in a writeup: (Include your
name at the start of the writeup. (If the writeups are printed out, the file
name info is lost, so put your name and Andrew ID in the document text as well)
- How many warnings did you get in Step 1c (before you fixed warnings)? Which
one (if any) was the most surprising?
- Which warning was the most difficult to get rid of? What lesson did you
learn from this experience?
- A screen shot indicating that your code compiles clean (without warnings).
The screen shot should include both the command line executed (listing lines
from the make file suffices) and a command showing a manually invoked make
process finishes with no warnings.
- A screen shot indicating that the _build.sh process works showing the tar
extraction command and the build command running to completion.
- A screen shot indicating that the _run.sh process works showing the _run.sh
command and a maze window for maze 1.
- Screen shots showing how well mazes 2, and 3 work. You do not have to solve
the mazes (yet), but your code must compile, run, and the turtle must leave the
start square in the maze.
- Did cleaning up warnings fix any bugs or improve performance on mazes 1
through 3?
- Do you have any feedback about this project? (Include your name in the
writeup)
Handin checklist:
Hand in the following:
- Your build file: AndrewID_P08.tgz
- Your writeup, called
p08_writeup_[FAMILYNAME]_[GivenName]_[AndrewID].pdf the elements of the
writeup should be integrated into a single .pdf file. Please don't make the TAs
sift through a directory full of separate image and text files.
Other requirements:
- Use the usual project naming conventions with a prefix of "p08"
for items other than source code.
- The writeup shall be in a single acrobat file for ease of navigation.
- Fonts for all diagrams and text shall be rendered at no smaller than 10
point font. Smaller fonts will require a resubmission
Zip the two files and submit them as
P08_[FAMILYNAME]_[First name]_[Andrew ID].zip.
The rubric for the project is found here.
Hints:
- You might wish to turn warnings on one-by-one while fixing them
- If you want to learn more about writing portable C code, also enable this
flag: -std=c11 to avoid GNU-specific extensions
- You should check to make sure your turtle still solves mazes once in a
while when cleaning up the code. (You are using version control, right? If the
turtle behavior breaks this is a good time to revert to a previous version.)
- The "-Werror" flag turns all warnings into errors, which ensures
you will notice and correct warnings. If you need to check if your code
compiles and runs before you have fixed all of the warnings, you may comment
the "-Werror" flag out. Just be sure that it's not commented out when
you are counting your warnings and submitting code for this and future
projects.
- Caution -- if you attempt to re-make a built file that has not been changed
the make command might do nothing. This does not mean your code is fixed -- it
means the compiler didn't run on it if you'd previously suppressed -Werror. Be
sure your make command is actually compiling affected files.
- The scope of the clean make is student-written code (the turtle, the maze,
and helper functions). You do not have to clean up files that you have not
changed.
- You should submit/tar 'ece642rtle' directory. DO NOT SUBMIT the whole
'catkin_ws' directory. This means that all your changes should be limited to
'ece642rtle/' plus any scripts you choose to place in the home directory
itself.
- Before you hand in, get a clean copy of the VM and execute the TA grading
procedure as specified above (the sequence of un-tar, build, and run commands
shown when explaining the build file requirements). In other words, test what
you plan to hand in.
- Make sure the permissions are correct (of your build script and any other
script that it may call). Do not expect the TA to do `chmod +x ...sh` on your
behalf.
- Assume that your build will run on a clean VM with only catkin_ws
directory. You can assume that there would be 'src' directory as well inside
'catkin_ws'.
- Please refer to earlier projects for the correct build command sequences
for a fresh VM.
- The 'devel/' and 'build/' directories do not exist in a clean VM image, so
you must include 'catkin_make <no arguments>' inside your build package
to be called from '~/catkin_ws'. You can also include 'catkin_make clean'
before the 'catkin_make' command to be on a safer side.
- Be sure that your build script changes directories back to the directory
that has the run script. (We suggest this is be the home directory, which is
where the build directory has to be.)
- You must not launch additional shells/terminals to run monitors. You
must not assume that TA will spawn another terminal to run your monitors. You
must run the monitors in the background in the same shell. Entering CTRL+C into
the launching command terminal must kill all the associated processes.
There should not be any background processes running. It is important you
understand what a Unix "background process" is and how to use the
"&" character to invoke one (there are many, many tutorials on
the Web on this topic). If you don't use background processes properly you will
encounter problems.
(If you have hints of your own please e-mail them to the course staff and,
if appropriate, we'll add to this list.)
- 8/28/2022: Released.
- 10/20/2023: updated with font size requirement