Updates galore.


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