Clarifications/Updates to A2

June 14/07 - Clarification about infinite loops and RETURN_TYPE instructions

The following has been discussed in the forums for the last couple of days.

Your code needs to handle infinite loops such as:

idx   instruction
0      GOTO_TYPE 1
1      GOTO_TYPE 0

Notice the function does not have a RETURN_TYPE instruction. This is okay in this case since
even if there were a RETURN_TYPE instruction at index 2, it would never be reached (because of the infinite loop).

However, the following function is NOT okay (and you are not expected to handle it):

idx   instruction
0      OTHER_TYPE

This is not okay because the instruction to be executed after index 0 is at index 1. The instruction at index 1 is non-existant. You will never get a function whose execution path leads you to a non-existant index.

Hint for dealing with infinite loops: Your code should not be treating infinite loops as a special case; if you implemented the pseudocode from the assignment handout correctly, then it already should handle infinite loops.

June 10/07 - EditableQueue remove() method clarification

The assignment handout states:
__________________________________________
The EditableQueue interface extends the PureQueue interface (section 8.2.1 of the text) by adding the following method:
You are to implement the interface EditableQueue using a linked list. Note: you are allowed to use java.util.* in this part. Your implementation should be put in the class LLEditableQueue.
__________________________________________

The remove() method should remove only the FIRST occurrence of the specified element in the queue. (This is consistent with how java.util.LinkedList.remove() is implemented.)

June 7/07 - How NOT to lose style marks

You can check your code's style the way we will do it and fix any problem before submitting your code.
For more information see the website:
   http://www.cdf.toronto.edu/~csc148h/summer/assignments/style.shtml
 
Follow the instructions on the course website to download Checkstyle and our
xml file. Assuming you have unzipped the check style in "Dir1" directory and
148 xml file in "Dir2" directory. Open a command prompt (or inside Dr Java) and run
 
java -jar Dir1\\checkstyle-all-4.3.jar  -c  Dir2\\148-stylechecks.xml javafiles
 
where javafiles are names of your java files you want to check for style.
You will see a list of warnings/suggestions for each file with the line
numbers. Fix the problems and re-run the check style.
 

June 2/07 - Clarification on how to calculate "running time"

The following was discussed in the tutorial that was held yesterday (Fri Jun 1), but since there were few people there, I am posting this discussion to the bulletin board as well.  
 
When you call the run() method on the Robot or a Task, you have to pass in a duration value telling it how long to run for. In the case of RoundRobinRobot, the way it works is by selecting a task to execute (the next task in the queue), and then calling task.run(quantum) on it, where 'task' is the task selected, and 'quantum' is the quantum that the RoundRobinRobot was created with. The Task may not run for the full quantum. For example, suppose you ask the robot to run for a duration of 25 ms. If the Robot's quantum is 15 ms, and the next two instructions in the Task to be executed each take 10 ms, the task can only execute the first of those instructions. That means there's 5 ms that are "left over" that the task did not use (15 ms [quantum] - 10 ms [first instruction] = 5 ms). The task itself does not remember this left over time *between* calls: that is, after task.run(quantum) has returned, and you call it a second time, it does NOT remember that it had 5 ms left over from the previous call. However, the run() method of the RoundRobinRobot will recognize that the task did not execute for its full quantum. That is, it will see that the task only took 10 ms, and calculate that the remaining time it's supposed to run for is 15 ms (25 ms [original duration] - 10 ms [actual time task ran for] = 15 ms [remaining time]). Since this is greater than or equal to the quantum, it can execute a task for another quantum.  
 
Continuing with the example, suppose that the next task the RoundRobinRobot chooses to execute is also set up so that the next two instructions take 10 ms each. Again, only the first of these instructions has time to execute, and again there's 5 ms "left over". The robot will calculate that the remaining duration for executing tasks is 5 ms (15 ms [old remaining duration] - 10 ms [actual time task ran for] = 5 ms [new remaining duration]). Since this is less than the quantum, no more tasks can be executed and the robot's run() method returns. Note that like a Task, the Robot's run() method does not remember "time left over" *between* calls: that is, the next time the run() method is called, it does not remember that it had 5 ms left over from the previous call. 

June 1/07 - Wrong return method in Assignment handout

On the handout at the bottom of page 5, for the getRunningTime() function, it says that the return type is 'void'. It should be 'long'. The handout has been updated. The starter code already had the correct return type defined.

June 1/07 - Clarification on what to unit tests to hand in

For part 2, submit Junit tests for the public methods that you have to implement. You do not need to test public methods already implemented in the starter code.