Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Team "Clubbing of Baby Seals" - Introduction to Squeak, its Tools, and GUI Debugging Case Study
...formerly known as "Team 25"...
Courtesy of Toogle
Who:- Tom Filip
- Mark Shalda
- Matt Plowden
What:- Quick intro to Squeak
- Sample problems in Squeak
- In-depth complex problem solutions
Why: This webpage will hopefully serve as a resource for future 2340/Squeak students, by providing them
with experience that took our team hours of trial and error or researching to figure out.
How: Please take a look at the following sections, and the hints / tips, strategies involved.
Writing your first program
Division of responsibilities
Management of others
Validating the end result
Debugging GUI problems / TextMorph in detail
Other Teams' good Case Studies!
Tips on Design
You will probably hear a lot of things about Squeak even before you begin the class. While some of the things you hear are better, some are worse, do not by any means underestimate this class! While it is easier than 2335, you still need to dedicate appropriate time to:
- completing projects
- study for exams
Squeak is incredibly different from Java in the sense that it uses late binding. For all you skeptics that think 2340 could be taught in Java or C++, none of these languages have the flexibility of late binding, excellent debugging, inspecting abilities (examples follow) - dynamic object manipulation a t runtime. While Java and C++ have a wider usage in the real world, Squeak introduces important concepts that cannot be portrayed by these languages. In this sense, your design environment, your runtime environment, your debugging environment are all the same thing.
It may be intimidating to sink into a new language, new environment, new ways, but once you get a hold of the basics, it's not that bad. Okay, now that you have downloaded Squeak and ran "Squeak.exe" on your PC, here is where you stand:
First thing you need to do is click on the gray background area, and a world menu will pop up. From there, you proceed to OPEN a MORPHIC PROJECT, and for convenience, blow it up to be full screen:
1. 2. 3.
At this point, the three essential tools in Squeak you will be working with are WORKSPACE, TRANSCRIPT, and SYSTEM BROWSER. Click on the TOOLS menu on the right, and drag and drop these three tools onto the white area, like so:
A big concept/difference between Squeak and all other languages involves these three:
System BrowserBesides the internet and the book, this is your API. That's where all objects and methods are, so you will be CODING new things and searching for existing features in there. You can use the Method Finder, also located in TOOLS to help find methods/objects you may need.
Important things that matter:
1. This section lists "groups" of objects. For example, we are in "Morphic-Basic." This category includes all the basic objects that form everything you see in Sqeuak. They are the Java equivalent to JLabels, JPanels, etc.
2. Section two shows the actual objects in that category. Currently, we selected object TextMorph.
3. While this section has no meaning to the computer, it can improve organization for human users. You can organize different methods in "4" by accessors, modifiers, event-handlers, etc.
4. List of methods for selected object in "2" - TextMorph.
5. Instance versus Class. In java, it would be Object vs. Static methods.
For example, you would call a static method like this:
While a dynamic/object method like that:
a := new ObjectName.
6. The actual code itself.
This is the equivalent of System.out.println(...) or fprintf(stdout, ...), for Java or C, respectivelly. Anytime you want to print something out (say for debug purposes), call the following within your code:
Transcript show: 'A String of What you want to display'; cr.
Workspace is kind of like your command prompt but more, in the sense, that it executes lines / sections of code, it stores variables. You can type in anything, then hit either 'Alt-D' for do it (execute), or 'Alt-P' for print it (show result).
A few additional core features of Squeak that other languages may not directly have available are the inspector, and the debugger.
Inspector:For example, let's execute the following command in the workspace:
tm := TextMorph new openInWorld.
This will bring up a TextMorph object in the screen, like so:
If we click on the wrench halo icon, we will be presented with an option to Inspect the object, like so:
Please note, that you can inspect ANY object in squeak. All you have to do is select the appropriate reference, and hit Alt-I (for inspect). This brings up the inspector window:
The inspector is so powerful, because it lets the user to poke around the object, and look at all it features (in this case, dimensions, coordinates, owner, submorphs, etc., etc.), from which you can infer even more information (such as, how to change text, change color, etc.) with the combination of the System Browser. With a little common sense, and the inspector, you at times don't even need an API. Even if you don't know where to begin tackling a problem, you can try simulating it's components / features, and use the inspector to give you a start. It's an essential feature for Squeak.
Debugger:Last but not least, the debugger. Like we said before, the advantage of late binding applies to the debugger as well. You can modify your objects/code while they are running, while you debug them. The debugger pops up anytime you don't specify the proper call or proper argument (obviously), and it can also be instantiated by putting a 'self halt' call in the code like so:
This window shows you the current stack, when you hit Debug, the debugger window will show:
From this point on, you can click a method in the stack (in this case initialize), and see where you currently are. You can use a combination of PROCEED, INTO, OVER... to step through your program and try to catch the bug. Kind of like the inspector, the debugger shows you all the variables (bottom region) for the current scope. You can see the values of these, modify them on the fly (e.g., to see if b would work if a fails), edit and save the code, restart the execution of a method after you've done changes, etc. Sky is the limit.
First, you need to create a category to place your class/object in. This is done by clicking 'add item...' on the left side of System Browser.
Once you have created and selected a category, you can start adding new classes. The way you add a new class is you overwrite the NameOfSubclass
to whatever you want the new object to be called. For example, if we want to create an object that spits out a "Hello World!" message, we do the following:
(Note: where it says "THIS CLASS HAS NO COMMENT!" is where you should write a description of what the class does, its variables, etc.)
To create a new method, you have to select a message (method) category, overwrite the predefined template that's shown to whatever you want it to be named. I.e., from this:
Once this is finished and saved, you can go to the WORKSPACE to test your code.
Sure enough, when you create a new HelloWorldMessage object, and ask it to print (press alt-D by each line), the proper text is displayed on the Transcript:
You can repeat this process to code all your future classes and methods!
While this may sound trivial, good teamwork is a must in this class in order to succeed. Here are a few topics that may sometimes pose threats.
If you care about your grades, DO NOT pick you team simply based on friends. Pick it based on reliable people, and people you can work with effectively. Even if you get into a team that is made of your friends, but is not working out, try to find another group that can facilitate better productivity.
People laugh at me when I tell this, yet so many groups fail to do this. Communication is essential. Exchange all sorts of contact info possible. This includes AIM, Email, Cell Phone numbers, etc. You never know when you'll need to get a hold of someone right there and then, and if they check their email twice a day, their email address alone won't do you much good.
Try to be fair in dividing up the work. Also, be suspicious of a group member trying to tackle a very large / difficult part by themselves. More on this below...
While others may seem like efficient workers, it is essential that you have a checks and balances system. Check on others, and make them check on you. Integrate often. Ask others to present their work to you periodically, to ensure you are on schedule.
Two words: START EARLY!
On every phase, before you begin coding, make sure that everyone has the latest code. While some groups insist on using CVS, I can say that we had no issue sticking to simple change sets and email. Before starting, always create a new change set. When done with your work, export this change set, so other group members can file in your work.
Creating a new change set:
Filing out changes after you are done with your part:
Inserting other people's changes:
This is only a quick intro on change sets. There are many more features / topics online or in the book which help you recover from other people's bad changes, inspect change sets, etc.
Make sure (as a group) that the end result works. We got burned once on having a project fail, after we integrated three completely unrelated change sets...and didn't check!
Our Case Study:
Other teams' case studies - also good references:
Team Robot Chicken: Mini Java-to-Squeak Tutorial
Team ASDF - see Comanche Tutorial: Team ASDF Case Page
Team SqueakersAnonymous - see Saving to Disk: Milestone 5: Saving to Disk
10 Good Methods
...and fore more tutorials, help, see the Cases page!
Two main design mechanisms you will be using in this class are CRC cards, and UML diagrams. For CRC, every phase that you update the CRC cards, scan them in and save them. It will help you in the long run, because files aren't as easily lost as paper. Make sure you do CRC cards BEFORE you code. This is the whole point! CRC cards will help you design a better object oriented product in the end. When it comes to UML, use Visio. General tip - have your TA validate your CRC/UML work before it's due, and fix all errors that he sees.
Links to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu
- Fall 2005 Teams last edited on 14 December 2005 at 2:01 pm by lawn-199-77-215-180.lawn.gatech.edu
- Yuan Liu last edited on 27 July 2006 at 7:06 pm by adsl-83-195-187.asm.bellsouth.net
- Summer 2006 last edited on 13 June 2006 at 10:25 pm by adsl-33-173-159.asm.bellsouth.net
- Teddy's CoWeb Assignment 1 last edited on 11 June 2006 at 7:33 pm by r61h153.res.gatech.edu