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:
public boolean remove(E element)
- removes the
specified element
from the queue (regardless of where it is in the queue).
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.