SnarfXcvrs now Xmit.

[Michael McClary <michael>]

Synopsis:

 - ViewHandler (= EXTREMELY bogus SnarfPacker) now works well enough to
   test the transmit side of SnarfStreams (and to provide useful chunks
   for the real stuff).

 - The transmit side of SnarfXcvr works.

 - CountSnarfStreams and StuffSnarfStreams now work (though
   StuffSnarfStreams will require minor modifications when
   SnarfPacker is de-bogosified.)

 - Structured debug of this stuff has not yet done. (i.e. it works
   right in the case tested, but I haven't checked to see if it's
   touching all the bases, and am virtually certain it missed a couple).

I thought you folk would like to see the following excerpt from the test
output:  a printOn of the ViewHandler just after it commit()ted the two
flocks it knew about to the bogus snarf.

(New programmers are reminded that this is a "verbose", human-readable,
version of the data, and that switching to a "terse" version for storage
saving is trivial.)

ViewHandler(300, (ViewEntryShepherd(????), ViewEntryShepherd(????), NULL),
->*Shepherd(12,Sheep(13,NULL,NULL),Sheep(14,NULL,NULL))*Shephe<-
->rd(8,Sheep(9,NULL,NULL),Sheep(10,ViewEntryShepherd(2),ViewEn<-
->tryXcvr(1)))||*|||||||||||||||||||||||||||||||||||||||||||||<-
->||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||<-
->||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||<-)

Explanation:

  ->The pseudo-snarf buffer<-

  | = Initialization character, i.e. marks bytes that were not changed.

  * = Separator marking boundaries of the regions allocated for the
      storage of the flocks.

 Sheep:  A test sheep object consisting of:
	  - A copy of the allocation sequence number (to be used later
	    when testing reanimation of disk objects).
	  - Two pointers-to-heapers (which are initialized NULL, and
	    can be used car/cdr-wise to build tinkertoy flocks).

 Shepherd:  A test object essentially identical to a Sheep except that
            it answers "TRUE" to isShepherd().  (Heck.  I could have
	    inherited all that cruft...)

ViewHandler(300, (ViewEntryShepherd(????), ViewEntryShepherd(????), NULL),
  \            \____            \______________/
   \                \                       \
It's a ViewHandler with a 300-byte buffer, aware of two flocks.  (The
list is LIFO, which is why the first flock in the following buffer is
the flock associated with entry #2.)

->*Shepherd(12,Sheep(13,NULL,NULL),Sheep(14,NULL,NULL))*...

Flock #2:  Shepherd#12, pointing to Sheep #13 and #14, which point nowhere.
           This flock exactly fit the space computed by the CountSnarfStream.

                                                    ...*Shephe<-
->rd(8,Sheep(9,NULL,NULL),Sheep(10,ViewEntryShepherd(2),ViewEn<-
->tryXcvr(1)))||*...

Flock #1: Shepherd #8, pointing to Sheep #9 (which points nowhere) and
	  Sheep #10, which points to Shepherd #12 (in the other flock)
	  and Shepherd #8 (back to its own shepherd, forming a loop).

(Note how the ViewEntryShepherd broke the connection to the other flock,
and the ViewEntryXcvr broke the loop.  (Those names are prety awful, and
may get changed.  Like to "SnarfXcvrEntry" and "ShepherdSnarfEntry".
They correspond to entries in tables/lists/whetever in the SnarfXcvr
(for references to previous objects in the same transaction) and in the
SnarfPacker (for references to the shepherds of other flocks).))

This flock is slightly (2 bytes) smaller than the space allocated for it,
because the CountSnarfStream sizes the flock before locations are assigned,
and thus must make the ViewEntryShepherd item big enough to hold its final
value.  It does this by assigning a bogus number of its own.  (In this case,
it was told to start counting at 100.)

If you're wondering about the numbers, there were apparently seven objects
allocated before we got around to flocks, and Sheep #11 was dropped when
Sheep #10 was changed to point to Shepherd #8, during the testing of the
Sheep and Shepherd objects.

Next:
 - A structured debug of this, to pick up the missed bases.  (Among the
   known warts are commented out junk, uses of NEW(), and getFoo()s that
   can return NULL.)
 - Merging with the way {Comm}Xcvr drifted while I was writing this stuff.
 - The reanimation side, which requires "become".

	Yay!
	michael