R. Clayton (rclayton@monmouth.edu)
(no date)
I've updated Graph.java to get rid of some idiotic array-bounds errors. I've
also turned off the matrix print; if you want it, you'll have to turn it back
on. You can find the updated files in the a10 assignment directory and on the
assignment page.
I've also made a few other updates:
* I've added some extra graphs in addition to the random-path graph: a
complete graph and a random-edge graph. A random-edge graph as fewer and
more disconnected edges than does the random-path graph. Use the -gn option
to select a graph, where n is 1 for a random-path graph (the default), 2 for
a random-edge graph, and 3 for a complete graph (reverse alphabetical
order).
* I've added some animation code so you can animate and watch your code work.
The NodeRunnable prototype has changed to pass in the animator; see
NodeRunnable.java and NodePairing.java for details. The file
NodePairingAnimatorInterface.java contains the animation routines and
example calls. The -a1 option invokes the real animation code; the default
is to invoke fake animation code that does nothing.
The xtango animation code is old and creaky java (ver. 1.1); it invokes
deprecated methods (Thread.stop()), throws the occasional null-pointer
exception, and has preferences-permission problems. Ignoring these problems
worked for me, but if your program prints anything to std-{out, err} it can
be a pain finding it for all the animator chatter.
See below for some tips on running the animation.
* I've made my solution with animation available in NodePairing.jar. You can
run it by typing
java -jar /e*/h*/c*/*8/a10-anim/NodePairing.jar <options>
Because this update is a significant change to the code (and because it's close
to the deadline), I've installed it in the separate directory a10-anim. The
original directory a10 does not contain any of these updates except the first
involving the Graph.java array-access fixes.
There are two ways to run the animation: single stepping and continuously. If
you run the animation continuously, you should slow it to somewhere in the
1000s - 4k or 8k - to start. I haven't figured out single stepping; it seems
you have to click step at least twice (not a double click) to go to the next
step. Be sure to turn on single-step mode before starting the animation
(although you can do it after starting too, as well as turn it off). I
recommend you single-step through a few small graph examples to start.
One of the things I found surprising about the animation is that it was (and
still is, to some extent) difficult for me to follow. It took me about a
half-hour to first understand what was going on (and to realize that the
animation wasn't broken). Part of the problem is due to poor animation design,
but a majority of the problem comes from concurrency and its ability to
(correctly) produce events in an order I hadn't expected.
I don't recommend you spend too much time trying to understand my program's
animation. I do, however, strongly recommend you animate your own program and
try to understand that. It should underscore the futility of trying to reason
operationally ("first this happens, then that happens, then ...) about the
correctness of concurrent programs.
This archive was generated by hypermail 2.0b3 on Tue Aug 12 2003 - 09:30:05 EDT