Hello. In this course,
we will go over how Pharo execution works,
and what sorts of files are used when and where.
Until now you've been using
.image, .source and .change,
and it's probably not clear to you.
It works, but I'd like to explain exactly what it does,
so you can avoid future mistakes and better control your system.
In sum, the Pharo execution model
is a virtual machine that executes compiled code.
This virtual machine is platform specific,
and VMs exist for different versions of MacOS, Windows, Linux,
IOS, ARM and Android.
It's the same execution model as for C# and Java.
In Pharo it's exactly the same.
We have what is called multiple stage compilation.
This means that the code you program is compiled to bytecode,
which is a set of platform neutral instructions.
And the virtual machine transforms bytecode to assembly code.
This is how Pharo works.
It's the same in other object-oriented languages.
The virtual machine is the file.
Depending on your OS, it's either .exe or .app with MAC.
They're virtual machines.
They can be executed in two modes,
either from a command-line,
or in interactive mode with a graphic interface.
For example, with Linux, when you use Pharo on a server
you usually use command-line.
The virtual machine executes compiled code
and generates on the fly assembly.
This compiled code
is packaged and stored in an image.
A memory snapshot.
This image represents a virtualization system for Pharo objects.
We'll see that next.
The virtual machine needs only the image to execute programs.
Because this is where code is compiled and where the objects are.
In addition, we have 3 files.
Image, change and source.
I'll explain each of these files and their role.
The .image file is a memory snapshot that contains objects.
It contains simple objects like points, strings, etc.
Everything we use.
But it also contains compiled methods
and namely compiled classes.
So each time you save your image, all objects are saved to the disc.
Image really is a virtualization system ahead of its time.
At startup,
you get back all the objects you saved.
Namely the program counter,
which will also be saved
and restored exactly where it was before you saved it.
The important thing is that you have an OS and a virtual machine,
and above the virtual machine, you have this system,
which is a memory space where your objects live
and which you can save to your disc or not.
And it contains your compiled objects.
That's why I put "1s" and "0s."
In addition, you have change files.
A change file is a file that contain backups.
Everything you do in Pharo is logged
and entered into a sort of large virtual tape,
which contains all of your additions and modifications.
It's like Big Brother, only it's for Pharo.
You can have fun with it and use it to replay certain sequences.
It's a tape
that contains backups of every action that modifies Pharo.
What happens is that, a change file is associated to an image file.
What's the purpose of this?
When you define a new class,
the class code is not stored in the image file,
it's stored in the change file.
So if you disassociate the two, you could lose your code.
The program will keep executing,
but you might lose the source code of your application.
If we look closely,
I have an image file that contains
my bytecode and compiled objects in binary form,
and next to it, I have a change file that contains a list of changes.
For example, here I added counter, increase and decrease.
Likewise with other classes.
And we have tools that enable you to replay these changes.
In Pharo, you can browse through various versions of methods.
The tools that use different versions of methods use .change.
I drew a dotted line around this couple because it's very important
that .change and .image remain synchronized.
Don't start editing text with Emacs inside .change files.
You can do it, but it's of no real interest.
You'll only break your .change file.
The image file will continue running
because it only uses .change to show data in programming mode.
But I don't advise it.
Generally speaking,
images are handy to develop.
You're working and someone interrupts you.
You save your image and take a break.
When you come back, you're in exactly the same situation.
The entire state of your system is stored on the disc.
You can come back 3 years later
and find exactly the same state as 3 years ago.
But for a software engineer, it's not good practice.
It's fine for development and prototypes.
Please use a Version Control System instead.
We have Monticello,
a versioning system written in Pharo,
and we have a backend for Git.
Save your code in a Version Control System,
then use a continuous integration server such as Jenkins or Travis
to construct your images each time you startup.
People often confuse these two things at first in Pharo.
Images are extremely practical for development.
But when you want
more structured development and greater control,
you must absolutely use classical tools.
They work well.
There is a prototype mode,
but at some point you must save to a Version Control System,
then you can access all versions from your environment.
There are videos that explain the counter class, for example.
There is a third file I haven't talked about yet.
It's the source file.
A source file is a sort of specific change file.
It contains all the textual definitions of the system at .0.
For each new version of Pharo, there is a new .change file,
and this .change file will contain definitions for arrays, sets, etc.
All the methods that are defined
in the core libraries of Pharo.
Generally speaking, you'll want to share this source file
and it's in read-only.
Change files are in write-mode and there is one per image.
Let's take a look.
This is a snapshot of the system status
at the onset of the new version of Pharo 4.0,
which corresponded to this universe.
Then we defined new classes. I defined the Node class.
I created new objects in binary form,
and in the change file associated with my image,
I added my new definitions, which are written here.
Like I said, this file is in read-only mode.
And this one is in write-mode.
Once again we can say that, conceptually speaking,
the image and change files function together.
I hope this has clarified the roles of these 3 files.
What you need to know is that we are putting together
a new change management system
so you can recover your files more easily
or replay various versions of your system.
In the future, there will be better integration with Git,
and we will offer new ways to produce images industrially.