Actions in Pharo 1.3 (FR)

Pharo 1.3 résulte de nombreuses modifications visant à améliorer les parties fondamentales du système. Nous sommes heureux et convaincus que le futur bénéficiera largement de ces développements. Nous remercions tous les contributeurs qui nous ont tant aidé. Sans vous Pharo serait plus lent et moins fun.

La version 1.3 ferme plus de 600 demandes du système de suivi. La liste complète est disponible en ligne.

Le serveur d'intégration continue donne continuellement accès à la dernière version, n'hésitez pas à télécharger et tester !

Compléments

La traduction française du livre Pharo by example est finie. Sous licence Creative Commons by-sa, vous pouvez le télécharger en PDF ou bien attendre la version papier qui ne devrait plus tarder.

Le CARA74 utilise principalement Pharo pour ses coding-dojos. Vous pouvez visionnez un nombre croissant de vidéos en français qui montrent Pharo en action.

Suit la liste des évolutions:

Nettoyage des dépendances

Nous avons supprimé beaucoup de dépendances indésirables entre plusieurs paquets. Les outils de la suite Moose nous ont permis d'améliorer fortement l'architecture du système, effort que nous maintiendrons dans le futur. En particulier, nous pouvons identifier plus efficacement les différentes couches du système. Cela est important pour nous permettre de changer des composants larges, d'être agile et d'exposer nos hypothèses.

Application de "code critics" sur tout le système

Nous avons commencé à lancer l'analyse de code sur tout le système et nous corrigeons au fur et à mesure. Nous continuerons dans cette voie et nous allons automatiser cette analyse via le serveur d'intégration continue. En particulier nous avons supprimé plus de duplication de code entre classes que nous pensions en trouver. Nous projetons de créer des règles d'analyse propres à Pharo et d'étendre l'analyse à toutes les applications clientes construites sur le serveur d'intégration.

Support des images sur serveurs, sans interface graphique

Smalltalk est historiquement lié à l'interface graphique. Or une application web ne demande pas d'intéraction côté serveur et Pharo doit pouvoir tourner facilement sur des serveurs démunis de X.

Nous avons introduit une meilleure gestion du modo non-intéractif. Nous voulons être sûrs que Pharo tourne correctement sans interface utilisateur. Idéallement nous voudrions être capable de brancher à chaud une interface graphique sur un système en cours de fonctionnement, mais cela fait encore partie du futur. Au moins vous connaissez notre vision maintenant.

Nous avons amélioré le fonctionnement en ligne de commande. Une nouvelle implémentation permet de passer plusieurs extensions sans conflits.

Pharo supporte maintenant stdin, stdout et stderr.

Meilleure robustesse du démarrage et arrêt du système

Au démarrage et à l'arrêt l'image exécute respectivement les méthodes startUp: et shutdown: des classes abonnées (via les méthodes addToStartUpList:, addToShutDownList:, ... et compagnie). Nous avons amélioré la robustesse des actions réalisées au démarrage en introduisant un processus en deux étapes.

Lors de la première étape du démarrage du gestionnaire d'interface graphique (UIManager), celui-ci est basculé sur un mode non-intéractif (StartupUIManager). Le gestionnaire non-interactif quitte le système dès la première tentative d'ouverture d'une fenêtre ou d'une quelconque interaction avec l'utilisateur. Il est donc important de ne pas utiliser d'interactions utilisateur lors de cette première phase du démarrage.

Ensuite, toutes les classes enregistrées exécutent leur séquence de démarrage (startUp) qui ne doit toujours pas contenir de comportements interactifs.

Une fois cette séquence terminée, toutes les actions de démarrage qui ont été enregistrées comme différées par méthode addDeferredStartupAction: sont exécutées.

Ce changement important structure le démarrage du système et assure que certaines actions se produisent uniquement quand elles peuvent être exécutées.

Meilleure apparence graphique

Nous avons intégré le travail fait dans Moose et réorganisé un peu les thèmes graphique. Certains sont dépréciés. Nous continuerons à améliorer cet aspect.

Meilleures widgets

De façon générale, les composants graphiques de base (« core widgets ») devraient être plus puissants. Nous avons réalisé beaucoup de progrès sur cet aspect et comptons continuer notre effort en ce sens.

Un meilleur support de la coloration syntaxique.

Nous avons introduit un « NullStyler » pour avoir un système plus modulaire.

Dépréciation de ParagraphEditor, introduction de TextEditor

Nous avons déprécié ParagraphEditor et utilisons maintenant TextEditor. Nous avons un meilleur TextMorph qui gère mieux le comportement de chercher / remplacer. La sélection de texte peut maintenant afficher automatiquement toutes les occurrences du texte sélectionné dans le texte complet. Cela permet de modifier le code rapidement.

PluggableTextEditorMorph était funky avec des duplications et donc nous l'avons déprécié.
Meilleur PluggableListMorph & co.

Grâce à l'excellent travail de Benjamin van Ryseghem, plusieurs aspects de PluggableListMorph ont été amélioré:

Support de la sélection multiple.
On peut rechercher parmi les éléments et le focus d'un nouvel élément peut être controlé au clavier.
Le comportement de la sélection peut être modifié à la volée (MultipleListOfMany, PluggableIconListMorphOfMany ont donc été dépréciés car PluggableListMorph peut faire la même chose).
Amélioration des performances de MorphTreeMorph.
Nous avons continué l'intégration de Polymorph au système et revisité certains choix.
Meilleur GeneralScrollPane qui supporte maintenant spaceFill et shrinkWrap.
Nettoyage et simplification du mode modal (n'utilise plus thisContext). Nous avons aussi supprimé des duplications de code.
La gestion des évènements clavier .... MorphTreeMorph keystroke event handling now accept an event.
Nous avons supprimé les vieilles classes inutilisées qui restaient de ST-80.
Les menus sont maintenant construit via UIManager pour ne pas casser le mode non-intéractif.

Meilleurs outils

Notre objectif est d'associer un modèle pour chacun des outils de base, ce qui nous permettra de déprécier la hiérarchie autour de StringHolder. Nous avons bien progressé sur se point. Benjamin van Ryseghem nous a énormément aidé à cette tâche.

L'accès aux outils se fait maintenant via Smalltalk tools toolName.

Côté classe, un outil doit implémenter la méthode #registerToolsOn:. Cette méthode est exécutée automatiquement pour toutes les classes lors de l'évaluation Smalltalk resetTools. Noter qu'avec le registre d'outils, vous n'êtes plus obligé de maintenir (et d'implémenter) un pattern Singleton pour chaque classe d'outil - c'est à dire SomeTool default doSomething. A la place vous pouvez enregistre une instance unique (ou classe) au registre, accessible alors via Smalltalk tools someTool doSomething.

Nous avons complètement réécrit les widgets à la base des outils RecentMessageList, Finder, Senders et Implementors.
Meilleur encodage des branches Monticello.
Meilleur menu contextuel du debugger.
Grand nombre de petites corrections.
Nouveau time profiler.
Suppression de beaucoup de code mort dans la hiérarchie StringHolder.
Meilleure prise en charge des messages différés de l'UI.
Amélioration de la vitesse du navigateur d'aide de 50%.
Après une longue discussion débutée à la conférence ESUG l'an passé, nous avons commencé à supprimer les dépendances à ToolBuilder. ToolBuilder était une bonne idée: un ensemble d'objets spécifiants des widgets abstraits communs à tous les frameworks. Certains outils les utilisaient. Il était potentiellement bon de porter un nombre donné d'outils à de nouveaux frameworks graphiques. Le problème est qu'il n'y a pas de nouveau framework à l'horizon et que les outils par défaut ne pouvaient bénéficier des avantages de Polymorph. Comme nous voulons obtenir des widgets puissants et que ToolBuilder ne comble pas nos besoins courants, nous allons le supprimer. Si des besoins arrivent, nous pourrons le réimplémenter.

Nouvelles bibliothèques et améliorations

Meilleur support et robustesse de l'infrastructure Announcements. Les problèmes rencontrés étaient de savoir comment s'assurer qu'un code solide et testé puisse être exécuté lorsque parfois du code utilisateur casse la boucle système. Les exemples typiques incluent les annonces, gestion d'évènements ou les threads de rendu. Nous avons introduit la méthode on:fork qui, sur une erreur, manipule la pile et crée un fork de la partie du processus contenant l'erreur. Cela permet en particulier de laisser continuer l'exécution de la partie non cassée du comportement. Cette modification amènera une stablité et robustesse à des endroits clés du système. La logique du thread de l'interface utilisateur sera réécrit pour bénéficier de ces avantages.
Weak Announcements

Le système d'annonces est important et nous avons amélioré la première implémentation naïve. Nous avons d'abord ajouté le support des Weak Announcements pour ensuite amener les avantages de l'introduction de on:fork. Cela permet de s'assurer que toutes les annonces seront bien livrées.

Ajout de WeakOrderedCollection nécessaire à Magma (base de données objet).
Ajout de Generator.
Ajout de Stratified Proxy. Souvent, lorsque vous construisez un proxy, vous ne pouvez pas contrôler tous les messages envoyés au proxy car l'implémentation s'appui sur DoesNotUnderstand et ProtoObject. Nous avons conçu une nouvelle version qui ne souffre pas des limitations des hooks de la VM.
Suppression de l'ancien framework d'annulation (UnDo). Nous l'avons remplacé par un nouveau qui marche vraiment bien. Merci à Alain Plantec.
Un Set peut maintenant contenir nil.
Nombreux ajouts d'exceptions explicites les erreurs sur les Collections (à la place de simples appels à error:)
Amélioration de Smalltalk cleanUp, utilisé par cleanUpForRelease.
Amélioration plus poussée de SystemNavigation pour travailler avec les environnements.
Plus de commentaires de classes. Grâce à la merveilleuse idée de Laurent Laffont (Comment Of The Day Contest) nous avons commencé à commenter systématiquement les classes non commentés.

Ancien compilateur

Pendant que nous continuons notre travail sur OPAL, en particulier son décompilateur et plusieurs points entre les couches, nous avons intégrés plusieur améliorations de l'ancien compilateur.

Synchronisation avec la branche principal du code du compilateur de Squeak
#whileTrue: maintenant "inliné"
Nettoyage de l'utilisation de FakePool
Les anciennes expérimentations de positionnement ont été supprimées
ifNotNil:, ifTrue: et compagnie sont maintenant ajouté au tableau de litéraux et sont donc trouvés lorsqu'on cherche "senders of"

Réseau

Certaines primitives n'étaient pas utilisées. Maintenant elles le sont.
Nous utilisons maintenant l'excellente bibliothèque Zinc pour les parties client et serveur HTTP lors du chargement des paquets.

Divers

Meilleure API pour systemVersion
Amélioration du support des mails
Meilleure gestion des fins de ligne et du presse-papier sous Linux
Correction du plugin de communication série
Nous avons commencé à nous assurer que l'on peut "boostrapper" le système. Certains points et hypothèses ont été identifiées et corrigées
Nous avons corrigés toutes les utilisations de == pour les nombres, car == n'est pas un test d'égalité numérique
Ajout du support des VM multi-threadées dans Process
Nettoyage des tests pour les rendre utilisables dans un contexte d'intégration continue

Nettoyage

Le système contient encore beaucoup de code mort. Nous avons continué le nettoyage de ce code en combinant deux stratégies. D'un côté nous déprécions le code (déplacement des classes / méthodes dans le packet Deprecated13). Cela permet aux clients de continuer à utiliser ce code et de migrer en douceur. La seconde stratégie est la suppression pur et simple :)

Nettoyage de ChangeSet, ChangeSorter et compagnie.
Suppression d'ExternalSettings, un système de préférences inutilisé qui permettait de les sauvegarder dans un fichier
Dépréciation de PCXReadWriter car ce format n'est plus vraiment utilisé de nos jours.
Suppression des dernières traces de MVC. La suppression de MVC nous a permis de démarrer un nettoyage majeur du modèle de Text. Paragraph a été remplacé par MultiNewParagraph, suppression d'un grosse quantité de code des classes Canvas et Text.
Nettoyage des réminiscences d'Etoys
Uniclasses, qui comlexifiaient considérablement le système.
Imports, Tiles et code inutilisé.
Le code dupliqué qui gérait l'encodage des variables temporaires dans les instances de CompiledMethod a été supprimé. Ceci simplifie considérablement le code, le rendant plus clair pour nettoyages suivants.
La sauvegarde de l'image contenue dans l'exécutable de la VM a été supprimée. Ceci simplifie le processus de sauvegarde.
Nettoyage du code qui gère le curseur.
Le code déprécié dans cette version (Deprecated13) contient 26 classes, 786 méthodes et plus de 5000 lignes de code.

Sécurité

Nous avons supprimé le gestionnaire de sécurité précédent car il n'était pas utilisé. De meilleures solutions seront ajoutées plus tard.
Pour commencer, nous avons introduit une nouvelle méthode pour gérer les plug-in qui améliore la sécurité et la flexibilité. Voici 2 primitives qui ont été ajoutée à la VM : SmalltalkImage>>loadModule: charge un module avec un certain nom et échoue si le module ne peut pas être trouvé, ne peut pas être chargé ou ne peut pas être initialisé. SmalltalkImage>>disableModuleLoading désactive le mécanisme de chargement de modules pour le reste de la session. Cette opération n'est pas réversible : toute tentative ultérieure échouera.

Wiki