1
00:00:00,280 --> 00:00:02,400
Hello. In this course,

2
00:00:02,560 --> 00:00:06,920
we will go over
how Pharo execution works,

3
00:00:07,080 --> 00:00:10,840
and what sorts of files are used
when and where.

4
00:00:11,000 --> 00:00:13,040
Until now you've been using

5
00:00:13,200 --> 00:00:15,640
.image,
.source and .change,

6
00:00:15,800 --> 00:00:18,120
and it's probably not clear to you.

7
00:00:18,280 --> 00:00:22,080
It works, but I'd like to explain
exactly what it does,

8
00:00:22,240 --> 00:00:26,400
so you can avoid future mistakes
and better control your system.

9
00:00:27,080 --> 00:00:30,240
In sum,
the Pharo execution model

10
00:00:30,400 --> 00:00:33,200
is a virtual machine
that executes compiled code.

11
00:00:33,360 --> 00:00:36,920
This virtual machine
is platform specific,

12
00:00:37,080 --> 00:00:42,680
and VMs exist for different versions
of MacOS, Windows, Linux,

13
00:00:42,840 --> 00:00:44,600
IOS, ARM and Android.

14
00:00:44,760 --> 00:00:49,400
It's the same execution model
as for C# and Java.

15
00:00:49,560 --> 00:00:51,560
In Pharo it's exactly the same.

16
00:00:52,040 --> 00:00:55,200
We have what is called
multiple stage compilation.

17
00:00:55,360 --> 00:01:00,080
This means that the code you program
is compiled to bytecode,

18
00:01:00,240 --> 00:01:03,520
which is a set
of platform neutral instructions.

19
00:01:03,680 --> 00:01:09,160
And the virtual machine transforms
bytecode to assembly code.

20
00:01:09,480 --> 00:01:11,000
This is how Pharo works.

21
00:01:11,160 --> 00:01:14,600
It's the same
in other object-oriented languages.

22
00:01:15,560 --> 00:01:17,880
The virtual machine is the file.

23
00:01:18,040 --> 00:01:22,120
Depending on your OS,
it's either .exe or .app with MAC.

24
00:01:22,280 --> 00:01:23,760
They're virtual machines.

25
00:01:23,920 --> 00:01:26,840
They can be executed
in two modes,

26
00:01:27,000 --> 00:01:30,280
either from a command-line,

27
00:01:30,440 --> 00:01:34,200
or in interactive mode
with a graphic interface.

28
00:01:34,360 --> 00:01:38,200
For example, with Linux,
when you use Pharo on a server

29
00:01:38,360 --> 00:01:40,440
you usually use command-line.

30
00:01:40,920 --> 00:01:43,720
The virtual machine executes
compiled code

31
00:01:43,880 --> 00:01:46,040
and generates on the fly assembly.

32
00:01:46,200 --> 00:01:48,240
This compiled code

33
00:01:48,400 --> 00:01:51,960
is packaged and stored in an image.

34
00:01:52,200 --> 00:01:53,960
A memory snapshot.

35
00:01:54,120 --> 00:01:58,960
This image represents a virtualization
system for Pharo objects.

36
00:01:59,120 --> 00:02:00,720
We'll see that next.

37
00:02:01,000 --> 00:02:04,880
The virtual machine needs
only the image to execute programs.

38
00:02:05,040 --> 00:02:10,240
Because this is where code is compiled
and where the objects are.

39
00:02:10,640 --> 00:02:13,200
In addition, we have 3 files.

40
00:02:13,360 --> 00:02:16,320
Image, change and source.

41
00:02:16,480 --> 00:02:19,560
I'll explain each of these files
and their role.

42
00:02:19,840 --> 00:02:25,120
The .image file is a memory snapshot
that contains objects.

43
00:02:25,280 --> 00:02:29,120
It contains simple objects
like points, strings, etc.

44
00:02:29,440 --> 00:02:30,800
Everything we use.

45
00:02:30,960 --> 00:02:34,200
But it also contains compiled methods

46
00:02:34,360 --> 00:02:37,120
and namely compiled classes.

47
00:02:37,560 --> 00:02:41,920
So each time you save your image,
all objects are saved to the disc.

48
00:02:42,080 --> 00:02:46,560
Image really is a virtualization system
ahead of its time.

49
00:02:47,280 --> 00:02:49,440
At startup,

50
00:02:49,600 --> 00:02:53,400
you get back all the objects you saved.

51
00:02:53,560 --> 00:02:55,440
Namely the program counter,

52
00:02:55,600 --> 00:02:58,880
which will also be saved

53
00:02:59,040 --> 00:03:02,680
and restored exactly
where it was before you saved it.

54
00:03:03,480 --> 00:03:07,800
The important thing is that
you have an OS and a virtual machine,

55
00:03:07,960 --> 00:03:11,720
and above the virtual machine,
you have this system,

56
00:03:11,880 --> 00:03:15,240
which is a memory space
where your objects live

57
00:03:15,400 --> 00:03:18,040
and which you can save
to your disc or not.

58
00:03:18,560 --> 00:03:21,440
And it contains your compiled objects.

59
00:03:21,600 --> 00:03:24,360
That's why I put "1s" and "0s."

60
00:03:25,200 --> 00:03:27,440
In addition,
you have change files.

61
00:03:27,600 --> 00:03:31,440
A change file
is a file that contain backups.

62
00:03:31,840 --> 00:03:34,600
Everything you do in Pharo is logged

63
00:03:34,760 --> 00:03:38,080
and entered into
a sort of large virtual tape,

64
00:03:38,240 --> 00:03:41,800
which contains all
of your additions and modifications.

65
00:03:41,960 --> 00:03:44,480
It's like Big Brother,
only it's for Pharo.

66
00:03:44,640 --> 00:03:48,880
You can have fun with it and use it
to replay certain sequences.

67
00:03:49,040 --> 00:03:50,680
It's a tape

68
00:03:51,080 --> 00:03:54,640
that contains backups
of every action that modifies Pharo.

69
00:03:55,120 --> 00:04:00,080
What happens is that, a change file
is associated to an image file.

70
00:04:00,600 --> 00:04:02,160
What's the purpose of this?

71
00:04:02,320 --> 00:04:04,400
When you define a new class,

72
00:04:04,560 --> 00:04:08,280
the class code is not stored
in the image file,

73
00:04:08,440 --> 00:04:11,160
it's stored in the change file.

74
00:04:12,960 --> 00:04:16,920
So if you disassociate the two,
you could lose your code.

75
00:04:17,080 --> 00:04:19,000
The program will keep executing,

76
00:04:19,160 --> 00:04:22,760
but you might lose
the source code of your application.

77
00:04:23,040 --> 00:04:24,440
If we look closely,

78
00:04:24,600 --> 00:04:26,760
I have an image file that contains

79
00:04:27,160 --> 00:04:31,040
my bytecode and compiled objects
in binary form,

80
00:04:31,200 --> 00:04:35,880
and next to it, I have a change file
that contains a list of changes.

81
00:04:36,040 --> 00:04:39,800
For example, here I added counter,
increase and decrease.

82
00:04:40,720 --> 00:04:42,680
Likewise with other classes.

83
00:04:42,840 --> 00:04:46,760
And we have tools that enable you
to replay these changes.

84
00:04:46,920 --> 00:04:50,960
In Pharo, you can browse through
various versions of methods.

85
00:04:51,120 --> 00:04:54,920
The tools that use different versions
of methods use .change.

86
00:04:55,080 --> 00:04:59,800
I drew a dotted line around this couple
because it's very important

87
00:04:59,960 --> 00:05:04,200
that .change and .image
remain synchronized.

88
00:05:04,360 --> 00:05:07,840
Don't start editing text with Emacs
inside .change files.

89
00:05:08,000 --> 00:05:10,480
You can do it,
but it's of no real interest.

90
00:05:10,640 --> 00:05:12,960
You'll only break your .change file.

91
00:05:13,400 --> 00:05:15,760
The image file will continue running

92
00:05:15,920 --> 00:05:19,360
because it only uses .change
to show data in programming mode.

93
00:05:19,520 --> 00:05:20,960
But I don't advise it.

94
00:05:21,480 --> 00:05:23,760
Generally speaking,

95
00:05:23,920 --> 00:05:26,880
images are handy to develop.

96
00:05:27,040 --> 00:05:29,520
You're working
and someone interrupts you.

97
00:05:29,680 --> 00:05:32,040
You save your image and take a break.

98
00:05:32,200 --> 00:05:36,240
When you come back,
you're in exactly the same situation.

99
00:05:36,400 --> 00:05:40,840
The entire state of your system
is stored on the disc.

100
00:05:41,000 --> 00:05:43,160
You can come back 3 years later

101
00:05:43,320 --> 00:05:46,480
and find exactly
the same state as 3 years ago.

102
00:05:46,760 --> 00:05:50,400
But for a software engineer,
it's not good practice.

103
00:05:50,560 --> 00:05:53,560
It's fine for development
and prototypes.

104
00:05:53,720 --> 00:05:56,640
Please use
a Version Control System instead.

105
00:05:56,800 --> 00:05:58,320
We have Monticello,

106
00:05:58,480 --> 00:06:00,720
a versioning system written in Pharo,

107
00:06:00,880 --> 00:06:02,560
and we have a backend for Git.

108
00:06:02,720 --> 00:06:07,400
Save your code
in a Version Control System,

109
00:06:07,560 --> 00:06:12,280
then use a continuous integration
server such as Jenkins or Travis

110
00:06:12,440 --> 00:06:15,560
to construct your images
each time you startup.

111
00:06:15,720 --> 00:06:19,480
People often confuse
these two things at first in Pharo.

112
00:06:19,640 --> 00:06:22,600
Images are extremely practical
for development.

113
00:06:22,760 --> 00:06:24,680
But when you want

114
00:06:24,840 --> 00:06:27,800
more structured development
and greater control,

115
00:06:27,960 --> 00:06:30,960
you must absolutely use
classical tools.

116
00:06:31,320 --> 00:06:32,480
They work well.

117
00:06:32,640 --> 00:06:34,280
There is a prototype mode,

118
00:06:34,440 --> 00:06:38,560
but at some point you must save
to a Version Control System,

119
00:06:38,720 --> 00:06:42,200
then you can access
all versions from your environment.

120
00:06:42,360 --> 00:06:46,480
There are videos that explain
the counter class, for example.

121
00:06:46,640 --> 00:06:49,800
There is a third file
I haven't talked about yet.

122
00:06:49,960 --> 00:06:51,680
It's the source file.

123
00:06:51,960 --> 00:06:55,400
A source file
is a sort of specific change file.

124
00:06:55,560 --> 00:06:59,840
It contains all the textual definitions
of the system at .0.

125
00:07:00,000 --> 00:07:04,000
For each new version of Pharo,
there is a new .change file,

126
00:07:04,160 --> 00:07:09,360
and this .change file will contain
definitions for arrays, sets, etc.

127
00:07:09,520 --> 00:07:12,240
All the methods that are defined

128
00:07:12,400 --> 00:07:16,000
in the core libraries of Pharo.

129
00:07:16,680 --> 00:07:20,520
Generally speaking,
you'll want to share this source file

130
00:07:20,800 --> 00:07:22,160
and it's in read-only.

131
00:07:22,360 --> 00:07:26,080
Change files are in write-mode
and there is one per image.

132
00:07:26,240 --> 00:07:28,400
Let's take a look.

133
00:07:28,560 --> 00:07:31,640
This is a snapshot of the system status

134
00:07:31,800 --> 00:07:34,720
at the onset
of the new version of Pharo 4.0,

135
00:07:34,880 --> 00:07:37,880
which corresponded to this universe.

136
00:07:39,040 --> 00:07:43,080
Then we defined new classes.
I defined the Node class.

137
00:07:43,240 --> 00:07:47,520
I created new objects in binary form,

138
00:07:47,680 --> 00:07:51,640
and in the change file
associated with my image,

139
00:07:51,800 --> 00:07:55,560
I added my new definitions,
which are written here.

140
00:07:55,960 --> 00:07:59,440
Like I said,
this file is in read-only mode.

141
00:08:00,520 --> 00:08:02,440
And this one is in write-mode.

142
00:08:02,800 --> 00:08:06,760
Once again we can say that,
conceptually speaking,

143
00:08:06,920 --> 00:08:10,120
the image and change files
function together.

144
00:08:10,280 --> 00:08:13,920
I hope this has clarified the roles
of these 3 files.

145
00:08:14,080 --> 00:08:18,400
What you need to know
is that we are putting together

146
00:08:18,560 --> 00:08:21,840
a new change management system

147
00:08:22,000 --> 00:08:25,280
so you can recover your files
more easily

148
00:08:25,440 --> 00:08:28,360
or replay various versions
of your system.

149
00:08:28,520 --> 00:08:32,160
In the future, there will
be better integration with Git,

150
00:08:32,720 --> 00:08:36,880
and we will offer new ways
to produce images industrially.