For quite a while now, the RB release at it's official location has been
broken.
The fix is small (and I've posted it to the list), but the fact is that
the release is throughly broken.
Further, apparently some of the remaining RB Port cruft now breaks the
SUnit tests.

I used to take care of these things for a while, but lately I haven't.
The need for someone that understands the RB framework, and wants to
take it to interesting places in Squeak is clear.

Nevertheless, I would like to see the Squeak community profit by the RB,
so here are a few of my thoughts.
* I think projects need a lead. A package that is "maintained" by
various people applying patches independently to fix what troubles them
can easily rot - different people constantly pulling the code in
different directions without coordination doesn't work. Either lots of
communication (the XP alternative) or a central authority is needed to
keep things working, simple and coherent. For an illustration, see the
mess that is Celeste (some of that mess has my fingerprints..). 
* The Squeak RB never had many very active contributors, but always a
small group or individual that took it up to some point. I have a few
guesses on why.
* The RB is not a goodie. It's too big and affects too much image to
maintain as a simple single changeset that people can apply or not. I
think to maintain the RB requires either - 
 - It is easily loadable as a group of modules
 - It is part of the base image
The first is the right way to go for both the RB and the image, and that
used to be my goal. I got as far as separating the future modules into
changesets, but it's too easy for inconsistencies to creep into a bunch
of changeset, which is why we need modules.

As time passed and no reasonably complete modularity tools became
available[1], my interest faded. If enough people want the RB now, it
might be wise to put it in the main image, and then cut it up and out as
the tools become available.
* The RB is big but it's well partitioned, and has many tests to
establish what part is broken. So different people can maintain
different parts of it. Some parts are stable and won't require much work
(RBParser), and some of them are more dynamic (all the UI).
* A few difficulties we have ahead with RB:
 - There's that small matter of a broken initialization method. I can
fix that, no problem.
 - There's still port cruft there that leaves scratches when it touches
things (Object>>testing...)
 - The existing division into Engine, UI and extras is still too coarse.
One should be able to get just the parser. Doing this properly requires
working with modules and I don't know enough to make do with what's
available.
 - The RB doesn't load into 3.3 because DeltaModules aren't complete
(IIUC, don't handle changes in format of a class). Haven't checked this
lately, maybe this was fixed?
 - As Henrik mentioned at some point, the Modules work changed the
semantics of Squeak somewhat. To adapt the RB to these changes would
require writing tests for all the functionality that's affected by the
semantics changes, and then getting them green. Obviously, the RB can be
used before this is complete, one just needs to be aware of the
differences.
* Some opportunities inherent in a working RB
 - It's much easier to clean up cruft with it than without it.
 - It helps people produce cleaner code in the first place.
 - Lots of very high quality code for people to learn from.
 - Lots of useful things in the framework that can be reused (Parser,
ParseTreeMatcher/Replacer, the refactorings themselves (which can be
integrated in Whisker or the Tile system, for example))
 - It's a real test for the modules tools.

[1] - I know modules are in the image. However, delta modules are
required for some things and don't quite work yet, and I don't think
there's currently the equivalent of a DualChangeSetBrowser, where I can
move a method or class from one module to the other. It it's there, I
don't know of it. That's basically what I'd need.

Anyway, if people here care about having the RB/want to help maintain
the RB or part of it/have ideas that'd help, let's hear them.

I do not endorse the idea of simply putting the code somewhere and
having everyone patch it in an uncoordinated manner. If that happens, I
predict the code will become unmaintainable within months, and will keep
the SCAN page as a known-defects-alternative.

Daniel

stephane ducasse <ducasse at iam.unibe.ch> (home) wrote:
> Steve
> 
> Daniel apparently is not interested anymore to help or maintain RB so I 
> would suggest
> a simple schema to have ready for everyone RB.
> Could you create a project at squeak foundation and put the current 
> version you have
> with a small script allowing to load RB in one click? then when other bug 
> fixes will come anybody could create a new distribution.
> 
> Then we should try to collect enhancements. I'm **really** too busy to 
> support improving RB but I would like to use it and push other to use it. 
> I use it in VW and yes indeed I program really fast with it.
> 
> Stef
> 
> On Friday, May 3, 2002, at 08:19  PM, Steve Gilbert wrote:
> 
> > "stephane ducasse (home)" wrote:
> >>
> >> Hi
> >>
> >> which version are you using?
> >> I would like to help to bring RB in a good state. It would be good if we
> >> could have a page on the squeak foundation for that.
> >>
> >> Are you interested because RB was on college
> >> Squeak alpha version http://squeak.heeg.de:8080/squeak/packages/
> >> and the patch that was never included in the previous web page
> >> http://scgwiki.iam.unibe.ch:8080/SmalltalkWiki/143
> >>
> >> Stef
> >
> > Stef,
> >
> > Currently, I'm working from 3.2gamma #4827.
> >
> > The version that I'm using is the one that you get by accessing the SCAN
> > repository using URL:
> > http://squeak.heeg.de:8080/TFODC69UQ0MFRIHMG40DRML1CU7VYZ9
> >
> > I guess that currently that's version 12 of 2001-12-01.
> >
> > I just downloaded the files specified in the script on that page.
> > However, the SUnit tests for that version of the RB requires some
> > external files to successfully complete "all" of the tests. See my
> > initial posting to this thread.
> >
> > Also, I found that the test
> > BrowserEnvironmentTest>>testCategoryEnvironment is either in an infinite
> > loop, or just takes an unusual amount of time to complete. So I renamed
> > it by pre pending "skip" to it so that it wouldn't run for now.
> >
> > Also there is a method called "test" that gets added to Object when the
> > RB cs's are loaded.  This causes one of the RB SUnit tests to fail,
> > because the test is expecting to see 2 testing methods and now sees
> > three.  Anyway, I changed the method to "flagTesting" and all of it's
> > callers to make the problem test work correctly again.
> >
> > Finally, there was a problem with the BrowserEnvironment>>keysFor:
> > method failing on "obsolete" methods.  This is now fixed with the latest
> > cs from SqC that came in the recent update stream. See:
> > 4855ClassBuilderFix3-2 -- Nathanael Schärli & Andreas Raab -- 23 April
> > 2002.  Good work guys!
> >
> > So after all of that, I can successfully run all the SUnit tests
> > associated with the standard image as well as the RB and SUnit packages.
> >
> > I would love to see the modification to RBScanner class>>initialize be
> > put into the SCAN repository.  That way everyone would stand a chance of
> > having a working RB right out of the box.  Also, there should probably
> > be a new unit test to protect against the errors that occur if this
> > change has not been made. There are a whole lot of SUnit tests for RB
> > that call a "needsWork" method.  Those should be looked into at some
> > point.
> >
> > As far as my interest in the RB. I've used it a good deal in VW and am
> > impressed by the gain that I get in productivity using it.  It is one of
> > the pieces that I think is "Fundamental" to moving Squeak forward. That,
> > and more SUnit tests.
> >
> > I think that RB will be especially useful in completing the re-factoring
> > necessary to complete the modules work.
> >
> > My biggest problem, is that I certainly don't have a firm grasp on how
> > the RB works, in a detailed way.  Therefore, it's difficult to make
> > judgments on what work is left to be done to make the tool useful enough
> > for daily usage.
> >
> > Steve
> >