670 S '07


Important Messages from the Instructors

Monday, April 23rd, 2007

Good Bye

Richard will grade the remaining projects (12 and 13) this week; I have graded a select subset of your final code-walk memos. Friday morning, after I return from a quick trip, we will determine the final grades for this course.

I have enjoyed the semester a lot, and I hope you have, too. Some of the lessons may have sunk in now, and some will only reveal themselves in the future when you're out there, working on real projects. (I know you had little time to read the suggested reading. Take notes and find the chapters and papers when you'll need them.)

Keep us in mind; keep us posted; and good luck to you all.

Monday, April 16th, 2007

For your final code walk (Tues and Wedn), you will need to run your game administrator so that it can hook up with my players, and three of your players to work with my game administrator. You will find out what the IP number for my game administrator is right before the code walk, and you will determine your IP number so that I can fire up my players to look for your port. Show up 5-10 minutes early so that you have plenty of time to get things to run.

Monday, April 16th, 2007

The deadline for Project 13 was extended by two hours.

I have also made cosmetic changes to Project 13, and I have spelled out a hint concerning the client side. (See red text) -- Use case 1 was changed only as a hint. You're welcome to implement it in any way you know how to fire up a TCP recipient.

When you turn in Project 13, be sure to include scripts that compile/run the server and client programs independently.

For test fest "Project 10", my transmission routines inserted comments into non-empty elements with the intention of finally breaking programs based on regular-expression. The following is a legitimate END message:

<END><AIRCRAFT NAME="Bell P-39D" TAG="2" /><LIST /></END>
Adding a comment to this message is legitimate according to the rules:

<END><!--are you reg-exp-ing for </END>--><AIRCRAFT NAME="Bell P-39D" TAG="2" /><LIST /></END>
The embedded <END> text causes problems if you base the legitimacy test of tree-structured data on regular-expression matching. -- I mentioned this fact time and again during code walks and also reminded you that this fact is the subject of the first and key part of CS U 390, the only true prerequisite of the course.

Sunday, April 15th, 2007

[new] The numeric results results for test fest "Project 10" are now available. Please be suspicious of those test cases for which my player fails. While I won't pretend that my code is perfect, you have plenty of other test cases to worry about.

For two teams (bcawley-roner and jdg-khanh), the entries are 0/0/0 and the test result doesn't exist (404 error for links) due to their programs crashing our machine. We are investigating.

Saturday, April 14th, 2007

Another example why software quality from the hardware to the top-tier matters.

Friday, April 13th, 2007

After trying to run test fest 10 for the week, we still haven't succeeded to get through the whole matrix. [The unix clean-up actions don't seem to kill off run-away administrator processes.] For now, we are posting the test cases from test fest 10 and links so that you can run them on your own.

Monday, April 9th, 2007

The results of the test fest for project 9 are now available on-line. The most important use for you is to check out all available test cases and to get your administrative routines (interaction with player) to pass these tests.

Project 13 is available now. I need to add one transaction still; otherwise it's in shape.

Monday, April 9th, 2007

Also see below: For project 12, your run script must run a single game, without displaying the Player UI. This script's output should be the same as in project 11, except that it should also print out a one-line notification whenever a player exchanges a wildcard.

Friday, April 6th, 2007

Here are Richard's directions for turning in Project 12:

Create a Memos/Project12 directory, as specified in the blog post from Jan 23. For task 1, create a Task1 directory within Memos/Project12. Put all of your design documents here, in portable document formats: HTML, PS, PDF, JPG, GIF, PNG, TXT.

Your Task1 directory should also contain a file named Task1.html, which provides an overview of your design changes -- the kind of thing you might start with, should you happen to give a code walk for your project. This document should also explain what the rest of the files in the Task1 directory represent. See the blog post from 2/13 for formatting guidelines for this memo.

For task 3, simply submit a memo according to the standard directions (see blog posts from 1/23 and 2/13).

Tuesday, April 3rd, 2007

I have moved the due date for Project 12 from Good Friday to Monday. This also means that I will not publish Project 13 until then.

Sunday, April 1st, 2007

Andrew S. requested a clarification to the new game rule of Project 12 concerning the use of "discarded squadron with wildcard."

Thursday, March 29th, 2007

People have asked how the run-script should work for Project 11. There are two parts to the answer:
  1. Do *not*, by default, display the player UIs from project 8. We will penalize people for opening windows.
  2. After each game, print out a brief report that contains the (cumulative) score for each player and also indicates whether players were removed for cheating, contract violations, or other problems. All reports should be written to stdout and look something like this for a successful game:
      the war took 2 battles
      Matthew : 465
      Robby : 300
      Shriram : 10
    and more like that when bad things happen:
      the war took 2 battles
      Robby: CHEATED
      Matthias: BROKE CONTRACT
      Shriram : 0
    Your run-script should use between three and six players to run two or three games.

    Optionally, you may also print such reports after each battle. [No credit!]

Wednesday, March 28th, 2007

On Trusting Players

After watching the code walks yesterday and after receiving several inquiries on "trusting players", I have decided to provide some additional design suggestions.

When a Project specification requests that you check the player's actions for attempted cheating, you definitely may not assume that players are trustworthy. You can't trust the player's hand; its designer may have added code to add cards in between turns. You can't trust the player's scoring of course; why not add a few points here and there while the "dealer" isn't looking. So no, don't trust the player for anything. Just imagine an open competition where friends and classmates program to the same interface and plug in players with the only goal of winning the Squadron Scramble tournament at all costs.

When a Project specification requests that you develop an automated Squadron Scramble player with a decent strategy, then imagine yourself playing the game -- with the information that you get through the specified interface. Is it useful to keep track of your score? Is it useful to keep track of your discards? Your attacks? The discards of the rest of the players? In other words, does it help your planning efforts if you know that almost all cards have been discarded, i.e., you're nearing the end of a battle? Well, if it is, your automated player should keep track of these items.

Monday, March 26th, 2007

On Mar 26, 2007, at 7:33 PM, someone wrote:

1. Are there any restrictions to what our player implementations are allowed to know about the game? I know the specified interfaces are intentionally limited but shouldn't our players be able to know things like scores, size of other player's hands, and any card that is discarded to the Stack? More specifically, can they keep track of anything that they would be able to if the game was played in real life?

These sound like great suggestions for future extensions. For now, your player should know what it can find out through the functions/methods in the given interface. For everything else, you would need more guarantees.

2. Related to 1, can our player keep track of every card placed on the discard stack? Once again, this is limited by the interface but it's something that could conceivably happen in real life.

Since the player can inspect the entire stack during a turn, the answer is yes. Can it see cards that are played and disappear between turn n and turn n+1? No.

3. What happens when a player requests to register in the middle of the game?


Are they queued for a turn (and dealt a fresh 7 once they're reached) or are they forced to wait for the next battle before entering? I could make arguments for either approach.


4. When a player is caught cheating what happens to their hand? Placed aside before the nextBattle/newDeck?

Their hand is ignored. But again, this sounds like a great idea for a future change request.

On Mar 26, 2007, at 6:24 PM, someone else wrote:

For task 3, you want the optimal strategy, is this for a human player, knowing everything ... or ... is it for a squadron scramble computer player, where all they know about is ...

This should be "describe your best strategy" meaning the automated player that does best in your tournaments. Keep in mind that the interfaces are given. You may not assume any additional knowledge on the side of the player.

Just in case: my answers are in red.

Wednesday, March 21st, 2007

Richard writes that from now on, "the run-harness script should NOT display the Player GUI from project 8". (I bet he'll be unhappy and subtract points if you do.)

Tuesday, March 20th, 2007

Several pairs have emailed me with the following question:
Does play-one-turn know about the first hand that the player is handed? Doesn't it need the information to determine whether the player is cheating?
As you may have noticed, by this time in the semester, I leave it to you to organize your classes and methods. In a sense this is 213/370 material and you're capable of designing/implementing it. As you do so, keep in mind today's hint, i.e., Tester and Administrator are really one conceptual unit. So you can create one huge method, but then it becomes difficult to create internal unit tests. Or you can create two methods plus one that combines them; in this case, you need to figure out where to keep all the state. Choose wisely.

Monday, March 19th, 2007

Andrew S. and Andrea M-M. have independently discovered the lack of a test case element for cheating. I have modified MESSAGES4.txt to remedy this flaw.

Saturday, March 17th, 2007

Richard has installed administrators for Projects 6 and 7 that respect the one-message per line protocol.

Saturday, March 17th, 2007

The mid-term grades are now available on-line.. Read the "Overall" average as a predictor for the final grade as follows:
  • "ok+" is between an A+ and a B+;
  • "ok" is between a B+ and a C;
  • "ok-" is between a C and a D-; and
  • "0" is failing.
Keep in mind that these are projections based on past performance.

Friday, March 16th, 2007

The results of the test fest for Project 7 are finally on-line again. Now that I have fixed my XTRN vs TURN confusion, the results are three-times as good as before.

Friday, March 16th, 2007

Richard writes: As part of grading, I ran everyone's harness against a very simple test case (based on one of those used for the test fest). The actual input was provided as specified in the blog post from yesterday.

In this stage, I was only checking whether your harness completed the test case, not whether it produced the expected results. So, if your feedback report indicates that your harness ran successfully against this input, this means only that it did not crash, and that it produced output that looks vaguely syntactically valid given the project's specification. This statement does not guarantee that your system performed correctly against the test case.

Also, many teams lost a point for not documenting that the fourth argument to playOneTurn means: is it all of the discarded squadrons, or only the bombers? This was indeed up to you for this project, so you could choose either. Of course, your Administrator's client needs to know, so your choice needs to be documented in the Administrator interface. Further, your use of this argument must be consistent with its description: since Turn's constructor expects a list of the other players' discarded bombers as its 4th argument, then if you define playOneTurn to accept a list of all discarded squadrons, then you have to filter it accordingly before creating the turn.

Friday, March 16th, 2007

On the lighter side of things, Ventz Petkov writes "It's a little funny because it holds a lot of truth."

Thursday, March 15th, 2007

Someone asked:
Suppose the harness receives an ill-formed turn. In that case, it will send a CONTRACT message and close its input port before the administrator can send the GET-CARDs requests. Is this acceptable?
The answer is that this is not in the spirit of the assignment which says that "[t]he goal of these contracts is to prevent ill-behaved players from crashing the server or from upsetting its basic internal invariants." In this case, a bad test case designer would crash the test harness, and that's not what you wish to test. Instead you want to guard against this.

If you submit such a test case with an ill-formed test, my administrator will discover this flaw and throw it out.

Thursday, March 15th, 2007

Never mind! This was a bogus test fest. Thanks to Andrea for noticing the bug (eliminated).

The results of the test fest for Project 7 are now on-line.

You can run your test harness for the "play one round" method manually using the mechanism below.

To check how your players are doing directly, I recommend that you reorganize the test cases and run them manually as follows. Say case1 is in file case1.xml and looks like this:

<TURN name="a"><STACK /><STACK><AIRCRAFT NAME="..." TAG="2" /></STACK><LIST /><LIST /></TURN>
<END><AIRCRAFT NAME="..." TAG="2" /><LIST /></END>

Then run the test case as follows, assuming your test script is called harness-for-interact:

cat TestInteract/case1.xml | ./harness-for-interact
<TRUE />
<AIRCRAFT NAME="..." TAG="2" />
<LIST />
<STACK NO="1" />

You can now inspect the output and determine whether it is as expected.

Wednesday, March 14th, 2007

Richard writes that "I've put (a version of) the test-fest administrator into everyone's SVN directory" and:

Since several teams have asked about why their test cases failed, we have made our test fest administrator available to you to run. While you can't inspect the administrator (it's in compiled form), you can still instrument your own code to get additional information about exactly what's happening.

The test fest administrator is now in SVN, in your submission directories for projects 6 and 7. Within those directories, I've added several things:

    aircrafts/ (if you didn't already have this directory)

The administrator will only work on the CCIS Solaris network. To run it:

  1. If you still have copies of these turnin directories checked out, then update them. Otherwise,
     svn co http://svn.barzilay.org/670/**TEAM**/turnin/Project6
     svn co http://svn.barzilay.org/670/**TEAM**/turnin/Project7
    making the obvious replacement for **TEAM**.
  2. cd to Project6 or Project7, as appropriate.
  3. Invoke the run-admin-6 or run-admin-7 script. Each script expects two command line arguments: the script that starts your test harness (run-harness, if you followed our submission directions), and the directory containing the test cases (Tests/Project6 or tests/Project7, if you followed our directions).


Unfortunately, it's not the same one that we ran, so the students may see different error messages -- I'm pretty sure I made this tarball up before you added the various contracts to the codebase.

Tuesday, March 13th, 2007

Four remarks on Project 9:
  1. Ventz discovered an incomplete sentence in the problem statement. That's fixed.
  2. I have fixed the IO3 part, as discussed in class. For a regular esac case, your harness for the administrator must produce the specified outputs. For a TIMING case, it must send back a TIMING response and for a CONTRACT it must send back a CONTRACT response.
  3. I contemplated the requested change to TIMING cases, i.e., dropping the done part. I have decided against it. There is no harm in specifying a random result for the turn, but I do recommend keeping it short.
  4. Robyn asked an interesting question after class. Suppose you are specifying a TIMING case, but your second message is a request for too many cards from the stack. Which of these two violations should we expect? There are two answers:
    1. A timing error can only be discovered if the execution of a second request for cards is about to execute. Before your program can do this, however, your contract system must determine that the second call is legitimate. During this phase, it will discover a problem with the "entry" part of the behavioral contract (too many cards requested) and signal a CONTRACT error. The timing error will never be discovered.
    2. You should ponder the following question then: Is the testing language of Project 9 rich enough to express this case?

Monday, March 12th, 2007

The results of the test fest for project 6 are now available on-line.

Saturday, March 10th, 2007

As of Project 9 your XML facilities must deal with two common elements:
  1. COMMENTS. The test cases from Projects 6 and 7 have shown that people need comments in their test cases so that they can create a pattern with comments and fill in the gaps for the specific cases.
  2. ABBREVIATIONS. Your XML readers and parsers must tolerate both forms of elements without sub-elements, i.e., both <LIST> </LIST> as well as <LIST /> must work for the XML representation of the empty list.

Wednesday, February 28th, 2007

Ventz P. sent me this blog entry on Why Programmers Can't Program. This shouldn't happen to you, but just in case, I have included FizzBuzz in first-year coding style:

CS U 211, assignment 6/7/8:

  (define hundred (build-list 100 add1))
  ;; Nat Nat -> Boolean 
  ;; is n a multiple of m? 
  (define (multiple? n m) 
    (zero? (remainder n m)))
  (map (lambda (n) 
           [(and (multiple? n 3) (multiple? n 5)) "FizzBuzz"]
           [(multiple? n 3) "Fizz"]
           [(multiple? n 5) "Buzz"]
           [else n]))

CS U 213:

  class Main {
      public static void main(String argv[]) {
	  for(int i = 1; i <e; 100; i++) { 
	      if (multiple(i,3) && multiple(i,5))
	      else if (multiple(i,3)) 
	      else if (multiple(i,5)) 

      // is m a multiple of n? 
      public static boolean multiple(int m, int n) { 
	  return (m % n) == 0; 

Tuesday, February 27th, 2007

Richard found this little story on the importance of test harnesses. It's worth reading.

Monday, February 26th, 2007

Brian G. points out that last week's "fiasco" is possibly an instance of Joel's Law of Leaky Abstractions. Well, I admit that abstractions over physical things are often "leaky"; the underlying hardware shows through in some ways or others. But at the same time, I also think that what Joel really perceives here is a fact that some of us call the "51%" solution: the fact that working programmers are undereducated and produce software that just barely performs and then think that this is "okay."

In the spirit of testing, contracts and fighter planes: Slashdot has a great story today on the Raptor (F22)'s first flight south. Sadly enough this problem plagued the development of previous fighter planes, as you may recall from a lecture on bugs and testing etc a short while back.

Three blog posts in one day is enough. Really.

Monday, February 26th, 2007

Andrea and Andrew have discovered an omission from the MESSAGES.txt file: the fighter squadron must proceed the bomber squadron in the attack. The MESSAGE file is fixed now.

Monday, February 26th, 2007

As some of you have discovered, entering LARGE test cases is nearly impossible in Unix terminals. (I was unaware of this limit and hadn't encountered this problem in previous editions of the course.) So you must either give up on large test cases or implement the test administrator(s).

If you are interested in "purchasing" such a test administrator from Richard, please drop him a line. He will then place a test administrator (for Solaris) into your SVN directory (where we expected the administrator). The cost is 5 POINTS.

Sunday, February 25th, 2007

Richard writes: "In the past, we've specified that we run your process in an environment containing settings only for the PATH & TERM variables. Since project 8 requires you to create a graphical display, you may assume an appropriate setting for the DISPLAY variable."

Sunday, February 25th, 2007

Richard writes:
  1. the "run-harness" script should execute your test harness from Task 2; it should expect no command-line arguments and should perform *NO* input/output to stdin/stdout beyond that specified in the task. (I/O to other places is fine.)
  2. Any test cases you write for Task2a should be in Tests/Project7. We'll continue this convention for later assignments; I won't mention this again.
  3. WARNING: we were fairly lenient the first time around on handing files in the wrong location for Project6. Going forward -- and this includes your resubmission for project 6 -- your files *must* be in the specified locations, as of the deadline, or you will not receive credit for the relevant tasks.

    (If you're having SVN problems with submitting, let me know *BEFORE* the deadline, and I'll work with you to get those addressed. But if you don't say anything until after the deadline, there's nothing I can do.)

Friday, February 23rd, 2007

Only one of the pairs in class was able to communicate properly with the test fest harness over standard input and output. I have therefore decided
  1. to extend the deadline for projects 6 and 7 until Tuesday 6pm,
  2. and to guarantee you a NEWLINE at the end of each protocol message.
This is only one bad part of the existing projects. In addition, many of you did not adhere to the specified XML grammar for writing test cases. Many of your test cases are missing elements; others include bogus characters at the beginning of the file. We conjecture that these characters were generated by XML editing tools and recommend that you check your XML in plain text editors before you submit.

Wednesday, February 21st, 2007

Richard has written up two suggestions that are "must reads":
  1. how to deal with a common and obscure SVN error message;
  2. how to deal with the "runnable scripts" grading policy.
Both are important for both your grade and your learning/preparation for the workplace.

Tuesday, February 20th, 2007

The specification for FROM messages is now included with MESSAGES2.txt.

Thursday, February 15th, 2007

As most of you remember from lecture or are discovering on your own, the special-purpose programming language for testing the player allows only a limited range of scenarios.

It isn't as inflexible as some of you may think though. In particular, it is legal to place the same card on the stack, on the deck, and in the player's hand.

Tuesday, February 13th, 2007

Read Richard's turn-in guidelines. Now. Or else.

Also, concerning project 6, he adds:
  • The test cases that you write should be placed in Tests/Project6; the Tests directory should be at top-level within your submission directory. (That is, Tests should be a sibling of README.)

    Each test case should be stored in a separate file, with the .xml extension, and a filename that suggests the purpose of the test case. DO NOT PUT SPACES IN THE TEST CASE FILENAMES.

    You may put other files in this directory (e.g., notes to yourself about the test cases), but they must not have .xml extensions.

  • For task 1, you must include a run-harness script that will start your test harness (not your test-case administrator). This script is subject to the same requirements as your other scripts. Further, it must expect no command-line arguments (optional arguments for your own purposes are fine), and it must perform no input-output beyond that specified by the project.

    This script should run a single test case, which it reads from stdin, write the test's output to stdout, and then terminate.

    In most cases, this script will simply start your test harness. (Since a Unix child process, by default, inherit its parent's open file descriptors, your test harness will have the same stdin/stdout as the script.)

  • If you attempt Task 2, your run script must accept one command-line parameter, the name of the test case to run. (You may support additional parameters if you desire, as long as they are not required.)

Saturday, February 10th, 2007

The description of design/code walks now contains information on how we evaluate the quality of the presentation, the panelists, and the memo from the secretary to the presenters. I urge you to read it carefully.

Wednesday, February 7th, 2007

Turning in Project 5/Task 0: Please create a Project5a directory under turnin (in SVN), with the diagram in Memos/Project5 as normal. Add text files there, if needed. Use ASCII or PDF for the diagram. Richard has no obligation to grade any other format. So, if you plan on using a drawing tool, including a UML tool (no need to do so!), make sure it can export PDF.

Friday, February 2nd, 2007

In response to those questions that revealed problems with the rules of Squadron Scramble, I have altered the description in two ways. When a question deserved mention, the revised description contains an explicit Q/A part (questions are in blue, answers in purple). When a question could be answered with a small change to the wording of a paragraph, I did that (in purple).

Please study the game again. On Tuesday, I will conduct a five-minute Q-and-A session for last-minute questions on the rules. After that, you will have to "pay" to get answers. Specifically, for every question that we answer, you will sacrifice two homework points from the specific homework.

Wednesday, January 31st, 2007

Richard asked me to post some guidelines about submitting code.

Here are answers to questions that we are receiving repeatedly:

  1. Does the completes function take into account wildcards when determining complete squadrons?
  2. ... but a squadron must be at least 2 aircraft cards and at most 1 wildcard from the game rules. Which spec should we follow?
  3. For the deck constructor, by directory order of cards, do you mean that we actually import from the xml file and then just use the order of cards as they are in the index.xml file?
The answer is that a squadron is a collection of three cards: at least one is an airplane and one or two others are wildcards. Yes, the specs contradict the original rules, i.e., your customer has changed his (absent-mineded) mind. Oh, and all aircraft cards in a squadron must have the same name.

Someone else also asked:

For the deck constructor, by directory order of cards, do you mean that we actually import from the xml file and then just use the order of cards as they are in the index.xml file?
And yes, you are to use the directory with an XML index file and images to create the collection of all cards. You may consider this your first deck, but recall that you also must provide a function for shuffling the deck.

Tuesday, January 30th, 2007

It is apparently not widely known that a squadron consists of the same kind of airplanes (i.e., airplanes with the same name in this game). Please take this into account.

Also I fixed two more small typo-level details in the specs.

Tuesday, January 30th, 2007

Someone asked:

Does this mean that we should have all static methods? In the OO course, we learned how to convert non-object-oriented signatures into object-oriented methods by using the implicit 'this' for the first argument in cases where the that argument was the object that the method belonged to.

Is this correct?

If you are NOT using an OO PL, you should implement the signature AS IS.

If you are using an OO PL, you should implement the signature IN THE SPIRIT OF 213 (or 370). In other words, you didn't just learn this in 370 (OO), you grew up with this from the very first day at NU.

The signatures are specified in a true-and-only OO manner. They specify that the first argument is THIS or SELF and the remaining arguments are the arguments of a method. I don't want to force people, however, to use an OO language, which is why I allow for this much variance. Otherwise you are to implement the signature as-is, especially the state-less part.

Monday, January 29th, 2007

A News Story

Disjoint Twins

Thursday, January 25, 2007 (205 Comments)

by Alex Papadimoulis

I'd imagine that there's a lot involved with bringing a new person into this world. No, no -- I don't mean that part, I mean the whole paperwork side of things. There's Social Security to set up, a .name domain to register, birth certificate, insurance -- especially insurance. With all those people feigning pregnancy and labor just to get a stay at the hospital and a complimentary "It's a Boy!" balloon, insurers need to be extra certain that childbirth claim resulted in a real child.

As the recent father of twin babies, Philip B. was relieved to learn that his employer's benefit provider, Sun Life Canada, made the insurance process really simple. Adding the little ones on the plan required no more than a phone call to provide birth dates, names, and that sort of thing. All seemed so easy, until the customer service rep realized what Philip was trying to do: "I'm sorry sir, but we need a different birth date for each of your kids."

"Uhh, er," Philip stuttered, rather puzzled, "they're twins? They were both born on the seventh of May, so they actually do have the same birth date."

"Oh yes, I understand," she said, "but our system cannot handle two people with the same last name born in the same month of the same year on the same plan."

Philip's jaw dropped. He inquired some more with the CSR to try understand how such a technical limitation could occur. It turns out that a new version of their software was installed that tracked each person's budget based on their last name, plan number, and month/year of birth. Hence, having two people born in the same month and year on one plan would cause all claims to be booked against one of the two's budget, risking a premature budget exhaustion.

We can only hope that, by now, Sun Life has corrected their new insurance system to account for the unfathomable concept of twins. But as of this day, for insurance purposes, Philip's kids are born a month apart, one on April 7 and the other on May 7. That, apparently, is much more fathomable.

Sunday, January 28th, 2007

Richard has discovered two additional small problems concerning Squadrons and completes in Squadron. Fixed in revised release.

Saturday, January 27th, 2007

Ventz Petkov pointed out a mistake in the signature of pop for Stacks in Project 4, which I have fixed now. (This just shows again the dangers of manually porting code to html.)

I have also noticed a missing requirement in Squadron, so please take a second look.

Wednesday, January 24th, 2007

One task of Project 3 is to represent the basic data of Sqaudron Scramble and some basic functions on it, e.g., cards-have-same-name. These functions perform the tasks that their names suggest. For card-< you are to implement a comparison that would help you order the cards on your hand (insert a new one at the proper place), just like in real life.

Tuesday, January 23rd, 2007

SVN Project Structure:

If we specify a directory name or filename in the SVN repository, your turnin tree must match that name *exactly* -- including case and punctuation.

In the notes for lecture 3, we stated that each project statement would contain the name of the directory that you are to create within the turnin directory. For simplicity, we will simply use the pattern established by the previous assignment: Project2, Project3, Project4, and so on.

For project 3 and forwards, your README file and the required scripts (compile, etc.) must appear at top-level within the project directory. You may structure your code any way you like within the project directory, but your README file must contain a roadmap, as discussed in lecture 3. So, if you choose to use Java, you may create the directory structure corresponding to your code's packages.

Any memos should appear within a Memos/ProjectN directory. The Memos directory must appear at top-level within the main project directory. (Rationale: we specify that the project name must appear twice within the path so that you can keep all of the memos you write to us in your work directory, and keep them well-organized, and we can find the memos easily when we grade.)

Finally: In lecture 3, we asked that your README file include a list of which parts you attempted. Since this is information is to be included on the cover page that you submit, you do not need to include this in your README.

To summarize:

   +---- Memos
   |     |
   |     +---- ProjectN
   |            |
   |            +---- memos here as necessary
   +---- README
   +---- compile
   +---- run
   +---- run-tests
   +---- code, in subdirectories as appropriate.

Thursday, January 11th, 2007

People have sent us inquiries about all kinds of programming languages. You are welcome to choose any programming language that runs on the public UNIX computers in the lab. For handing-in products ("shipping"), you must also provide a script that Richard can invoke from the command line.

If the "command-line" restriction represents a hardship for you, please send me a one-page memo (plain text!) and request an exception. Those will be granted on a case-by-case basis.

Wednesday, January 10th, 2007

We have decided that you are to choose your own partners for now. See Projects (tab on left) for details. The deadline is extended until Tuesday next week.

Thursday, December 14th, 2006

Welcome to CSU 670 for Spring '07.

I will messages about the course, the lectures, the project, and the presentations here. Get into the habit of reading this page on a daily basis.

last updated on Tue Aug 30 14:12:07 EDT 2011generated with Racket