Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
The Thing You Will do Daily in Smalltalk - A Guide on how to recover your code
Small talk may be a huge collection of classes, totally OO, and unit tested, but that doesn't mean that a primitive won't fail in a language that apparently doesn't have them. So Smalltalk Closed on you and you think you've lost half of your work. Thankfully the creators of this version of Smalltalk incorporated several ways to recover and back-up your code and some 'tricks' if the worse happens or some advice on how to prevent it.
Backing up Code:
Constant and consistent backups are your best choice while using this IDE. You will end up finding random errors, bugs, loops, error messages, and just about anything you can think of happening which will render your last 2 hours worthless. Because the IDE is apart of the image, and the code you are submitting isn't saved in the image until you tell it, only your changes are saved. This creates a potential hassle and can be avoided by doing the following.
Easily the safest way to backup your code. This is how you will submit your code to the teachers, and it is a very nice way of keeping a local backup in case you accidentally went into the debug menu and started playing with the wrong packages. Saving the image won't save you there. To do this you will look at the browser, right click on the package name, and then go to File Out->Package. Perhaps have a space to place a collection of these (such as accomplishments) just in case. I would recommend you do this before you actually do any other form of saving.
The repository is okay, but you can end up overwriting code if several people are using the same packages and aren't committing correctly. Basically you have to pay attention to who is editing what or you will end up causing huge rollback issues. Set up specific times to have everyone commit, retest the unit tests and everything, then load the new version. If people are working on to old of a version it can cause huge issues. To create a login to be able to store to the repository, go to http://www.cincomsmalltalk.com:8008/launch/PostGresRequest and just follow the steps. It takes just a few minutes and it's pretty easy.
Once you have a username and password, connect to the repository. Right click in the browser window on your package and publish. I have never seen this option fail and is a pretty safe bet for backing up your code. This is likely the second easiest and safest form of backing up that you have access to.
This can actually be very dangerous. Remember, that even though you are pressing control+s in the browser, your IMAGE is not saved. Instead the changes are being saved to a separate file called the change list in case VWST crashes. Several times while trying to save the image I received errors like "A Primitive has Failed", or the application just closes. It seems like a really bad thing, but it happens. Also note, that if any of your windows are 'broken' (Gray), or you have any windows open that are bugged, this will SAVE those windows into your image. You are better off Filing out or submitting to the repository and opening a fresh image. (You started with a new image when you used the program, didn't you?)
Obviously, if you crashed, the easiest thing to do is recover your backup. The following sections are covering how to restore your backups from the previous section as well as showing you the use of the Change List and how to recover code this way.
If you have a recent copy of your code, filing in what you have is a good idea. This will give you a good base and reference point in case you want to use the Change List in order to try to recover all of your code. To File In, you have two options. Delete your old package, then File In as a new package, or overwrite your old package. The best way to do this is to just delete your old package and insert the backup. This is because if you had deleted anything in the backup from the code currently in your image, it will still be there when you load. This may cause issues, but it likely will just be dead code. Right click on your package, Remove (Unload). Right click and re-create your package name, then right click on it and File Into. Select your saved file and click Okay. If you are prompted to initialize any packages, click no. This will delete all instance variables for that class and only seems to happen to some packages.
You will access the repository from the Image window, Store->Published Items, search for your package name and load the most current. Again, you can choose to load or remove your current package as you had done before, but it's just if you know you had deleted methods or classes from one instance to the next. It isn't hard to remove them manually later, but it may save some time if you did a lot of pruning.
This is where you will recover ALL of your lost code or help complete a backup that wasn't as new as it could have been. Go to your image window, Tools->Change List (F7). This will open a large file which contains EVERY piece of code that was placed, saved, or RAN. This includes the workspace, and even bad code. The thing is you will 'replay' the changes and hopefully get a final product that is the same as you last remember it. You have several options: find the code lines that you know were before the crash, click on the first one and then click Replay->All From Here Down. This will simulate your saving and changing for every line of code or workspace code ran. If all goes well, you will have no errors and you can be happy. What will likely occur is you replayed to early or to late, and it will throw errors while it is trying to remove methods that don't exist or add methods to classes that aren't created. You can skip these errors and replay from higher up, but more then likely it will be obvious what is wrong and it will be an easy fix. The other thing to do would to be replay the entire file, which I would not recommend. This not only takes a long time but it will simulate hours and hours of coding with projects that aren't even relevant to you right now if you used the same image as your other homeworks. If at all possible, attempt to not use this feature as it can result in you believing code you have is right when it isn't. When finished using the Change List at any time, MAKE SURE you verify the changes happened before continuing.
Of course, prevention is key. There were several instances of errors that I received which seemed to happen during certain operations. Hopefully they will help you.
This often happened when you would leave Smalltalk open for to long (several days). It also occurred some times while trying to Save the Image, especially after downloading large packages from the repository. To minimize your losses, make sure that you save your image after loading new packages, and to close smalltalk after you are done programming.
This is an easy fix, as long as you don't get caught in a looping error message, simply file out. To Prevent it, just make sure you only edit classes you created. It can be very easy to open the debugger and just follow the highlights and change code until it works, just play it safe.
You can exit the loop by pressing Control+w (press it several times). This does not always fix the issue, but it may. This will fix basic loops, and only some looping error messages, likely due to GUI related issues. Check your code for GUI extremely well, this often results in having to close Smalltalk with out saving.
These buggers are not close-able, alt-f4-able, and save with your image and greet you every time you open it back up. The only work around I was able to find was to actually file out and start from a new image. Similar to failing primitives, this seemed to occur when smalltalk was open for to long.
This guide is mostly information found from Google and simply experience. I would estimate that I lost at least 5 to 10 hours of work due to Smalltalk Failures before I started saving everything regularly and having backups. Don't let this happen to you.
Links to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu
- Index of Individual Cases last edited on 3 May 2011 at 12:46 pm by r52h48.res.gatech.edu