Pharo architecture
TL;DR
This page provides a high-level overview of the key components of the implementation of Pharo.
Overview
There are four main parts to a classical Smalltalk implementation:
1. The virtual machine (VM), which executes the bytecode and manages memory
2. The sources file, containing all the source code of the core system
3. The changes file containing all the source code modifications to the core system
4. The image file holding a snapshot of all the live objects.
The VM
The virtual machine implements the Smalltalk bytecode, and provides all the runtime support for the Smalltalk system. There will be a different VM for each operating system platform.
The bytecode of most Smalltalk implementations typically follows the specification in the “blue book” (see Smalltalk history).
Sources
The sources file contains a snapshot of all the source code that does not change frequently. There will be one sources file for a given release of the system, for example, Pharo9.0-64bit-f5f541c.sources.
Changes
The changes file logs all source code modifications, that is, changes or additions to classes or methods with respect to the sources file.
Since the changes file logs all source code changes, you can't lose source code , even if the system crashes. In case of a crash (which is always possible, since you can change anything, and thus break the system), you can restart the system and play back your changes using a dedicated change browsing tool.
The image
The image contains a frozen snapshot of all the objects in the running Smalltalk system. Whenever you save and quit the image, all the objects are written to the file and will come back to life when the system is restarted.
An image file is always associated to a changes file. If you save the image under a new name, say myProject.image, then a new changes file called myProject.changes will be created (a copy of the old changes file).
Managing projects
You might think that projects are managed as pairs of image and changes files, but that is not an effective way to track changes and collaborate within teams. Instead, source code for a project is typically stored in a version control system, such as github.
A common way to work is to load a project into a fresh image, work for a while, commit and push all the changes, and then throw away the image. This way you avoid depending on an image that may get cluttered or corrupted over time. On the other hand, you might save a backup image ready to present a demo.