Child pages
  • What's new in MPS 2018.3 (draft)
Skip to end of metadata
Go to start of metadata

EAP1 (was published on 11.09.18)

Behavior methods overridden/implemented icons

Behavior methods have been equipped with the icons similar to the BaseLanguage java methods.

Accordingly one can click on the icon and navigate to one of the overridden/implemented methods if needed.

Build language BuildMpsLayout_TestModules construction

The test modules run configuration construction in the build language has been extended with a possibility to specify additional idea plugins which ought to be loaded on the MPS ant test execution.

The plugins required for the MPS ant test execution used to be calculated automatically, although it appeared that there are scenarios when the test needs a particular plugin in its environment, which could not be deduced from the modules containing the tests by the MPS build language engine.

Now one is able to ensure that the plugin he needs is present during the MPS ant test execution.

Generator language 

$INCLUDE$ macro has been deprecated and there's a migration to replace its instances with $CALL$. Former didn't support templates with arguments and there's no reason to keep two mechanism to invoke a template.

$WEAVE$ macro and weaving rules can invoke templates with arguments now

When interpreted template weaves an external template from 'compiled' generator, it is no longer interpreted but compiled template code is executed.

'Compiled' templates may weave interpreted templates now

QueriesGenerated, collection of queries from a template model, no longer uses Java reflection (in fact, this is the change I forgot to mention in 2018.2. Though this one is not high importance to end-user unless he looks into source code or digs through exception stacktraces, it's a notable change in the way generator had worked for years)

EAP2 (was published on 18.09.18)

Reusable cell action maps

Cell action map items from an existing action map can be reused in a new action map via imports.

EAP3 (was published on 26.09.18)

EAP4 (was published on 02.10.18)

EAP5 (was published on 08.10.18)

EAP6 (was published on 17.10.18)

Support Touch Bar for Mac Book

Initial support:

  • MPS actions are now avaliable in Touch Bar
  • List of actions depends on context and used modification key
  • Custom user actions and action groups can be added to Touch Bar by adding to one of predefined InterfaceGroups
    • IDEATouchBarDefault
    • IDEATouchBarDefault_alt
    • IDEATouchBarDefault_cmd
    • IDEATouchBarDefault_cmd_alt
    • IDEATouchBarDefault_shift
    • IDEATouchBarDebug

Idea announce can be used as template: https://blog.jetbrains.com/idea/2018/05/intellij-idea-2018-2-early-access-program-is-open/

Can be added to help: https://www.jetbrains.com/help/idea/touch-bar-support.html

Hight Contrast Theme

MPS-28772 Enable High Contrast theme in MPS
Support new feature from Idea in MPS https://blog.jetbrains.com/idea/2018/10/intellij-idea-2018-3-eap-high-contrast-theme-and-more-accessibility-improvements/

EAP7 (was published on 26.10.18)

Conflict resolving in merge dialog for children in multiple role changed

Before it was not possible to apply changes from both sides (local and remote): applying from one side just rejects change from the other side. For children in multiple role it is not convenient if both changes are applicable.

Now after applying changes from one side of the conflict the other conflicting changes are converted to the addition into the end of the changed group and it is necessary to apply or ignore them separately.

For example:

After applying left version of the conflict you still can apply or ignore the line from the right side:

Fixed and improved actions for working with deprecated code

Find Usages of Deprecated can find all usages of deprecated elements. Now, the report of the found usages groups the entries by the expected version of code removal, so it's easier to recognise their severity and prioritise their elimination. In addition, we've reviewed our own deprecations in MPS code and added some additional migrations to help you minimise the amount of deprecated code in projects using MPS.

Custom packages for BaseLanguage Classes

For a long time, the only way to control Java packages of generated classes was name of a containing model:

Here, we've got 3 BaseLanguage roots in a jetbrains.mps.samples.files.blpack model. Generated code used to end up in a package with the same name.

However, with a new Classifier property 'packageName', it's possible to control Java package of a generated class. The property is available for root classifiers:

ClassConcept:

Interface:

EnumClass:

 

Generated code for the model now uses the property:

with files arranged properly:

Tips & Tricks

Now default Tips & Tricks for MPS can be customized.

This can be done with build script new tips & tricks concept:

Tips can be reused from MPS general distribution, imported from directory or from solution:

  • First option just add all MPS tips to final distribution. This is default option for build script generated with wizard.
  • Second one required manually created folder with correct structure of tips that can be obtained from mps-tips.jar itself. You need folder that contains html files, css and images folders.
  • Last option allows to use jetbrains.mps.build.tips and jetbrains.mps.core.xml languages to quickly create basic tips in MPS itself.

Finaly tips must be packaged into build script layout to the lib folder. In build script generated with wizard MPS tips & tricks are packaged to lib folder by default:

Tips & Tricks language

To import tips & tricks from solution, create solution with model and add languages jetbrains.mps.build.tips and jetbrains.mps.core.xml to model used languages.

Then you can create instance of MPSTipsAndTricks concept, where multiple tips can be created.

Each tip is HTML formated text. One image can be added to each tip:

Importing from solution to build script tips & tricks by pointing to solution and generated xml from MPSTipsAndTricks concept:

Fully compiled datatypes

Moving forward to fully compiled languages we've made datatypes to be completely generated. All generated information regarding datatypes is now available from SModel API.

New generation facilities for BaseLanguage extensions

BaseLanguage is intended to be customized with lots of extensions. However, for some extensions, it is tricky to implement proper generator especially when you have to consider that there are some other independent extensions can be instantiated in a model. Now BaseLanguage provides new several generation-time concepts to make writing extensions' generators easier for some cases.

Generating of lvalue-expressions. Lvalue expressions are such expressions that are evaluated to variables which can be read or written with some value. For some cases generation of lvalue-expression become hard since it might depend on in what context the expression is used. Now new `generic lvalue-expression` generation-time concept can be utilized to make a generator simpler and context-unaware.

Transform lvalues to references. Some expressions aggregate other lvalue-expressions to make compound operations with a variable that is produced from aggregated expression (e.g. plus assignment or increment and get expressions). Introducing new expressions with such semantics had been unfeasible since it is hard to write a proper generator for such constructions. Fortunately, in new release you can wrap arbitrary lvalue-expression with `@byRef` expression so then baseLanguage generator will transform wrapped expression into expression of type `Reference<T>` that provides get and set operations over a wrapped variable.

Both introduced generation-time concepts have described in this article.

Default methods support in BaseLanguage

In the new version MPS allows to create the 'default' methods in BaseLanguage interfaces.

The 'default' keyword is implemented by the DefaultModifier concept which extends the Modifier concept in the BaseLanguage. DefaultModifier is located in the jetbrains.mps.baseLanguage.jdk8 language, which means that in order to create a 'default' method in the interface, one needs to import the jdk8 language.

The transformation/substitute menu + some cosy intentions are also supplied.

Concept overridden/implemented icons

MPS marks concepts with an overridden/implemented icons, allowing user to navigate to the superconcept or subconcept of the current concept.

Overridden/implemented icons further enhancements

The popups with the overridden/implemented concepts/classses/methods became asynchronous, which means that MPS fills the popup with the search results in background. During this activity one might navigate to some occurrence which has been already located by the MPS search engine.

Also the filtering by the name of search objects is available now.

Finder changes

Also the finders distributed by MPS got updated and optimized.

Furthermore, in order to execute a finder asynchronously one needs to use a special OnEachNodeFoundByExpression, which represents a simple finder invocation with a callback which is executed for each found node.

Consequently the find usages options for a concept have been changed.

The options have been extended with Derived Concepts and Concept Ancestors, which yield the list of subconcepts and superconcepts, respectively.

Also the find usages options for the behavior methods have been extended with "Overridden Methods" and "Overriding Methods".

Suppressing specific errors

Error suppressing used to be a rough tool to prevent MPS from showing error improperly found by typesystem checker. If a node was annotated with attribute 'SuppressErrorAnnotation' using intention 'Suppress error for node ...', no error message was shown for that node and all of its descendants. Now there is a possibility to suppress only specific error messages.

The selected error message will be suppressed for the node and all its descendants while other messages remain present. For more information see the documentation page.

 

Saving migration data as annotations

Migration scripts communicate with each other using migration data, special fragments of AST which are produced by some migration script and consumed by another one. In previous MPS versions, these data fragments were stored in special files laying somewhere nearby the module descriptor. This approach had the main disadvantage that such files with migration data cannot be merged easily if modified in two branches simultaneously. Now MPS supports another mechanism of transferring migration data which is highly recommended for newly created migrations. Produced node containing data should be now attached to any node that is close enough to the place to which the data is related. If there is no specific place to put annotation because it is related to the whole model, data node will be attached as a new root in current model.

Migration script producing nodes with data should declare the concept of such nodes and use putData() construction to insert each of such annotations into the model:


Retrieving nodes containing data performs quite the similar way as it used to be:

BuildMps_IdeaPlugin packaging option

The custom packaging option in the BuildMps_IdeaPlugin (the idea plugin declaration) got deprecated and should not be used from now on.

Instead one has to choose now the possible layout packaging right in the layout BuildMpsLayout_Plugin construction.

There are two possible options for now. One is auto packaging, that behavior corresponds to the absent "custom packaging" flag in the 2018.2 version, meaning

that all the provided languages and solutions are put into the 'languages' folder under the plugin root directory.

The second corresponds to the present 'custom packaging' options at all of the items listed in the BuildMps_IdeaPlugin declaration in MPS 2018.2.

It implies that the developer has to provide the whole plugin layout on his own.

 

  • No labels