[V3dot10] Announcing new VersionsBrowser and source condensing
m3rabb at uiuc.edu
Thu Jul 26 04:39:35 UTC 2007
On Jul 25, 2007, at 22:18 , Andreas Raab wrote:
> Hi Maurice,
> One thing I would strongly recommend is that before you plan on
> adding any new features you make a version that *just* works like
> what is today in Squeak.
I agree with you. The last thing I want to be responsible for is
blowing up anyone's Squeak image or losing anyones sources.
To be clear, I am NOT recommending using the source condensing stuff
for the V3.10 release. However, just the new VersionsBrowser and new
ClassCoomentVersionsBrowser if the group finds it solid. It works
with the source and changes files as they currently are. It is
simply a replacement of the old VersionsBrowser. It is a reader and
does not change the source files.
> I know that it's not as exciting as building the remote retrieval
> and search facility but it is something that people can test and
> debug with a known set of expectations (e.g., "this should work
> just like it did before") and help you finding bugs in the
> Given the amount of time that I just spent in fixing numerous
> issues in condensing sources and changes in Croquet, the thought of
> having an untested, unproven, complete rewrite of the source code
> management system gives me major heartburn (as a matter of fact if
> it were up to me I'd be quite skeptical if there is enough time to
> test it enough for 3.10). There is nothing like loosing someone
> else's source code to get people really upset...
> I'd strongly recommend making a version for people to use ASAP and
> later add all the new features. If this stuff isn't solid it's
> going to be a major disaster.
Ok. I just updated the my release on SqueakSource, and reverted
#condenseChange and #condenseSources to their original versions.
If anyone wants to play with my refactoring of condensing, I moved
the methods that initiate the condensing into the category
'experimental condensing'. I wrote the condensing code from the
ground up, and kept it separate from the legacy sourcecode management
methods. So now, my release leaves the original condensing
Regarding the VersionsBrowsers, with only a few exceptions, I made no
changes to the core system. I refactored a handful of method in
PositionableStream and SequenceableCollections, and provided
associated tests. I also changed about ~half dozen methods that
reference the VersionsBrowser class, and simply "touched" a ~half
dozen others to force the recompiling of these methods. The methods
that reference the VersionsBrowser are all over the system, so that
is why there are so many dependent packages even to it is just about
a dozen call sites.
I hope that helps.
Thanks for your feedback,
> - Andreas
> Maurice Rabb wrote:
>> Hello All,
>> I am 1st year PhD student at UIUC working under Ralph Johnson. I
>> am releasing a new version of the VersionsBrowser and
>> ClassCommentVersionsBrowser. This is the extra feature that Ralph
>> mentioned that he wants to include in V3.10.
>> It is a complete refactoring of the version browsing tools as well
>> as the mechanism for condensing the sources. It enables the
>> previous versions of method source and class comments to be stored
>> in, and accessed from, an external archive. Many Squeakers don't
>> condense the sources or changes files because they want to
>> maintain the complete record of previous versions of methods.
>> Unfortunately, this approach to development prevents one from
>> using the changes file to full effect. If one starts work with an
>> empty changes file, the changes file only contains methods that
>> are relevant to ones work. With my new refactoring, one can have
>> the advantages of both worlds: a clean changes file, and access to
>> the previous historical versions of methods and comments.
>> You can check out the project documentation at the following link:
>> The project has evolved since a bit since we first posted the
>> above docs. We wrote the VersionsBrowser first, modifying the way
>> it searches for source code. I am comfortable that is works
>> properly as a replacement for the old VersionsBrowser. However, I
>> would appreciate if people would try it out and bang on it.
>> Even though the browser appears to work properly the "old" way, I
>> couldn't be sure that it really was working properly until it was
>> tested on a sources and changes file that truly referenced code
>> remotely. That involved the ugly process refactoring the source
>> condensing process. This part now seems to work as well, but needs
>> to be tested more thoroughly.
>> To get the code, use the Monticello browser to load the Tools-
>> Versions-Tests package from:
>> http://www.squeaksource.com/VersionsBrowser2/ It only depends on
>> the Tools-Versions package which in turn depends on a bunch of
>> other packages.
>> To condense the sources, look at the methods in the 'condensing'
>> category in SystemDictionary.
>> - #condenseChanges
>> works the same way condensing the changes file only.
>> - #condenseCurrentSource
>> is my renaming of #condenseSources but otherwise works the same way.
>> - #archiveSourcesPermanently This method empties the changes
>> file and condense all of the current sources to a new source file,
>> and moves all of the prior source versions to the permanent master
>> archive. Since we don't want random Squeakers to affect the
>> master archive, this method actually only generate a new permanent
>> archive locally. Once generated locally, it can be copied
>> manually to the actual FTP archive site by someone who has
>> - #archiveSourceLocally
>> This method allows one to create one's own personal methods
>> archive that doesn't affect the permanent master archive.
>> The VersionsBrowser looks for methods first in the source and
>> changes file, then in the local archive, and then finally in the
>> permanent archive. Method versions >from the permanent archive
>> are stored in a local cache if the permanent archive is being
>> remotely accessed.
>> This leads me to two areas I would really appreciate some HELP:
>> 1) Does anyone have write access to a publicly accessible FTP
>> site that I can use to host the archives? (Possibly
>> ftp.squeak.org ?) I have been having too many firewall issues
>> here at UIUC to be able to run and test the remote access. 2) I
>> would like to build a complete permanent archive of the old
>> versions of past methods. As I understand it the prior versions
>> were lost at V3.9 when the changes file got too big. Is this so
>> Stephane? However, when I looked at V3.8 it too doesn't appear to
>> have much method version history. What is the last version of
>> Squeak to have a complete record of method versions? Do I need to
>> go all the way back to V1.x and build the archive from each
>> version in order?
>> Even without a "complete" method versions history, the new
>> VersionsBrowser and condensing work can be released with 3.10. We
>> can swap in a more complete permanent archive as we build it.
>> I look forward to your comments, fixes and feedback.
>> Thank you!
>> On May 12, 2007, at 10:16 , Ralph Johnson wrote:
>>> One of the features of the new versions browser that doesn't yet
>>> is for the history database to be remote. Right now, the history
>>> database is a directory of files, one for each class in the
>>> My plan was for this to be put on a server and that people who
>>> need to browse version history very often, or who were short on disk
>>> space, could just use the remote version. That doesn't work yet,
>>> though it might work in a few days. However, everything else
>>> seems to
>>> work, though it hasn't been tested very much.
>>> Here is what I am thinking. For our final alpha image, we will
>>> provide a history database, a new .sources file, and a completely
>>> empty changes file. During the beta process, we will keep using the
>>> history database and the .sources file, (unless we discover
>>> wrong with them). Then, for the final 3.10 release, we will once
>>> again rebuild the history database and .sources file, and have an
>>> empty changes file.
>>> The 3.9 team ran out of space in the .changes file and had to
>>> changes, losing some history. It would be cool to go back and
>>> recover that history and put it in the history database.
>>> Even cooler, we could go back and get all the history in Squeak 1
>>> Squeak 2, so we could have a complete history of all code that had
>>> ever been in the Squeak image. This would only require changing the
>>> history database, not changing anything in the image, so it is
>>> the official 3.10 release process. If we don't have time to work on
>>> it earlier, we could work on it after 3.10 is over.
>>> The new versions browser has a much nicer way of representing the
>>> sources than what Squeak currently has. We should considering
>>> refactoring Squeak to use these classes everywhere. However, I am
>>> opposed to doing that in 3.10. We should use the new versions
>>> browser and debug these classes. Once these classes are mature than
>>> we can change other tools to use them, perhaps in 3.11 or 3.12.
>>> This work was done by Maurice Rabb and Navodit Kaushik as a class
>>> project for my course on OO programming and design. Navodit will be
>>> the first to admit that Maurice was the leader on this project.
>>> He is
>>> a long-time Smalltalker who is just starting grad school at UIUC and
>>> you can expect to hear a lot from him in the future!
>>> So, here is a summary of my proposal. I want to know what you
>>> think about it!
>>> We will make the final 3.10 alpha be to add the new versions
>>> and the final alpha image will have a new history database, a new
>>> .sources file and an empty changes file. If you update your old
>>> to have all the changes then you will still have the old .sources
>>> and the old .changes file and the history database won't be much use
>>> to you. We might not have the remote history database working. We
>>> should be able to do this within a week.
>>> During the beta period we will just fix bugs. One of those bugs
>>> be the fact that the remote history database doesn't work.
>>> The final 3.10 release will have a new .sources file and a new
>>> history database.
>>> V3dot10 mailing list
>>> V3dot10 at lists.squeakfoundation.org
>>> <mailto:V3dot10 at lists.squeakfoundation.org>
>> V3dot10 mailing list
>> V3dot10 at lists.squeakfoundation.org
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
More information about the V3dot10