Lab #4: Project #1 checkpoints Get the various points in this lab checked off by a TA by the last lab of Tuesday, 2 October. It would be good, of course, to have them done the FIRST week! Indeed, you will probably want to have done a good deal of the implementation work prior to coming into lab for checkoffs. REMINDER: There are on-line changes to the project description. Be SURE you have read and recorded them! In order to do the steps below, you need to have copied over the ~cs61b/hw/proj1 files. We have named this file README.lab4 so that you can safely put it in the same directory. In what follows, I assume you are in a directory that contains the Project#1 files, possibly already modified by you. 1. Fill in User-Manual (I suggest, of course, that you do this OUTSIDE the lab and just have it ready for check-off). Condense this down and implement the printHelp command. 2. Place the file mcalc.prj, included with these lab4 files, in the directory you are using for your Project #1 development. Execute in a shell the command prcs populate This should tell you that some number of files "were added" (to mcalc.prj). Look at mcalc.prj in Emacs to see the list. Now execute the command prcs checkin in a shell. PRCS is a source-code control system, documented in your lab reader. For this lab, we make only cookbook use. I am trying to develop in you the habit of using such tools. The checkin command makes a copy of all the files listed in mcalc.prj in a directory called ~/PRCS. You can modify the files in your Project#1 directory as much as you like, and re-issue the checkin command above as often as you like (in your top project 1 directory, not in the mymath subdirectory). PRCS will take a snapshot of all files listed in mcalc.prj, and keep it around permanently so that you can always restore your files to what they were at any of these checkins (don't worry: it doesn't make a complete copy each time; it is clever enough to store only the changes). As long as you are careful never to erase ~/PRCS, as long as you checkin your files frequently, you will be able to roll back to a previous point at any time. 3. Remove any .class files in your project by issuing a 'gmake clean'. command. In Emacs, use the compile command (C-x C-e or the menu) to execute 'gmake test'. The first thing this command does should be to try to recompile your files (if it doesn't, you've broken something; unbreak it and try this step again). Examine Project #1 Makefile. What is it in this Makefile cause gmake to recompile your files? Assuming your files compile, 'gmake test' will then run the two test cases, which should fail (unless you've already implemented this part of the project!) What do the messages you get in response to this mean (e.g., the lines that start with "<", or things like "1,2d0"? What Unix command produced those lines? NOTE: I said "In Emacs", and I meant it. If you are NOT using Emacs commands to run all compilations and test scripts, and are instead issuing commands in a shell, you are SEVERELY handicapping yourself in the long run. Emacs, properly used, or (for those of you at home) an IDE (Integrated Development Environment) offering the same compilation-control features prevents errors, keeps your screen uncluttered, and speeds up your interactions considerably. And always remember: I can ask ANYTHING on an exam! 4. How does the Makefile use test-filter? Why do you suppose I included it? 5. On the basis of the project specification and your User-Manual, devise a set of test cases in the style demonstrated by the test*.* files provided for Project #1 and update your Makefile to run them. Start with a file of simple tests that uses only numbers, [, ], and =. Then try a file using just numbers, arithmetic operations and =. Use "#" comments in both of these test files to describe what they're supposed to test (and incidentally to test the # is working!). Now a file using just numbers, pop, dup, exch, and = to test stack manipulation. Next a test of the ':=' and '=:' operators. Then a file with matrix operations---scalar multiplication and division, matrix (and vector) addition and subtraction, matrix (and vector) multiplication. Then some tests with errors in them, one error per file (why just one?). Check as systematically for error cases as regular ones: there can be syntax errors, stack underflows, non-conforming arrays, divisions by 0, and so forth. Again, it is best to do all of this outside of lab, and just have it checked off. 6. Use the commands prcs populate prcs checkin in your Project 1 directory to add your test cases to the repository. The steps above do NOT require you to implement any part of the mcalc program; your tests ought to work on anyone else's project as well, for example. Now we turn to implementation. 7. Choose a representation for Quantities, and define the necessary fields (which should be private) and constructors (you may add others later, but make a reasoned guess based on what the class has to do). Implement also the accessor methods r(), c(), and the two elt methods. Put a description of the representation in the INTERNALS document. Remember that under the updated project description, we are equating scalars with 1x1 matrices, row vectors with 1xn matrices, and column vectors with mx1 matrices, even though this mathematically abusive. Get what you have written to compile, and then use prcs checkin NOTE: Simple, obvious implementations are possible (and encouraged if they help you get the job done). The more ambitious among you might like to think about this PUZZLE: How can I represent a Quantity so that the transpose operation, the row(*) operation and the col(*) operation take a constant amount of time (regardless of how big the matrix is)? The answer depends crucially on the fact that a Quantity, once constructed, is never changed. 8. Now complete the parts of mcalc that push scalars on the stack and handle "#"-style comments (and use 'prcs checkin', of course, when you get them to compile). 9. Devise a way to test whether your answer to (5) is working (we haven't implemented print yet, remember!) by running your program so far on a suitable test file and using gjdb to examine the fields of the Quantites that result (how do you look at the contents of a Stack with gjdb?) 10. Now implement enough of mcalc to row push vectors on the stack and again check using gjdb. (Do I need to say "and use 'prcs checkin' when they compile"?) 11. Now implement print on Quantities and the '=' operator in mcalc. At this point, at least one of the test files you did for (4) above ought to start working. Debug until they do. 12. Now's as good a time as any to take care of some odds and ends: printing prompts (you will have to add a case to our switch statement), and implement the exch, dup, and pop commands. Make sure this all works. 13. Fill in the code that handles errors to do something reasonable. 14. In all of these steps, whenever you modify your files and get them to compile, CHECK THEM IN. Whenever you ADD a new file (a test, or possibly a new source file, if you decide you need a new class), use 'prcs populate' and then 'prcs checkin'. It does NOT hurt to checkin or populate often, because the system saves only your changes each time. If you ever want to see what you have changed since the last checkin, use prcs diff Each of your checkins has a number: the first was 0.1, then next 0.2, and so forth. The command prcs info Lists all of these, and says when they were checked in. You can compare your current files with any previous checkin, version 0.n, using prcs diff -r0.n If you ever want to restore a previous version, FIRST CHECKIN WHAT YOU HAVE (important!), and then use prcs checkout -r0.n Just plain prcs checkout restores the latest version. 15. Choose a strategy for handling the := and =: operators (for the purposes of the lab, I'm not asking for an implementation). What field declarations will you need, and how will you use them? Describe this plan in your INTERNALS document. 16. Have your TA check off that you have substantially completed the points here (there is still plenty to do: implementing arithmetic, :=, and =: among others, but it would be good to be AT LEAST as far along as suggested by this lab).