View this PageEdit this PageUploads to this PageVersions of this PageHomeRecent ChangesSearchHelp Guide

Why do we need to refactor the Versions Browser?

Like many of the Squeak source code development tools, the implementation of the VersionsBrowser needs refactoring. The methods are large and confusing, and there are lots of difficult to understand dependencies between other objects. Further exacerbating this problem is the lack of documentation – both at the class as well as at the architecture level.

This is reason enough to do a refactoring. However, there is another motivation. To understand it, you must understand how Squeak stores and maintains its source code.

Squeak Source Files

Similar to other Smalltalk environments, Squeak stores its source code in two files, namely the 'sources' and the 'changes' files. While the 'sources' file holds the most recent version of every method in the system, the 'changes' file holds the source code for all the new methods that have been added to the source code and for all methods that have been changed in the system.

So when one changes existing methods or adds new methods, these changes are written to the 'changes' file. The 'changes' file holds every version of every method change that is made to the system. In contrast, the 'sources' file is considered immutable. The system keeps track of the location of the most recent (and therefore current) version of the source code for a method. As a rule, Squeak does not use actual objects to manage source code for methods. While this deviates from the general “everything is an object” paradigm of Smalltalk, it does provides some key advantages.

The system doesn’t use source code to run, but instead uses CompiledMethod objects. A CompiledMethod is the compiled version of a method’s source code and is directly executable by the Squeak virtual machine (VM). CompiledMethods are much more compact than the source code itself. They are saved as actual objects in Squeak memory image. CompiledMethods are referenced by the MethodDictionary of each class. Within the dictionary each CompiledMethod is the value while its key is its method name, also called a selector. A CompiledMethod represents the current version of a method for its class. Each CompiledMethod holds a pointer to the text of its source code. This pointer is not an memory pointer, but represents the position of the starting character of the source code within the sources or changes file. The figure below illustrates the concept.

Uploaded Image: PointingToSourceCode.jpg

An advantage of storing the source code separate from the memory image, is that it is written and saved to disk every time a method is changed or added. If Squeak crashes, the record of all methods, and their order of addition to the system is available in a human readable form.

Ideally, when one uses a fresh version of Squeak for the first time the 'changes' file is empty. The 'changes' file grows as it records one’s new methods, and method changes. Therefore the 'changes' file is a useful tool for tracking bugs and overall understanding of how one has changed the system.

In recent years however, new versions of Squeak have shipped with a large changes files. In some versions the 'changes' file was as big as the 'sources' file itself! Not only did it bloat the size of Squeak, but it made the 'changes' file far less useful to the developer. However, the one big advantage (albeit restricted to few) of shipping the 'changes' file is it that provides Squeak “super users” the capability to track the evolution of methods within Squeak over a period of time.

However in Squeak 3.9, the last version of Squeak, the 'changes' file had grown so large so that the range of the source pointer in the CompiledMethod was in danger of overflowing. The release team was forced to condense the sources to counteract this. While this was the appropriate action, many Squeak developers were upset at the loss of past source code information in the 'sources' file. Hence the motivation for this project which aims to provide an intermediate solution wherein while the average user will get an empty 'changes' file and only the latest version of source code, the superuser can see all versions of the method. This is done by providing a 'history' file that has versions OLDER than those in the 'sources' file.

This change was difficult to make in the old version browser, which was the real reason to refactor it.




Link to this Page