I would like to view this page in
MPS 2022.2 inclut des annotations dans la fenêtre Inspector, a renforcé la prise en charge de Kotlin, amélioré l'API SModel et bien plus encore.
Les annotations sont désormais accessibles depuis la fenêtre Inspector et le processus d'annotation est maintenant effectué sur la racine entière. Cette action est accessible en faisant un clic droit sur la bordure gauche de la fenêtre Inspector. L'annotation s'ouvre à la fois dans l'éditeur Inspector et l'éditeur principal.
De nombreux problèmes propres à l'éditeur ont été corrigés pour offrir une meilleure expérience de saisie, tels que :
T.() -> R
qui était précédemment chargé comme (T) -> R
). it
. Receiver.() -> Unit
) utiliseront correctement ce type de récepteur en tant que paramètre implicite this
dans le corps de la lambda. La prise en charge de SModel est désormais disponible dans MPS Kotlin avec le nouveau langage jetbrains.mps.kotlin.smodel. Outre la prise en charge étendue de la compilation, cela permet d'utiliser le code Kotlin dans les modules de langage (tels que les classes auxiliaires, par exemple).
En supplément des types ordinaires (nœuds, concepts, liens et références), cette solution exploite la flexibilité de MPS Kotlin pour introduire les paramètres de type Concept. Les fonctions, les variables et les classes peuvent désormais déclarer et utiliser ces paramètres et les recycler en tant que types internes, ce qui simplifie la saisie et permet d'exploiter les casts intelligents de Kotlin.
La compilation de Kotlin offre davantage de persistance. Dans cet esprit, les classes Kotlin ne sont plus effacées au redémarrage de MPS.
Une nouvelle option a été ajoutée dans les scripts de build pour marquer un module comme devant être compilé par le compilateur Kotlin. Cet indicateur est inséré manuellement et aucune vérification automatique n'est actuellement disponible pour le définir sur « true ». L'indicateur doit être ajouté lorsqu'un module contenant des fichiers Kotlin est sur le point d'être compilé en JVM.
Vous pouvez désormais mettre en forme vos commentaires BaseLanguage avec un style de texte. Les styles gras (Ctrl + B), non italique (Ctrl + I), souligné (Ctrl + U) et gras non italique (Ctrl + B -> Ctrl + I) sont désormais pris en charge dans les commentaires.
Dans BaseLanguage, il est désormais possible d'effectuer des transformations Postfix qui vous permettent de transformer le code en ajoutant du texte à l'expression. Cela permet de faire gagner du temps aux développeurs, car ils n'ont pas à déplacer le caret vers l'avant de l'expression ou à sélectionner l'expression de façon à appliquer une transformation.
Précédemment, MPS découvrait les modèles dès leur enregistrement dans un référentiel. La découverte d'un modèle dans un module de projet ordinaire impliquait précédemment de parcourir le système de fichiers pour identifier les fichiers et leur type, et de lire au minimum les informations d'en-tête relatives au modèle.
Désormais, les modules ne lancent la découverte de modèles que si cela est nécessaire. La nouvelle API SModule (SModule.forEachRegisteredModel()) permet de cibler les modèles déjà connus par un module, sans passer par la découverte ou le chargement de modèles. Si vous utilisez les clients d'API SModel, et notamment les sous-classes SRepositoryContentAdapter, il peut être intéressant d'utiliser la nouvelle API pour bénéficier de l'amélioration.
MPS inclut désormais une API cohérente pour créer des références, ainsi qu'une représentation interne mise à jour de ces références. Ces modifications permettent d'améliorer le système de référence/persistance du modèle, qui est planifié pour les versions ultérieures. Ce changement permet dès à présent de réduire d'environ 5 % le stockage en mémoire de n'importe quel modèle.
La nouvelle version de MPS tient compte des entrées de version jar et permet d'exposer les classes Java ayant une version correspondant à la valeur d'exécution réelle de Java.
Même si MPS et la plateforme IntelliJ utilisaient une version très simplifiée de la bibliothèque Log4j sans problème de sécurité connu, ils utilisent désormais tous les deux le package java.util.logging pour la journalisation. Une couche de compatibilité a été implémentée (sur la base de SLF4J) pour rediriger les requêtes de l'API Log4j vers une implémentation JUL (Java Util Logging).
L'action Debug Log Settings vous permet de configurer les niveaux DEBUG et TRACE pour les catégories. D'autre part, vous disposez à présent du nouveau fichier de configuration bin/log.properties qui utilise le format de configuration JUL reconnu. Contrairement au fichier log.xml des versions précédentes, ce fichier de configuration n'est pas lu par défaut, mais les utilisateurs peuvent demander un accès à cette configuration (ou toute autre configuration externe) via la propriété système idea.log.config.properties.file.
Les scripts de build Ant que MPS génère à partir des déclarations lang.build utilisent des tâches différentes pour générer et compiler des sources (<generate> pour MPS et <javac> pour la version standard d'Ant). Vous disposez à présent de la nouvelle tâche <mps.make> qui correspond au processus Make lancé depuis l'IDE. Il est responsable de la transition complète d'un modèle, jusqu'au niveau du code compilé. La tâche combine à la fois la génération et la compilation du code, ce qui permet de gagner du temps puisque MPS nécessite des classes compilées pour son module de chargement des classes (car les tâches <javac> dupliquent souvent les efforts de compilation déjà réalisés lors de la phase <generate>). Cela rend également les builds de ligne de commande Ant et le processus Make lancé depuis l'IDE bien plus similaires et augmente la fiabilité de votre processus de build.
Les tests de générateur ont été améliorés et incluent des options de correspondance qui permettent d'ignorer l'ordre des nœuds. D'autre part, une nouvelle action permet de réorganiser les racines du modèle, ce qui aide à mettre les modèles de test de référence dans l'état souhaité.
MPS plafonne le temps passé dans la partie de transformation M2T (Modèle vers texte) pour traiter les erreurs potentielles dans les aspects de TextGen. Le plafond était précédemment codé de manière irréversible. Cependant, certains gros modèles atteignaient cette limite, générant une exception indésirable de dépassement du délai. Désormais, l'IDE comporte un paramètre qui permet de contrôler le délai d'expiration. La prise en charge des builds de ligne de commande est prévue pour les versions futures.
MPS enregistrait auparavant les dépendances entre les classes BaseLanguage générées dans le fichier « dependencies ». Le compilateur Java s'appuie sur cela pour déterminer si les classes de compilation dépendantes ont besoin d'être mises à jour. Cependant, suite à la modification du fichier « dependencies » dans la version 2021.2 pour stocker les dépendances à un niveau supérieur, il n'était plus nécessaire de collecter et de stocker les noms de classe par racine. MPS réduit ainsi le temps de TextGen à la fois pour le code BaseLanguage (puisqu'il n'est plus nécessaire de collecter les dépendances individuelles) et pour le processus de compilation Java (puisqu'il n'est plus nécessaire d'analyser les dépendances de fichier individuelles, d'attribuer les dépendances de fichiers aux modules et aux chemins de classe, ni de propager l'état « dirty »).
Le nouveau fichier deps.cp stocke désormais les dépendances par module pour permettre à MPS de déduire le graphe de compilation du module. Ce fichier conserve l'état de la transformation, il est donc « verrouillé » et personnalisé (il ne liste pas les dépendances qui n'ont pas été utilisées dans la transformation), ce qui contraste avec le graphe de dépendances capturé lors de l'exécution, qui est basé sur les dépendances réelles du module.
MPS ne crée plus de solutions d'exécution/de sandbox imbriquées sous un module de langage. Par défaut, ces modules sont apparentés au module de langage. En cas de changement de nom du module de langage « principal », ces modules étaient toujours reconnus comme « apparentés » et renommés en même temps que le module « principal ».
Afin d'améliorer la fonctionnalité de clé d'étiquette composite introduite dans les versions précédentes, MPS prend en charge le stockage des clés composites dans les modèles de point de contrôle.
Pour plus de clarté et de facilité d'utilisation, la barre de progression Cloning repository s'affiche désormais sur l'écran d'accueil et directement dans la liste des projets.
Il est désormais possible de générer rapidement une table des matières dans les fichiers Markdown sur la base des en-têtes de documents.
Il est à présent possible de créer une signature GPG dans un commit. La signature s'affichera dans la section Commit Details de la fenêtre d'outils Git.
Lorsque vous travaillez avec des fichiers Markdown qui contiennent des instructions avec des commandes à exécuter, vous pouvez exécuter ces commandes directement à partir du fichier en utilisant les icônes d'exécution dans la gouttière.
Lors de la publication de chaque nouvelle version majeure, nous préparons des instructions pour la migration à partir de versions plus ancienne de MPS pour s'assurer que tout fonctionne correctement. Veuillez les étudier attentivement.