Date: Sat, 23 Aug 1997 21:17:57 -0500 (CDT) X-Sender: email@example.com Mime-Version: 1.0 To: firstname.lastname@example.org From: email@example.com (Ralph E. Johnson) Subject: novice information Status:
>For example, how do >people manage their projects? Multiple images, or fileOuts from a single >image (that are filed in as needed)?
It is nice to "live in an image" so that you can have all your windows, half-baked examples, and little collections of objects start up right where you left off. If projects are quite different, I'll have a separate image for each. However, it is also possible to keep several projects in one image. You can do this by just placing each project in its own category. But sometimes a project also needs to change system code, and sometimes when you go from one project to another, you need to get all your open inspectors, debuggers, and workspaces. The Smalltalk "project" was designed for this purpose.
I am describing how 1.18 works. It may have changed in 1.19.
You can create a new project from the desktop menu open>open project. This will create a little window that represents an entirely new desk top. The menu on that window has the option "enter project". If you choose it, you will get a whole new set of windows. You can "exit project" and go back to the original desktop. You will see that the project window now shows a miniature view of the desktop in that project. This is neat, because the original Smalltalk-80 didn't do that, but everybody thought it should.
It turns out that each project keeps its own change set (at least, Smalltalk-80 V2.0 worked that way). Any change you made in one project would be observed by others (i.e. there is only one set of classes) but if you "file out all changes" from one project, it only files out the code you changed while you were in that project. Thus, it isn't hard to keep project code separated.
One thing to remember is NEVER TRUST AN IMAGE! Images are extremely convenient and fairly fragile. Every so often you will kill an image, and you will lose everything in it. It is possible to recover from your changes log, but it is real pain if you have several weeks of work there to recover. I make it a point to build a new image once a week or so. Some people do it every day. It all depends on your style, I guess. Just because you saved an image doesn't mean that you can start it up again.
>What is the tradeoffs between change sets and fileOuts?
Change sets ARE fileOuts. I think you mean, "what is the tradeoff between using 'file out all changes' and filing out a whole category." The main problem with filing out a category is that all your code might not be there. The problem with filing out all changes is that you get one big file, and maybe you want five files, one for each category. You can solve this problem a little with projects. But on a large system, I tend to file out each major category and then to say "file out all changes" to get the rest. The original Smalltalk-80 system would remove code from the change set when you explicitly filed it out. This caused problems a few times when you filed it out just so you could print it. However, it made it easy to file out the categories and then get the system changes separately. Later on they made it so that filing out a category didn't remove the code from the change set. Then I would build a script that would file out the categories of interest, remove them from the change set, and then file out all changes. We had a few hundred classes, so it was worth while being careful about this.
In the old days, I had two ways to file out a little code and not let it affect the change set. The best way was to save my image, file out the code, and then start up the saved image. The second way was to file the code back in again.
Note that "file out all changes" never removed the changes from the change set. It was only filing out changes from the browser. You should check to see which way Squeak does it.
Note that Smalltalk is better than "make". It is easy to write scripts that file in code. These scripts can check various conditions and so you can support multiple versions of a system. You can also write scripts to maintain those files. ENVY does this all even better, of course, but it will be some while before there is an ENVY for Squeak, and the idea of buying a $10,000 product to use with free software is a little wierd!
"More About Squeak..."
Last modified at 1/30/98; 9:43:20 AM
Home Page for How To Squeak
Other Links of Interest
College of Computing | EduTech Institute | GVU Center
Mark Guzdial | CS2390, Modeling and Design | STABLE
Last modified at 1/30/98; 9:43:20 AM