Date: Sat, 23 Aug 1997 21:17:57 -0500 (CDT)
X-Sender: johnson@128.174.252.12
Mime-Version: 1.0
To: guzdial@cc.gatech.edu
From: johnson@cs.uiuc.edu (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!


-Ralph