Smalltalk sports an exploratory programming environment. Expressions can be evaluated and the code defining the system can be modified and added from within the system. This provides fantastic flexibility and a more natural programming style but it does bring some dangers. We are expecting the system which we are modifying to remember our modifications, unfortunately some of these can turn out to be more 'potent' than expected. To handle this eventuality all user instigated modifications are written to an external changes file as chunks of text which can be evaluated at a later date to reenact a user session. In combination with saving the image this should ensure that your changes to the system won't be lost whatever happens. (hopefully)
To fully define the state of the Dolphin system requires three separate file; image, sources and changes. The image is a large binary file recording the state of each object in the system. The sources file contains the text definition of each original method supplied with Dolphin in the chunk format. The changes log file contains the expressions evaluated by the user, including modified and new method definitions, again in the chunk format. Each file has the same filename but with a distinguishing extension; IMG, SML and CHG respectively.
It is imperative that you do not manually edit the sources or changes file. Dolphin knows the positions of sections within the files by an absolute character index so just adding a single character will ruin all the method definitions.
Selecting a method in the Class Hierarchy Browser displays its source code. It might be expected that this piece of text would be stored with the CompiledMethod object, in fact it is stored in an external file. This is done to reduce the memory requirements and for security against losing your changes.
There are two external files which hold the method definitions. The sources and changes files. When you run Dolphin for the first time the definition of each method in the system will be stored in sources file. Whenever you add or modify a method the new definition is appended to the changes file. If you modify a method a number of times each version of the definition will be stored away into the changes file, with the last definition being the most recent.
The changes log works in conjunction with saving the image to protect against loosing changes if the system becomes unusable. Whenever the image is saved a special marker, a line similar to
"Image saved on 17:05:58, 02/07/96"!
is inserted into the changes log. All further expressions evaluated by the user will be appended to the changes log after this marker. If the system become unusable before you save the image again it is possible to recover the intervening changes.
Before you rerun Dolphin you can load the changes log into a text editor and create a new file containing the appropriate text after the last Image Saved marker. On running Dolphin the file can be loaded into a new workspace by choosing the File/Open… from the Transcript. The appropriate chunks can then be selected and evaluated by choosing the Workspace/File It In. You should be careful not to evaluate the statement which caused the problem in the first place…
Over time the changes file can grow significantly in size. It is possible to reduce this to something more manageable by choosing the File/Compress Changes from the Transcript. This will recreate the changes file with just the current definition of each of the changed methods. All of the other information stored in file will be lost, so from then on it will only possible to recover the modified methods from the changes file. This is currently a rather simplified technique and you will run into problems if you have added a class, deleted methods, etc. As a result you should use this with care.
Some times you may have reached a stable state where you would only like to see the changes to the system after that point to be thought as changes. This can be achieved through evaluating:
SourceManager default compressSources
This will move all the new method definitions from the changes log into the source file. This will leave the system in a state similar to when you ran Dolphin for the first time, the change log will be empty and the definitions for all of the methods will be stored in the sources file. At that point no methods in the system will be thought of as changed. The process of adding and modifying methods can again continue.
You should realize that this is a system wide operation, it is not possible to restrict this to a collection of methods which you want pushing back into the source file.
The sources and changes files are referenced within the SourceFiles global. This is an Array whose first element is the File object for the sources and second is the changes File object. The SourceManager provides a number of methods for opening and closing the files.