Installing Squeak

Note: The steps below will result in a system-developer's version of Squeak. On the laptop there is a special Squeak distribution derived from squeakland.org. See Etoys for information on the actual OLPC version. --Bert

Multiplatform

Squeak inherited from Smalltalk the binary-image multiple platform capability (ca.1980 much earlier than Java); in order to use it, you need the binary-image (cross-platform) and the virtual machine (OS-specific).

This means that if you develop something in Etoys (Squeak) in your *nix, Mac or Windows machine, you then copy the .image & .changes to the OLPC and it will work exactly the same—no compilation, no conversion, no hassle.

Download files

The latest stable image (not the VM) can be found here.

On the Squeak download page, click the appropriate link to download the virtual machine and image for your computer and operating system.

Pre-built zip files (with all necessary files) exist for Windows and Mac OS. Current stable release is 3.9 (as of 2007-01-23 - please verify and update links if this changes).

For Linux you must download the current release Basic Image file and the executable VM for Linux or the VM source (see here for other flavors).

Installing

Normally, Squeak installations are self-sufficient in the sense that it keeps itself in one directory without messing around with the OS, so all you have to do is make sure that all files reside in a directory of your liking. Sharing the VM, sources and other tidbits is possible—but since you are here you probably want the fast-lane no fuzz installation...

MS-Windows and MacOS

should be straight forward: just unzip.

What follows is for Linux

Untar the file into a directory.

Go into the directory and run

sh ./INSTALL

to install the virtual machine.

Choose or create a directory to run Squeak in, and run

inisqueak

there to create your personal image file.

(I haven't found the inisqueak script, so I hope someone will edit this.)

OR copy the image file, the changes file and the sources file to your working directory, and change their names to squeak.image, squeak.change, and squeak.sources. (I don't yet know if this last is necessary. Anybody?)

Running Squeak

If you are running in a GUI, just drag-n-drop the image file (squeakXXX.image) onto the VM executable (squeak or <squeak.exe>).

Another option is to run it from the command-line which (iirc) goes vm image (ie: squeak squeakXXX.image. (NOTE: I could be mistaken - so check the docs and/or websites ;)

Run

squeak

and you get an amazingly rich but underdocumented graphical programming environement. If OLPC wants a proper manual for all of this, I'm an experienced Tech Writer with lots of API and other programming documentation experience who learned Smalltalk from the books when they first came out, and I'm available.--Mokurai 05:36, 12 October 2006 (EDT)

Notice to Squeak/Smalltalk begginers

I recommend reading some material along, probably starting either at Why Smalltalk's Squeak Tutorials page, or the hectic Squeak.org wiki (or try a Google search)

Squeak, as a direct descendant of Smalltalk-80, basically manages four essential files:

The Virtual Machine (VM)

normally inmutable, so no really a cause of problems

.image

is the file where the snapshot of the objects are stored / serialized. This file is manually saved, so if you exit the environment without saving, you lose (or discard) your changes since the last save.
Discarding (not saving the image) is particularly helpful when you are trying things out or mess up (and you will, trust me, we all have :)

.change

is where the history of all the changes done by the user (method editions, sending messages (manually) to objects, etc.) is stored. That's the reason why it's very important to keep both the .image & .change files together at all times.
Since all the source code of new or modified methods is stored in this file, if you lose it or becomes off-sync with the image, meaning that the source code will be lost. The environment will still work fine (compiled methods are objects, so they'll reside in the image) but you will not be able to browse the code properly. You can still decompile it though ;)
NOTE: never edit this file manually! Although it's used as the deposit for the source-code, you will accomplish nothing (except ruining your sources) in the environment if you do.

.sources

is where the method's sources are kept - but only the 'original' source - once you change a base method, it's source will be stored in .change—so if your paths are correct, this file doesn't need to be copied and is basically a read-only file.

I personally recommend that your first action in the environment is a Save As (with an appropriate and different name—ie: testing.image) so that 'starting from scratch' is just a couple clicks away and will ensure that you always keep the 'original' environment as a backup.