Salut. Dans ce cours, j'aimerais aborder avec vous
comment l'exécution de Pharo fonctionne et quelles sortes
de fichiers sont utilisés et où et quand.
Parce que pour le moment, vous avez dû utiliser Pharo,
vous avez eu un point images, un point source et un point
change, ça doit être complètement obscur pour vous, ça
fonctionne très bien mais là j'aimerais vous expliquer ce
que ça fait exactement, de façon à ce que vous évitiez de
faire des bêtises dans le futur et que vous contrôliez un
peu mieux votre système.
En gros, le système d'exécution de Pharo, c'est une
machine virtuelle qui exécute du code compilé.
La machine virtuelle est spécifique à une plateforme et
il y a des VM qui existent pour Mac OSX, Windows, Linux,
différentes versions, iOS, ARM, Androïd.
C'est le modèle d'exécution de C sharp, de Java, c'est
exactement le même dans Pharo.
Et on a ce qu'on appelle une compilation multiple, ça
veut dire que le code que vous écrivez en Pharo est
compilé vers du bytecode. Le bytecode, c'est un ensemble
d'instructions qui est indépendant de la plateforme, et
la matière virtuelle va transformer dynamiquement ce
bytecode en assembleur lors de l'exécution.
Voilà comment fonctionne Pharo, c'est pareil que dans les
autres langages objet de base.
La machine virtuelle, c'est le fichier.
Suivant votre OS, ça va être le fichier qui est en point exe.
Sur Mac, ça va être en point app.
Ce sont des machines virtuelles que l'on peut exécuter de
2 manières, soit avec une instruction aux command-line,
soit en mode interactif, ça veut dire avec une interface
graphique, ça dépend. Par exemple sur Linux, quand on
utilise Pharo sur un serveur, on va utiliser souvent en mode command-line.
La machine virtuelle, c'est ce que je disais tout à l'heure,
elle prend du code compilé, elle génère de l'assembleur au vol.
Maintenant, le code compilé est packagé, stocké dans ce
qu'on appelle une image.
C'est un snapshot aussi, c'est un système de virtualisation.
En fait, l'image représente un système de virtualisation
pour les objets Pharo. On va voir ça juste après.
La machine virtuelle, elle, pour s'exécuter n'a besoin
que de l'image parce que c'est là où le code est compilé
et où sont les objets.
A côté de la machine virtuelle, on a 3 fichiers.
On a le fichier image, le fichier change et le fichier source.
Je vais vous expliquer chacun de ces fichiers et quels rôles ils jouent.
Le fichier image, c'est une sorte de cache qui contient des objets.
Il contient des objets tout simples: les points, les
chaînes, tout ce qu'on va manipuler.
Mais il contient aussi les méthodes compilées et en
particulier aussi les classes qui ont été compilées.
À chaque fois que vous allez sauver votre image, tous les
objets sont sauvés sur disque.
L'image, c'est vraiment un système de virtualisation
avant l'heure et au démarrage, tous vos objets qui ont
été ça sérialisés sur disque vont être remis en mémoire,
en particulier le pointeur de programme va aussi être
sauvé et rétabli exactement à l'endroit où il était avant
que vous sauviez.
Ce qu'il faut voir c'est que vous avez un OS, vous avez
la machine virtuelle, et sur cette machine virtuelle vous
avez ce système qui est en fait un espace mémoire dans
lequel vos objets vivent et que vous allez pouvoir sauver sur disque ou pas.
Et lui contient des objets compilés, c'est pour ça que j'ai
mis des petits 1 et 0 sur le dessin.
A côté de ça vous avez le fichier change.
En fait c'est un fichier qui contient des enregistrements.
Tout ce que vous faites dans Pharo est loggé, est écrit
dans une sorte de grande cassette virtuelle qui
représente toutes les additions, les modifications, tout
ce que vous avez fait. C'est comme Big Brother mais c'est
pour Pharo et donc on peut s'amuser, on peut l'utiliser
pour rejouer certaines séquences parce que c'est une
cassette qui contient des enregistrements qui sont des
actions qui modifient Pharo. Un fichier changes
est associé à un fichier image.
En particulier, à quoi ça sert ?
Quand vous allez définir une nouvelle classe, le code de
la classe n'est pas stocké dans le fichier image, il est
stocké dans le fichier changes et si vous dissociez les
2, vous allez peut-être perdre votre définition de code.
Le programme va continuer à s'exécuter mais vous allez
peut-être perdre le source code de votre application.
Si on regarde, j'ai mon image qui contient mon bytecode,
mes objets compilés et à côté de ça, j'ai mon fichier
changes qui contient une liste de changements.
Là par exemple je dis "Ah ben tiens, on a ajouté la
classe Counter, on a ajouté la méthode increase, la
méthode decrease et on a fait la même chose sur d'autres classes.
" On a des outils qui permettent de rejouer ces changements-là.
Vous avez peut-être vu dans Pharo qu'on a aussi la
possibilité de browser différentes versions de méthodes.
Les outils qui utilisent différentes versions de méthodes
utilisent le point changes. J'ai mis ces pointillés
autour de ce couple parce que c'est très important de
garder le point changes et le point image synchronisés.
N'allez pas vous amuser à éditer avec emacs à l'intérieur du point changes.
Vous pouvez le faire mais ce n'est pas très intéressant,
parce que vous allez casser votre point changes.
L'image va continuer à fonctionner parce qu'elle s'en
sert juste, quand on est en mode de développement, pour
nous montrer de l'information. Mais c'est dommage, ne le faites pas.
De manière générale, j'ouvre une parenthèse, une image c'est
vraiment quelque chose de très cosy.
Vous êtes en train de programmer, il y a quelqu'un qui
vous interrompt, vous sauvez votre image, vous allez
boire un café, vous relancez votre image, vous êtes
exactement dans la même situation. Vous avez complètement
stocké l'état de votre système sur disque.
Vous pouvez faire ça et revenir dans 3 ans, et 3 ans en
arrière vous aurez exactement le même état que celui dans
lequel vous étiez 3 ans en arrière.
Le problème, c'est que d'un point de vue généologiciel,
ce n'est pas une bonne pratique.
Ça veut dire que c'est très bien de l'utiliser pour du
développement et du prototypage, utilisez un système de
version de contrôle, on a Monticello qui est un système
de version de contrôle qui est écrit en Pharo, il y a des
back end pour Git pour sauver votre code, vous le sauvez
dans un système de version de contrôle, et après vous
allez utiliser un serveur d'intégration comme Jenkins ou
Travis pour construire vos images à chaque fois que vous allez démarrer.
Souvent les gens qui arrivent sur Pharo confondent ces 2 choses.
Les images sont super pratiques quand on est en mode
développement, quand on veut faire du développement un
peu structuré et contrôler un peu, il faut absolument
utiliser des outils classiques qui fonctionnent très bien
parce qu'en fait, on est en mode prototype dans certains,
quand on arrive à un point, on va sauver sur un système
de version et on va pouvoir accéder à toutes nos versions
depuis l'environnement. Il y a des vidéos qui vous
montreront ça ou qui vous ont déjà montré ça sur la
classe Counter par exemple.
Il reste un troisième fichier dont je n'ai pas parlé qui
s'appelle le fichier source.
En fait, le fichier source, c'est un fichier changes un peu particulier.
Il va contenir toutes les définitions du système à l'instant T0.
A chaque fois que vous avez une nouvelle version de
Pharo, il y a un nouveau fichier point changes, et vous
voyez que ce fichier va contenir les définitions des
tableaux, les définitions des ensembles, toutes les
méthodes qui sont définies sur toutes les librairies
corps de Pharo. En général, ce fichier source vous allez
le partager et il est en read-only, alors que le fichier
change il y en a un par image et il est en écriture.
Si on regarde là ce que je vous montre, c'est un état du
système où on a commencé avec une nouvelle version de
Pharo 4 qui correspondait en fait à ce monde-là,
et tout d'un coup vous avez défini de nouvelles classes.
Là, j'ai défini la classe Node, donc j'ai créé des
nouveaux objets à l'intérieur de mon aspect binaire.
Et dans le fichier changes associé à mon image, j'ai eu
des nouveaux enregistrements qui ont été écrits ici.
Comme je vous ai dit que ce fichier-là, de toute façon il
était read-only, et lui il est write.
Vous voyez encore une fois, on va dire que
conceptuellement, ce sont 2 fichiers qui fonctionnent
ensemble, l'image et le changes.
J'espère que ça a un peu clarifié les rôles de ces 3 fichiers.
Maintenant ce qu'il faut savoir, c'est qu'on est en train
de mettre en place un nouveau mécanisme de gestion de
cette cassette, de façon à pouvoir récupérer plus
facilement quand vous avez un crash ou que vous voulez
rejouer et voir toutes les versions de votre système.
Dans le futur, il va y avoir une bien meilleure
intégration avec Git, et aussi de meilleures façons de
produire des images de manière industrielle.