The Smalltalk development environment provides very powerful ways to develop applications. By using it to the full, it's possible to be very productive. It's also possible to lose all your work in a moment if you don't take some simple precautions! The advice in this section is based on bitter experience.
There are some very powerful code management tools available for VisualWorks, but if these are too complex or expensive for your immediate needs you can do a perfectly good job with the facilities included in VisualWorks. So, Smalltalk provides two ways to save work—the 'save-image' facility, and file-out files.
The first rule is to use the 'save-image' facility. Use it often—especially just before you make a crucial change to the system.
Provided you have a reasonably fast computer and your image isn't too big (so that it doesn't take too long to save), you should do a 'save-image' at least every half hour. Also, do one after every change which you don't want to have to repeat, and before doing anything that could damage the system. This includes redefining any of the system methods, especially if you're modifying the way the user-interface works. It's very easy to throw yourself into a loop from which you can never recover by damaging the code which deals with the opening of windows, causing the system to try to open a notifier to tell you, causing it to try to invoke the damaged code, causing it to try to open a notifier... . Before you know it, your screen is covered with notifiers which you can't get rid of!
Using the Development Tools
As well as using the 'save-image' facility, you should make use of the file-out facility to keep copies of your finished code outside an image.
This makes sure that you can rebuild your image from scratch should this prove necessary. In fact, it's quite a good idea to rebuild your image regularly (perhaps as often as every day), just to make sure that you're not relying on odd instances lying around which you no longer know how to recreate, and to tidy-up any garbage generated during development which the garbage collector fails to reach,
Another important thing when managing your .image is never to delete your changes file. This file, one of which you'll have noticed goes along with every image file, contains all the source-code you have added or modified. Whenever you change a method, the new source code is added to the end of the changes file. Any old version which may have been in the file remains in the file. In effect, this means that you've got a log of the history of the changes you've made. This log includes do its which have a permanent effect on the image (for example, defining global variables).
Should your image become damaged (and it's not hard to do), you can use a tool called the change list (see diagram below) to repair it.
This is one of the most arcane tools in the system and is somewhat awkward to use, but since it can almost literally save your life, it's well
The change list tool being used to rebuild an image from a changes file.
worth learning how to use it. Just start up the latest undamaged version of your image, and open a change list from the Changes menu in the launcher. Use the file in/out —> read file/directory command from the operate menu in the top left pane to read into the tool the changes file of the broken image. You can then selectively replay pieces of that file to reconstruct your image. If you're lucky, you'll be able to replay everything you did right up to the moment your image got damaged.
Even if you can't, you should get a long way. When you've finished, make sure you do a 'save-image' to a new file straight away (don't overwrite your last working version though).
Throughout this chapter we've looked at various ways you can enhance your use of the programming tools in the Smalltalk development environment. In particular, we looked at how to make use of the navigation commands in the system browser and its relatives. These enable you to follow message sends both backwards and forwards, which is a big help when you're trying to understand how one of the system classes (or even one of your own) works.
We also looked at getting inspectors open (see below too) and then at using 'chains' of inspectors to explore object instances. Remember that you can execute code in inspectors too.
Workspaces are something that everyone uses differently, but we did consider one or two common ways of using them, and mentioned that any text view in the system can be used as a temporary workspace.
Following on from the discussion of how to write efficient code in the previous chapter, we looked at how to measure the performance both of your own code, and the computer on which you're running it.
Finally, we considered some simple ways of avoiding a catastrophic loss of your work, by using the 'save-image' and file out facilities. If the worst does happen, we looked at using the change list tool to recover your work from the changes file.
If you try some of the things we discussed, you should find that not only are you able to become a more efficient programmer, but that your ability to explore and understand the class library has also increased. These exploration and comprehension skills are vital to realising the full power of the Smalltalk environment.
As it happens though, all of the tools and commands we've looked at here are equally helpful during debugging, and that is the subject of the next chapter.
Using the Development Tools