Refactoring Browser maintenance (also relevant for other projects)

stephane ducasse (home) ducasse at iam.unibe.ch
Sun May 5 20:40:17 UTC 2002


Hi daniel

I mainly agree with you. I would really like to look at the parser
and the parseTree, prettyPrinter and parseTreeMatcher....
But I have no time right now..Really no time.

I'm willing to be a beta tester of anywork around RB.

Stef

On Saturday, May 4, 2002, at 04:19  PM, danielv at netvision.net.il wrote:

> 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
>>>
>




More information about the Squeak-dev mailing list