View this PageEdit this Page (locked)Attachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
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"...
Uploaded Image: gatech.jpg
Courtesy of Toogle


- Tom Filip
- Mark Shalda
- Matt Plowden


- Quick intro to Squeak
- Sample problems in Squeak
- In-depth complex problem solutions


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.


Please take a look at the following sections, and the hints / tips, strategies involved.

      Why Squeak
      Starting Out
      Writing your first program

      Forming teams
      Division of responsibilities
      Management of others
      Validating the end result

Case studies
      Debugging GUI problems / TextMorph in detail
      Other Teams' good Case Studies!

Tips on Design
Back to Top


Why Squeak:

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:

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.
Back to Top

Starting Out:

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:

Uploaded Image: image002.jpg

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. Uploaded Image: image004.jpg 2. Uploaded Image: image006.jpg 3. Uploaded Image: image008.jpg

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:

Uploaded Image: image010.jpg

A big concept/difference between Squeak and all other languages involves these three:
Back to Top

System Browser

Besides 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:

Uploaded Image: image012.jpg

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:
      ObjectName methodName.

   While a dynamic/object method like that:
      a := new ObjectName.
      a methodName.

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.

Uploaded Image: image014.jpg


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).
Back to Top

A few additional core features of Squeak that other languages may not directly have available are the inspector, and the debugger.


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:
Uploaded Image: i66.jpg
If we click on the wrench halo icon, we will be presented with an option to Inspect the object, like so:
Uploaded Image: i68.jpg
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:
Uploaded Image: i70.jpg
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.


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:
Uploaded Image: i72.jpg
This window shows you the current stack, when you hit Debug, the debugger window will show:
Uploaded Image: i74.jpg
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.

Writing your first program:

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.

Uploaded Image: image016.jpg   Uploaded Image: image018.jpg

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

Uploaded Image: image020.jpg

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:

Uploaded Image: image022.jpg

(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:
Back to Top

Uploaded Image: image024.jpg


Uploaded Image: image026.jpg

Once this is finished and saved, you can go to the WORKSPACE to test your code.

Uploaded Image: image028.jpg

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:

Uploaded Image: image030.jpg

You can repeat this process to code all your future classes and methods!
Back to Top


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.

Forming teams

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.
Back to Top

Division of responsibilities

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...

Management of others

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!
Back to Top


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:

Uploaded Image: image032.jpg   Uploaded Image: image034.jpg

Filing out changes after you are done with your part:

Uploaded Image: image036.jpg
Back to Top

Inserting other people's changes:

Uploaded Image: image038.jpg   Uploaded Image: image040.jpg
Uploaded Image: image042.jpg

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.
Back to Top

Validating the end result

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!

Case Studies:

Our Case Study:
      Debugging GUIs

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!
Back to Top

Tips on design:

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.
Back to Top

Links to this Page