lab02 : ASCII Art: Logical operators, integrating github into your workflow

num ready? description assigned due
lab02 true ASCII Art: Logical operators, integrating github into your workflow Tue 01/30 09:00AM Mon 02/05 11:59PM

Pre-lab prep

*Read through the entire lab, and identify parts that seem unclear to you. You can let your mentor know about this at the beginning of the lab.

Goals for this lab

By the time you have completed this lab, you should be able to

Skills Needed

By now, we expect that you are comfortable with these basic skills from lab00 and lab01 so we will no longer describe them in as much detail as we did previously:

Step 0: Check-in with your mentor

Below are the links to different sections of the lab:

Step by Step Instructions to getting setup with github

Step 1a: Do some initial ONE-TIME git configurations (this step has to be done individually)

   git config --global user.name "Alex Triton"

   git config --global user.email "atriton@cs.ucsb.edu"

  git clone git@github.com:ucsb-cs16-w18/cs16-w18-starter-code.git

Note that this repo contains the starter code for all labs (although only the code for the current is up to date). So, you don’t have to repeat the above step in subsequent labs.

Step 1b: Create a new repo, add your partner as collaborator and clone the git repo that contains the starter code

  cd cs16-w18-starter-code
  git pull

Never modify the code in the cs16-w18-starter-code repo directly because you are not the owner of that repo. Instead you should work on a copy of those files.

Step 2: Clone the repo in the pilot’s account and get the starter code

cd ~/cs16

git clone git@github.com:ucsb-cs16-w18/lab02_alily_jgaucho.git

cd lab02_alily_jgaucho

cp ~/cs16/cs16-w18-starter-code/lab02/* ./

You should see the following files:

$ls
backslash.cpp  README.md  starC.cpp  starL.cpp  starT.cpp  starZ.cpp

Step 3: Using the git command line tools to save the first version of your code

Its now time to use the git-command line tools to perform version control for the files in your git repo. The four essential commands we will be using are:

git pull
git add .
git commit -m "Initial version of lab02 files"
git push origin master

Go ahead and type them out on a terminal in your git repo (lab02_alily_jgaucho) directory. The above commands save a snapshot of your code on github. To check that this was done sucessfully open a web-browser and navigate to your repo on github. Then check to see that the starter code appears in your repo.

Note 1: Everytime you add a new piece of logic to your code you should save a snapshot of the latest version of your code by issuing the commands: git add … , git commit … and git push …. All the previous versions will be available to you as well and you have the option of reverting to older versions (We will see how in later labs). As you go through the rest of this lab you will essentially need to use these commands to keep track of the different versions of your code.

Congratulations on integrating git into your workflow! Now proceed to the programming part of this assignment.

Step 4: Create a team on submit.cs

What we’ll be doing in this lab: ASCII Art

There was a time when laser printers either hadn’t been invented yet, or were not yet widely available. Thus, the only kind of printer most folks had access to was something called a "line printer", which printed only from left to right, top to bottom, and could only print the kinds of characters you find on a typewriter keyboard.

So, you might find folks making pictures like this one, found at http://chris.com/ascii/

                                 .ze$$e.
              .ed$$$eee..      .$$$$$$$P""
           z$$$$$$$$$$$$$$$$$ee$$$$$$"
        .d$$$$$$$$$$$$$$$$$$$$$$$$$"
      .$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$e..
    .$$****""""***$$$$$$$$$$$$$$$$$$$$$$$$$$$be.
                     ""**$$$$$$$$$$$$$$$$$$$$$$$L
                       z$$$$$$$$$$$$$$$$$$$$$$$$$
                     .$$$$$$$$P**$$$$$$$$$$$$$$$$
                    d$$$$$$$"              4$$$$$
                  z$$$$$$$$$                $$$P"
                 d$$$$$$$$$F                $P"
                 $$$$$$$$$$F
                  *$$$$$$$$"
                    "***""  Gilo94'

For now, we’ll be keeping things much simpler: we are going to do some very simple ASCII art of letters, numbers and symbols, in order to practice with if/else and for loops.

The first few exercises will be very simple, but they get progressively more challenging.

An example for you to follow: starL

As an example, we will write a C++ function that returns a C++ string that when printed to cout, makes the shape of prints the letter L with stars, at any width or height, provided both width and height are >= 2

If either the parameter width or height is less than 2, the function returns an empty string.

The function will have the following function prototype:

string starL(int width, int height);

The following table shows various calls to this function, along with what the string returned looks like when printed using cout << starL(w,h);

The rule is that the L should have width at least 2, and height at least 2, otherwise the result is an empty string, and printing an empty string results in no output.

starL

So, this is a fairly easy function to write. This will do the job, and is provided for you as an example of how functions like this should be written.

To test whether this function works, we can write a simple main that takes the command line arguments, converts them to integers with stoi, and then passes those to the function:

What you’ll be doing

What you’ll be doing in this lab is writing three similar functions: startT, starC and starZ.

Sample values returned from starT

starT

Sample values returned from starC

starC renders the letters C, but requires a minimum width of 2, and a minimum height of 3. Otherwise it returns an empty string.

starC

Sample values returned from starZ

starZ renders the letters Z, but requires a minimum width of 3. It only takes one parameter, because the height and width are always assumed to be equal.

starZ

Step by Step Instructions

Step 1: Practicing with the starL program

First compile the starL.cpp file that you have in this week’s directory with the option (-std=c++11 ) as per the following command:

g++ -std=c++11 -o starL starL.cpp

Run the program with a few command line parameters. You’ll notice something special happens when you pass in the command line parameters -1 -1.

 ./starL 3 4
 ./starL 4 3
 ./starL
 ./starL 2 1
 ./starL -1 -1

With the command line parameters -1 -1, the program runs a set of tests on itself to make sure that the function starL inside the program is functioning correctly. So, you should be able to get some feedback on whether your code is correct before you even send it to the submit program. The code uses stoi to convert the argv[1] and argv[2] to integer values, and compare against -1.

Look over the code and try to understand how it works. When you feel ready, move on to the next step, and try tackling the starT.cpp, starC.cpp and starZ.cpp programs.

Step 2: Writing the starT program

Your job now is to start edit the starT.cpp program, which has a function inside of it that is a “stub”. That function does NOT produce the correct output—it always just returns the string “stub”. You need to replace that code with a proper implementation of starT. You can use the implementation of starL in the starL.cpp file as a model.

Compile your starT.cpp to the execuatable star. Suppose we want your program to draw a T with width 3 and height 2, we will run your starT executable as follows:

$./starT 3 2

In general the parameters to the startT program are width, followed by height. You should take this into consideration when writing your main function. To write the starT() function refer back to the description of starT earlier in this lab. You can also run the program with arguments of -1 -1 to run the internal tests and see whether your implementation is correct.

When you think you have a correct implementation, try submitting to the submit.cs system. You can submit just your starT.cpp program to see how far along you’ve gotten:

~submit/submit -p 922 starT.cpp

Note that this will show failures for starC.cpp and starZ.cpp, which are files that you’ll be working on at a later step.

You could also just submit the “stubs” for those—though those will fail some or all of the tests:

~submit/submit -p 922 starC.cpp starT.cpp starZ.cpp

Either way, for now, concentrate only on the test failures that pertain to starT.cpp and try to address any problems you encounter. If you fix these NOW before moving on to starC.cpp and/or starZ.cpp, you will likely have better success, because what you learn from fixing your mistakes will help you get those other parts solved more quickly and easily.

Some rules to keep in mind for the starT function:

Hints: recall that:

Also, for starT.cpp:

Usage: ./starT width height

Save the new version of your code with the starT implementation by typing out the following commands:

git add starT.cpp
git commit -m "Implemented starT()"
git push origin master

Step 3: Writing the starC program

Next, write the starC program. Follow the same basic procedure as for the starT.cpp program.

To get started, look at the table near the top of this lab that shows correct output for the starC program, as well as looking at the test cases in the runTests() function of the starC.cpp file in your directory.

Note that you’ll need to add some code to the main, but this time the rules are different. The minimum width is 2, and the minimum height is 3—everything else returns a null string (except for the values -1 for width and -1 for height—when passed in combination, the tests should be run.)

When:

then, you are ready to try testing your code on the submit system.

If you submit starC.cpp together with your starT.cpp program, your submit command will look like this:

~submit/submit -p 922 starC.cpp starT.cpp

(The order of the files doesn’t matter—list starT.cpp first, or starC.cpp first, aand either way, the result is the same.)

Note that failures for starZ.cpp may still show up, but we need not be concerned about those yet.

Concentrate only on the test failures that pertain to starC.cpp and starT.cpp and try to address any problems you encounter. Once all of those pass, move on to the starZ.cpp program:

Save the new version of your code with the starT and starC implementation by typing out the following commands:

git add starC.cpp
git commit -m "Implemented starC()"
git push origin master

Step 4: Writing the starZ program

For the starZ.cpp program, we have these rules:

The starZ function follows these rules:

Hints for the middle part of the Z:

-bash-4.1$  ./backslash
Usage: ./backslash width
-bash-4.1$ ./backslash 3
*
 *
  *
-bash-4.1$ ./backslash 5
*
 *
  *
   *
    *
-bash-4.1$ ./backslash 2
*
 *
-bash-4.1$ ./backslash 4
*
 *
  *
   *
-bash-4.1$

As with starC.cpp, you should add code to starZ.cpp so that you are able to invoke the internal tests by typing ./starZ -1 . Note that this time, there is only one parameter.

And, if there is not exactly one parameter, there should be an appropriate “usage” message that follows the pattern of the other programs—except that there is only a width parameter in this program.

When you have a version that can pass its internal tests, try submitting it along with your starT.cpp and starC.cpp to the submit.cs system.

~submit/submit -p 922 starC.cpp starT.cpp starZ.cpp

If there are errors reported, fix them.

When you have a clean build, you are nearly done with this lab. I say “nearly” done, because you should take one last look over the grading rubric to see if there is anything you need to adjust before doing your final submit and calling it a day.

Note: You MUST make one final submission that includes ALL of your files. For getting incremental feedback while working on the lab, it is fine to submit one at a time, but for GRADING purposes, your LAST submission (in time) must be a complete submission of EVERYTHING. In the ideal case (for you), that submission is completely “green”, i.e. all test cases pass, and you have a perfect score (at least from the standpoint of the points you are awarded for passing the test cases.)

If there are parts you can’t figure out, be sure to submit all of your files anyway to maximize the number of points you receive based on the parts that ‘'’are’’’ working.

Make sure you do a final git add .., git commit … and git push .. to make sure the latest version of your code is available on github.

Evaluation and Grading

Correctness

End of lab check off points: