Managing and Saving Changes
Last updated at 10:04 pm UTC on 8 December 2006
Starting and Quitting
Obviously you have figured out how to start the system. The approved method is to double-click on an image, although if you have several different interpreters, you may want to drag the image to the appropriate interpeter.
To quit a Squeak session, choose 'quit' with or without saving from the screen menu. If you save, your image file will be overwritten. You may choose 'save as...' to write a newly named copy of your image and changes (see below).
All of the objects – classes, dictionaries, windows and other objects that make up the Squeak environment are stored in an image file (this must always be named 'SomeName.image'). For this reason, when you start up an image, everything is right where you left it when you last saved the image.
Sources and Changes
For various reasons, the source code associated with the image is stored in two other files. The code of the system as originally delivered (vers 2.0) is stored in the file 'SqueakV2.sources', and the sources for everything done since that time is in the changes file (which must similarly be named 'SomeName.changes').
Storing the source code in a separate file has several advantages. To begin with, if you have been working for a couple of hours, and your dog rolls over the power cord, you will still have a sequential record of all your program edits, and these can be perused and replayed with numerous tools such as changes: post-snapshot log. This feature has also saved many a hacker who got too adventurous in changing the system he or she was using.
Also, if you wish to run the system with severely limited resources, it can be operated without any source code, owing to its ability to decompile the bytecode methods into a readable and editable version of the original source code (only comments and temporary variable names are lost).
Finally, since the changes file does not consume memory space, Squeak keeps a continuous log of all your program changes, and these can be examined and reinstated at any time (see 'versions' option in browser selector pane).
In addition to the 'save' command that saves the entire state of your Squeak image, individual methods, categories and classes may be 'filed out'. This option is available in most browsers, and it results in the creation of a text file with an appropriate name, incorporating the code in question.
The format of this file is special, in that it can be read back into the same or another Squeak image to recreate those same classes and methods in a new environment.
ChangeLists, ChangeSets, and ChangeSorters
A ChangeList is a method-by-method view of a fileOut. Note that the changes-file record of all your program edits uses the same fileOut format, so a ChangeList can browse the change history of any Squeak session. The recent change log option of the changes... menu is one example; other examples in ChangeList public access include viewing other Smalltalk source code files. This can be easly invoked through the FileList 'browse changes' option.
In addition to the sequential changes-file record of all changes, whatever project you are in, a ChangeSet keeps a more dictionary-like record of what has been changed. This allows you to fairly easily make a fileOut of just the most recent versions of a bunch of related changes that constitute your work on that project.
ChangeSorters allow one to organize all system changes into a number of independent ChangeSets. One word of caution: at the present, unaccepted changes in a changeSorter window will be lost if you exit the window and return later, due to over-ambitious automatic updating.
Projects offer a natural way of organizing related work, windows and changeSets. The effect is almost like many separate images in one, except (!) that all projects share the same code, regardless of where else it may be changed.
Organizing your Disk (on the Mac)
Squeak will look for its sources file both in the folder in which the image was started, and in the folder in which the VM exists. It is simplest to put the sources together with the VM, and then you can use any number of image/changes pairs anywhere on your disk.
If you wish to maintain different versions of the VM on your disk, here is the easiest way: put all VMs in a single folder, along with the sources. Then in any folder with images for version X, put an alias of the VM for version X, and drag your image onto the VM alias to start it.