As a newcomer to Smalltlak progarmming, I'm still learning the ropes
on how to effectively manage the development environment and development process. Among the the tips that I have come across in Smalltalk programming is to save and backup the image frequently, in case it becomes corrupt. My question is: why? Why bother backing up the binary image? Once I figured out how to use Dolphin's Package Manager, I thought package maintenance was a snap. The Dolphin environment keeps track of uncommitted classes and globals (though not loose methods) so it was simple to fileOut all of my classes into a PAC or PAX file. Isn't this enough? If my image should become corrupt, shouldn't it be enough to simply install all the packages that I have saved into a fresh new image and thus rebuild and recover the lost image? If so, why would anyone want to back up binary images, especially when PAC and PAX files are text files that can be versioned and checked into CVS? Is it because in ordinary usage, there are hundreds or thousands of user-defined classes stored in dozens of packages, making it incovenient to install the packages into a fresh image? I would think that it would be a useful exercise to install packages into an image anyway to ensure that an image can be rebuilt in case of disaster. It would be akin to the continuous integration practice employed in XP, in which the entire source tree is checked out and rebuilt from scratch along with regression testing, whenever some code is checked in. Is there more to image maintenace that I am not understanding? Damon |
Damon wrote:
> If my image should become corrupt, shouldn't it be enough to simply > install all the packages that I have saved into a fresh new image and > thus rebuild and recover the lost image? That is how I manage it. I take care that the package files are saved out often, and backed up regularly, but I never normally back up the image. I use a fair few scripts to install the 100 plus packages that I usually run with, or to remove the shipped packages that I don't want. Some people go even further and never even *save* the image. Others rebuild it from fresh each day. -- chris |
In reply to this post by Damon
Damon,
> Is there more to image maintenace that I am not understanding? Just to back up Chris' points ... There are only two situations where I backup the three image files. - Immediately after installing a fresh version of Dolphin. This is probably not needed so much now, it's a lot easier to extract a clean image from the distribution files than it used to be. This gives me a base, clean image that I can use for building my working image and also for testing if a bug I'm seeing is due to an image problem or is something I've introduced. - After creating the above I use scripts to install all my working packages and modify the image options to reflect the way I prefer to work. I can overwrite the current image with these files at any time to give me a standard working image. If OA provide any updates I just repeat this step (the script knows where I store OA updates and includes them automatically) and create a new working image and backup. FWIW, I only save the image if - I'm in the middle of doing something and want to remember the current state while I do something else. - I'm about to test something that may break in a big way (_very_ advisable when adding and testing additional View sub classes) - I'm debugging and want to make it as easy as possible to repeat a series of operation on known data Others do things differently - you've just got to find a system that fits in with _your_ way of working -- Ian |
Could you post the script for loading your packages?
This sounds like a good way to work. Thank You, Ben Meyer "Ian Bartholomew" <[hidden email]> wrote in message news:<mOcra.13853$[hidden email]>... > Damon, > > > Is there more to image maintenace that I am not understanding? > > Just to back up Chris' points ... > > There are only two situations where I backup the three image files. > > - Immediately after installing a fresh version of Dolphin. This is > probably not needed so much now, it's a lot easier to extract a clean > image from the distribution files than it used to be. This gives me a > base, clean image that I can use for building my working image and also > for testing if a bug I'm seeing is due to an image problem or is > something I've introduced. > > - After creating the above I use scripts to install all my working > packages and modify the image options to reflect the way I prefer to > work. I can overwrite the current image with these files at any time to > give me a standard working image. If OA provide any updates I just > repeat this step (the script knows where I store OA updates and includes > them automatically) and create a new working image and backup. > > FWIW, I only save the image if > - I'm in the middle of doing something and want to remember the current > state while I do something else. > - I'm about to test something that may break in a big way (_very_ > advisable when adding and testing additional View sub classes) > - I'm debugging and want to make it as easy as possible to repeat a > series of operation on known data > > Others do things differently - you've just got to find a system that > fits in with _your_ way of working |
Ben,
> Could you post the script for loading your packages? It does a bit more than loading packages but it's still not a particularly complex thing to create. The basic idea is that you just replicate in code the steps that you go through when creating a new working image. Rather than posting my script (I have posted a copy before to the group) it's probably easier to go through the basic elements. 1) User Preferences. Any option you set in the Dolphin User Preferences list can be replicated in code - the options are all accessed through class methods. eg. SystemBrowserShell defaultShowInheritedMethods: false. Debugger showWalkbacks: false. SmalltalkWorkspace defaultFont: (Font name: 'Microsoft Sans Serif' pointSize: 10) 1a) There are some changes that can't be accessed in this way. You just have to work out how to do these yourself. For example, to prevent comments being shown in italic Compiler syntaxColorAt: #Comment put: '\cf4 '. 2) Odd changes stored in st files. These are just the odd changes that OA (or others) post in the newsgroup. Rather than edit the script every time I have just created a folder and dump the files in there. File for: (FileLocator imageRelative localFileSpecFor: 'Patches\*.st') do: [:each | SourceManager default fileIn: each path]. 3) st files that I have defined and which can be located anywhere in my local folder hierarchy. This can include patches and further script files written for specific reasons. SourceManager default fileIn: (FileLocator imageRelative localFileSpecFor: 'whatever.st') 4) Packages. I normally do this from a separate st file installed under (3). You can either do this a package at a time or embedding it in a loop and passing the package names. NB You might have to fiddle with the order you load the packages to avoid warnings about packages already being loaded - this normally happens when one package is a prerequisite of another. PackageManager current install: (FileLocator imageRelative localFileSpecFor: 'whatever.pac'). or #'(tom' 'dick' 'harry') do: [:each | PackageManager current install: (FileLocator imageRelative localFileSpecFor: 'ASubPathIfNeeded' , each)]. To create the script file just pick and choose elements from above, add them to a workspace and save as a st file. Keep fiddling until the workspace can be filed into a clean image without error (keep an eye on the Transcript as some warnings are only displayed there). 5) Once you are happy that it works you can, optionally, add another step to the script. In full .... PackageManager current packages do: [:each | each resetChangeFlags]. View destroyAll. [ Processor sleep: 500. SmalltalkSystem current playSaveImageSound; sessionManager saveImage: (SessionManager current imageBase , 'Working'). SourceManager default compressChanges. #('chg' 'sml' 'img') do: [:each | File copy: SessionManager current imageBase , 'Working.' , each to: SessionManager current imageBase , 'backup\Working.' , each]] fork. This cleans up the image, saves it, compresses it and then copies the three new image files to my backup folder. So, when I want a new working image it's just a matter of starting a clean image and filing in one st file. I am then left with a clean set of working image files that are already backed up and ready to be used when I want to restore my working image to it's default state. -- Ian |
Ian,
Thank you, as usual, for supplying such a complete answer. Sorry I didn't notice a similar one you had made in the archive. --Ben |
In reply to this post by Ian Bartholomew-18
Dear Ian,
I had the same criteria for saving before testing some interfaces wirings. Specially the listViews, they ofen drops the image down when you make a mistake on the query for a row representation. That brings you up dozens of walkbacks. bests clicks (on terminate) and atl-F4's, oops, I mean... regards, Seb "Ian Bartholomew" <[hidden email]> escribió en el mensaje news:mOcra.13853$[hidden email]... > Damon, > > > Is there more to image maintenace that I am not understanding? > > Just to back up Chris' points ... > > There are only two situations where I backup the three image files. > > - Immediately after installing a fresh version of Dolphin. This is > probably not needed so much now, it's a lot easier to extract a clean > image from the distribution files than it used to be. This gives me a > base, clean image that I can use for building my working image and also > for testing if a bug I'm seeing is due to an image problem or is > something I've introduced. > > - After creating the above I use scripts to install all my working > packages and modify the image options to reflect the way I prefer to > work. I can overwrite the current image with these files at any time to > give me a standard working image. If OA provide any updates I just > repeat this step (the script knows where I store OA updates and includes > them automatically) and create a new working image and backup. > > FWIW, I only save the image if > - I'm in the middle of doing something and want to remember the current > state while I do something else. > - I'm about to test something that may break in a big way (_very_ > advisable when adding and testing additional View sub classes) > - I'm debugging and want to make it as easy as possible to repeat a > series of operation on known data > > Others do things differently - you've just got to find a system that > fits in with _your_ way of working > > -- > Ian > |
Free forum by Nabble | Edit this page |