Re: michael/wjr merge

[Michael McClary <michael>]

> Whoa!  Some of us Neanderthals need to know from where you've diverged.
> My starting point was alpha-5 (5/8/90) and if we're talking about "basic"
> changes (i.e., xpp, xlatexpp) then for some of "us" it's not so cavalier.
> (or is it *arrgggghhhh* 3 more weeks of translating?)

You should be unaffected until the revised comm stuff is integrated
into an alpha (which may be soon).  At that point, you can treat it
as a divergence from the previous alpha.

You may be happy to hear that the "extensive and significant" changes
are internal to the interaction of the stubble script, the CommHandler
class, the (now reorganized) hierarchy of classes rooted at Xcvr
(formerly Transceiver), and a few chunks of their related hair.

(Some of their hairballs had migrated into IntegerVar and PrimArray, in
the form of the SELF_COPY hook.  SELF_COPY has been eliminated and the
hair combed out of IntegerVar, and I expect Mr Hill will soon do the
same for PrimArray.  A new facility has been added to regularize the
intended function of SELF_COPY, but nothing uses it yet.)

The interface the comm package presents to the other objects is unchanged
from alpha-5.  The protocol on the comm link has been changed slightly
(the redundant commas are gone), but that change is internal to the Xcvr
implementation class (now named "TextyCommXcvr").

The changes are "E&S" mainly to Mr Hill, who will be integrating mjm.wjr...
with his changes to alpha-6, to form either the next alpha or the one
after it.  There is a curtain between com and its clients.  The
reorganization is entirely in what is being done behind the curtain.

(You should probably have a talk with me or wjr to be sure you can
ignore that man behind the curtain.)

You may be less happy to hear that changes to the handler/transciever
stuff will continue.

 - Chris Hibbert will be simplifying the proxy methods and eliminating
   the explosion of MessageHandlers.  This should speed the compiles
   and shrink the images significantly.
   
 - Bill Richard will be replacing makeProxy() with sendProxyTo().  This
   kills a garbage-collector moose and has other benefits.  (Among the
   benefits is the simplification of a potential change to the proxy
   semantics that >would< be visible, but may be necessary, or at least
   highly desrable.)
   
 - I will be growing the disk branch of the hierarchy, which (I hope)
   will have no further impact on the com branch except for freezing
   it above the fork.  (This merge was that breakpoint.)

> > (I note that three people working on the same chunk of code, diverging
> > from a point already diverged from the main line (where at least one
> > more is working on related chunks) should make the next merge considerably
> > more interesting.)
> 
> Or is it hopeless?  Can I ever get a "next version" that'll Scheran
> translate in finite time?

You should be aware of a side-issue with this merge.  It's the first one
done by the head of QA, a noted reliability fanatic.  B-)  Therefore the
report was phrased in his charicteristicly Machivelian manner, highlighting
everything he found that might concevably be a reliability problem, and
leaving potential solutions to the readers.

If the horror movie scared you shitless, you caught half of the point.
If you got the impression I expect identical sequels, you missed the
other half.  The monsters are an easy kill once you see them.

> > xlatexpp/*:
> > 
> >   []The makefile provided did not, and could not easily, run regression
> >   tests.  I added a "tests" target and ran them.  They all failed.
> 
> A real encouraging sign...

Naw.  Totally expected.  If you don't run the regression tests you get
bit rot, and it all shows up at once when you turn them on.

> >   I have begun pursuing this with the Smalltalk crew, and will
> >   continue over the next few days.
> > 
> >   I also plan to write a letter explaining the pattern of use I
> >   intended for the regression test support.
> 
> What does this mean for we (er, I mean I) the users (er, user)?

If the tests failed because the tests were broken, they will be fixed.
If they failed because the smalltalk classes were broken, the smalltalk
classes will be fixed.

If you like my ideas about regression testing, you can use some or all
of them.  I recommend them highly (of course).

> > calc/*:
> > []

> I've never seen or used "calc", so what... ("he ignores the above")...

"calc" is just a testbed for the remote object stuff.

> > xpp/*:
> > 
> >   Extensive and significant changes were made.  Merging this section
> 
> Oh shit! (He says to his alter-ego.)  You can't be serious?!?!?!?
> At least there aren't "significant" changes to the visible interface???
> (i.e., *x.hxx stuff)??

Right.  Nothing changed at the x.hxx level except the interfaces between
pieces of the comm stuff.

> > stubble/*:
> > []

> I don't think this affects us.  I hope not, anyway.

I don't think it does, either.

> Please not my concerns over basic interface changes, if these change,
> then the whole focus of my work changes.  (And I had such good things
> saved for next week's meeting!)

Please note my effort to maintain a clear division between comm internals
and comm clients, and to make the changes only within, but not at or beyond,
that boundary.

If changes to comm internals affect your work, we need a talk.  (The
worst case I envision would still be a minor matter.)

	michael