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 Wed 04/17 08:00AM Tue 04/23 11:59PM

This is an individual lab, however, you are allowed to discuss the concepts with your labmates.

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:

Below are the links to different sections of the lab:

Step by Step Instructions to getting setup with github

Step 1a: Initial ONE-TIME git configurations

   git config --global user.name "Sam Gaucho"

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

Next, generate a private/public key pair and upload your public key to your github account. To do this refer to this tutorial: https://ucsb-cs56-pconrad.github.io/topics/github_ssh_keys/. In the process of setting up your key pair, when asked for a passphrase just press enter. By doing this step you will avoid having to enter a password or passphrase everytime you push your code to git.

Step 1b: Create a repo on github in our class organization

For this lab and all subsequent programming assignments, you should start by creating a repo in the ucsb-cs16-s19-ykk organization. You may not receive any credit for this lab if you do not create the repository under the organization (i.e., do NOT create it in your own account).

Make sure that when you create a repo, the Owner is the ucsb-cs16-s19-ykk organization (NOT your personal account).

IMPORTANT. If you haven’t completed the “Setup GitHub and add yourself to our organization” steps from Lab00, then make sure you do it now, otherwise, you won’t be able to access the organization and follow the steps below.

When you verified that your GitHub account is associated with the correct email address (see Lab00 instructions), you can follow these steps to create a new repo:

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

cd ~/cs16

git clone git@github.com:ucsb-cs16-w19/lab02_jgaucho.git

cd lab02_jgaucho

cp /cs/faculty/ykk/cs16/labs/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 from your git repo 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: Every time 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. As you go through the rest of this lab you will 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.

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 gradescope. 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 starT. 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.

Usage: ./starT width height

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

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.

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:

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 gradescope.

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 gradescope.
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. 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:

You must have good header comments: first line should be the name of your file, followed by date of creation, author and a brief description of the program. You must use curly braces in the body of all control structures (if-else, for and while) even if they contain a single statement. You should not mix tabs and spaces when indenting your code and use consistent indentation.