Présentation
Le site Pharo World propose une version du VM Pharo compilée en WebAssembly (WASM) et exécutée directement dans le navigateur. L’interface expose des actions classiques – Load, Save, Open File – et accepte les formats Smalltalk .st, les archives .zip contenant une image, ainsi que les paires .image/.changes/.sources. Cette approche permet d’interagir avec un environnement Pharo complet sans installation locale.
Architecture technique
Le cœur du système repose sur le VM Pharo, préalablement compilé avec Emscripten pour produire un module WASM. Ce module est chargé par le moteur JavaScript du navigateur, qui fournit le glue code nécessaire à l’initialisation de la mémoire linéaire et à la liaison des appels système. Le fichier WASM s’exécute dans le sandbox du navigateur, ce qui impose l’utilisation d’un système de fichiers virtuel (généralement MEMFS ou IDBFS) pour stocker temporairement les images et les sources chargées via l’interface.
Le chargement d’un fichier .st ou .zip déclenche une lecture du Blob fourni par l’API FileReader, suivi d’une copie byte‑wise dans la mémoire du VM. Une fois les octets disponibles, le runtime Pharo les interprète comme du bytecode Smalltalk, reproduisant le comportement d’un lancement traditionnel sur desktop.
Gestion des dépendances et du réseau
Pharo World intègre un gestionnaire de proxy configurable pour les opérations Git. Trois modes sont proposés : None (les requêtes sont envoyées directement au serveur distant, ce qui ne fonctionne que si le serveur autorise le CORS), Site default (aucune configuration explicite, le comportement dépend du serveur d’hébergement) et My proxy (un proxy CORS dédié). Le texte indique que les clones, fetches, pulls et pushes d’Iceberg ainsi que les chargements github:// de Metacello sont redirigés via ce proxy, chaque requête étant préfixée par l’URL du proxy suivi du domaine et du chemin du dépôt.
Cette architecture expose deux contraintes majeures : la nécessité d’un serveur CORS compatible lorsqu’aucun proxy n’est utilisé, et la visibilité des identifiants (nom d’utilisateur, token) pour les opérations de push, qui transitent intégralement par le proxy choisi. Le choix du proxy est mémorisé dans le stockage local du navigateur, mais aucune URL de proxy n’est imposée par la page elle‑même.
Limitations et perspectives
Le modèle WASM impose des limites de performance liées à l’absence d’accès direct aux instructions SIMD avancées et à la latence du garbage collector JavaScript. De plus, le sandbox du navigateur empêche l’accès aux périphériques matériels, ce qui restreint les possibilités d’interaction avec le système d’exploitation hôte (par exemple, aucune impression directe ou accès réseau hors CORS). La dépendance à un proxy externe pour les opérations Git introduit un vecteur de risque : le proxy peut inspecter le code source et les credentials, ce qui nécessite une confiance explicite de l’utilisateur.
Malgré ces contraintes, la démonstration montre que le VM Pharo conserve son cycle d’interprétation complet, y compris la console interactive, le gestionnaire d’images et le support des formats standards. Cette preuve de concept ouvre la voie à des environnements de développement Smalltalk hébergés, où la portabilité du code est assurée par le standard WebAssembly.
