1. Obtain a remote repository with the starting code for the problem set by visiting didit.csail.mit.edu. Find psets/ps0 under New assignments and create a repository. You will only be able to create a repo after the course signup forms are processed and the problem set is announced.

   • If you can’t create a repo after the announcement, you are not registered for 6.031. Contact the staff (how?) to check your status.

   • If you are listener or not taking 6.031 for credit, you can’t create a repo. See instructions below to clone from a read-only remote.

2. Open the terminal (Git Bash on Windows) and go to the directory (using cd) where you would like to store your code; for example, that might be a directory named Source in your home directory.

   Getting Started step 5 introduces the command line.

3. Clone your repo. You will access the remote repository over SSH from your laptop.

   Note: Getting Started step 6 has setup you must perform before using Git.

   Find your clone URL at the top of your psets/ps0 page on Didit. It will look like this, with your username filled in:

   ssh://«username»@athena.dialup.mit.edu/mit/6.031/git/sp18/psets/ps0/«username».git

   In the terminal, run this command, filling in the URL:

   git clone «URL» ps0

   The result should be a directory named ps0 with the starting code for the problem set. Keep the terminal open — you will also use it to commit your code.

   • If git clone says “does not appear to be a git repository” or “could not read from remote repository”, check your repository URL for typos. Make sure your repository is listed on Didit.

   • If git clone reports a “protocol error” or asks for your password but then does nothing, you should review any changes you made to your Athena dotfiles, especially .bashrc.mine and .bash_environment. Ask a TA for help if you are not familiar with Athena.

   • If you are a listener or not taking 6.031 for credit, you can clone problem set repositories using a modified command: replace the last instance of [username] in the URL above with didit/starting. You will not be able to push to this repository, it’s a read-only remote.

4. After cloning your repository, add the project to Eclipse so you can work on it.

   Note: Getting Started step 4 has setup you must perform before using Eclipse in 6.031.

   To import a project:

   • In Eclipse, go to File → Import… → General → Existing Projects into Workspace.
   • Select the root directory of your clone by clicking “Browse…” and navigating to it.
   • Make sure the project is checked, make sure “Copy projects into workspace” is not checked, and click Finish.

1. Your first task is to implement drawSquare(Turtle turtle, int sideLength), using the two methods introduced above: forward and turn.

2. Once you’ve implemented the method, run the main method in TurtleSoup.java. To run main, right-click on the file TurtleSoup.java in the Package Explorer on the left side of Eclipse, go to Run As, and select Java Application.

   This main method creates a new turtle, calls your drawSquare method, and instructs the turtle to draw on screen. A window will pop up, and, once you click the “Run!” button, you should see a square drawn on the canvas.

1. First, in the terminal, change directory (cd) to your clone, and take a look around with

   git status

   which shows you files that have been created, deleted, and modified in the project directory. You should see TurtleSoup.java listed under “Changes not staged for commit.” This means Git sees the change, but you have not (yet) asked Git to include the change as part of your next commit.

2. You can run the command

   git diff

   to see your changes. (Note: when the diff is more than one page long, use the arrow keys. Press q to quit the diff.)

3. Before committing, files must be staged for commit. Staging a file is as simple as

   git add <filename>

   so use

   git add src/turtle/TurtleSoup.java

   to stage the file. You should also stage the test file if you’ve added more tests.

4. In addition, it’s always a good idea to review your commits before committing to them. Run

   git status

   again to see that your changes are now listed under “Changes to be committed.” If you run

   git diff

   those changes are no longer shown! Use

   git diff --staged

   to see exactly what Git will record if you commit now.

5. Ready? To perform the commit,

   git commit

   will actually commit the changes locally, after opening your default editor to allow you to write a commit message. Your message should be formatted according to the Git standard: a short summary that fits on one line, followed by a blank line and a longer description if necessary.

   If Git warns you about configuring your default identity or you can’t edit your commit message, you did not follow the instructions in the Getting Started guide. Getting Started step 6 has setup you must perform before using Git.

   Now run

   git status

   once more, and see that your changes are no longer listed.

6. You can use the command

   git log

   to see the history of commits in your project. Right now, you should see two of them: the initial commit to create your problem set repository with the starting code, and the commit you made just now.

   Important: only the local history has the new commit at this point; it is not stored in your remote repository. This is one important aspect where Git is different from centralized systems such as Subversion and CVS.

7. In order to share the changes with your remote repository (which is the one we will be using for grading), you need to push to the remote repository, with

   git push origin master

   At this point, the remote repository on Athena now has the same history as your local repository. It is important to remember that we will be grading the history in the repository on Athena; if you forget to push, we won’t see your commits.

1. Implement calculateRegularPolygonAngle.

   There’s a simple formula for what the inside angles of a regular polygon should be; try to derive it before googling/binging/duckduckgoing.

2. Run the public tests that we provided. In 6.031, we use JUnit, a widely-adopted Java testing library. We’ll see more about JUnit, and about testing in general, in an upcoming class. For now, let’s focus on running the provided tests against your implementation. By convention, JUnit tests are in a class whose name ends with Test, so the public tests for this problem set are in TurtleSoupTest.java.

   

   To run the JUnit tests in TurtleSoupTest, right-click on TurtleSoup­Test.java in the Package Explorer, and go to the Run As option. Click on JUnit Test, and you should see the JUnit view appear.

   If your implementation of calculateRegularPolygonAngle is correct, you should see a green check mark next to calculateRegular­Polygon­AngleTest in the list of results.

   The   big red bar   indicates that at least one test has failed. That shouldn’t surprise us, since the other tests are exercising methods we haven’t implemented yet. When all the tests pass, the bar will turn green!

   If testAssertionsEnabled fails, you did not follow the instructions in the Getting Started guide. Getting Started step 4 has setup you must perform before using Eclipse.

3. Try breaking your implementation and running TurtleSoupTest again.

   

   You should see a red X or blue X next to calculateRegular­Polygon­AngleTest in the JUnit view, and if you click on calculateRegular­Polygon­AngleTest, you will see a stack trace in the bottom box, which provides a brief explanation of what went wrong. Double-clicking on a line in the failure stack trace will bring up the code for that frame in the trace. This is most useful for lines that correspond to your code; this stack trace will also contain lines for Java libraries or JUnit itself.

   Try double-clicking on the line in the stack trace for calculateRegular­Polygon­AngleTest(), and look at the code for the test. On that line, you should see a call to your calculateRegular­Polygon­Angle implementation with particular values for its arguments, within a call to assertEquals() that checks whether your implementation’s return value was correct. A JUnit test generally has this form: it calls your implementation, then makes one or more assertions about the value that your implementation returned.

4. Enough breaking: fix your implementation so it’s correct again. Make sure the test passes with a green check .

   Passing the public JUnit tests we provide does not necessarily mean that your code is perfect. You need to review the function specifications carefully. In future problem sets, we’ll also expect you to write your own JUnit tests to verify your code.

5. Implement drawRegularPolygon.

   Use your implementation of calculateRegularPolygonAngle. To test this function, change the main method to call drawRegularPolygon and verify that you see what you expect.

1. Implement calculateBearingToPoint.

   This function calculates the parameter to turn required to get from a current point to a target point, with the current direction as an additional parameter. For example, if the turtle is at (0,1) facing 30 degrees, and must get to (0,0), it must turn an additional 150 degrees, so calculateBearingToPoint(30, 0, 1, 0, 0) would return 150.0.

2. Implement calculateBearings.

   Make sure to use your calculateBearingToPoint implementation here. For information on how to use Java’s List interface and classes implementing it, look up java.util.List in the Java library documentation. Note that for a list of n points, you will return n-1 heading adjustments; this list of adjustments could be used to guide the turtle to each point in the list. For example, if the input lists consisted of xCoords=[0,0,1,1] and yCoords=[1,0,0,1] (representing points (0,1), (0,0), (1,0), and (1,1)), the returned list would consist of [180.0, 270.0, 270.0].

3. At this point, JUnit should now show a green check for both calculateBearingToPointTest and calculateBearingsTest..

Commit to Git. Once you’re happy with your solutions for this problem, commit and push!