Child pages
  • What's new in MPS 2.5 M1

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0
Table of Contents


Section 1 - IntelliJ IDEA integration

Include Page
MPS plugin for IntelliJ IDEA
MPS

...

plugin for IntelliJ IDEA

...

There are several aspects of integrating MPS into IntelliJ IDEA:

  • MPS Facet + settings (model roots/used languages/output path/...)
  • Explore .mps files in IDEA project view -> double-click on root to open editor
  • Change model properties (imported models/used languages) by calling popup menu on model file
  • Generating code by making the project
    1. navigate to errors in DSL code reported by generator (make)
    2. see http://confluence.jetbrains.net/display/MPSInt/MPS+Make+In+IDEA
    3. two modes of generating files: to different source root or to the same folder next to .mps file
    4. hiding generated code
  • Debugger in IDEA plugin: put a breakpoint into DSL code, run java application and stop on this breakpoint & explore stack trace
  • VCS integration
  • Actions available in the IDEA plugin
    1. Navigate to model/module/root (Alt+F1) is similar to MPS
    2. create complete list?
  • Two aspects of working with MPS plugins for IDEA:
    1. deploying your own languages
    2. using one of languages distributed with MPS
  • MPS plugin distribution description (plugins + possibility to switch then on/off)
    1. mps-core
    2. mps-java
    3. mps-vcs

Dependencies analyzer

The Dependencies Analyzer can report dependencies among modules or models. It can be called from the main menu or from the popup menu of modules/models:

Image Removed   Image Removed        Image Removed

The interactive report, shown in a panel at the bottom, allows the user to view usages of modules by other modules. The panel on the right side displays modules and models dependent on the module selected in the left-hand side list.

Image Removed

Module Dependencies Tool

With this tool it is possible to overview all the module (or set of modules) dependencies and used languages, detect cyclic dependencies as well as see in details paths that lead to the given dependency. The tool can be invoked from the project pane when one or more modules selected there.

Image Removed
Module Dependency Tool shows in the left panel all transitive dependencies of module and optionally all used (directly or indirectly) languages. It is possible to expand any dependency node and get all dependencies of the expanded node as children. These will be again transitive dependency but for the expanded node.

Select one of dependency nodes or set of nodes in the left panel. Right panel shows paths to the each selected module from its "parent" module. You can see brief explanation of each relation between modules in the right tree. It can be depends on, uses language, exports runtime, uses devkit, etc. For convinience the name of the target dependent module is shown in bold.

Image Removed

There are two types of dependency paths: Dependency and Used Language. When you select module in the Used Language folder in the left tree right tree shows only dependency paths making "used language" relation for the given module. To show "ordinary" dependencies on language as a module you should choose it out of Used Languages folder (like jetbrains.mps.lang.core in the picture below). It is possible to select several nodes (e.g. the same language dependency inside and outside Used Language folder), then you get union of paths.

Image Removed

If you want to track not only "visible" but also runtime dependencies you should check "runtime" option in toolbar. Only runtime dependencies are marked with "(runtime)" comment in the left tree.

Image Removed

By default dependency paths are shown in "from the shortest to longest" order. But there are still paths that are not shown: paths with the same tail part as one of the already shown path. It is still possible to see all such paths in the right tree with the "Show all paths" option. Only starting (distinct) part of path is shown, symbols "... -->" mean that there is continueation of the path already shown in the tree; you can follow path by double clicking its last element. Image Removed
Modules participating in dependency cycles are shown in red color in the left tree. It is possible to see paths in cycle by selecting module dependency equal to parent or for convinience by using popup menu:  Image Removed

Image Removed

For some types of dependencies it is possible to show usages or safe delete with popup menu. For "depends on" (dependency without re-export) Dependencies Analyzer will be invoked on Show Usages.
Image Removed

Changes in Refactoring language

UI for getting refactoring parameters now is removed from refactoring language. Now choosers for parameters are not called, it is not allowed to show UI in init (e.g. ask and ask boolean), keystroke has no effect. All this functionality should be moved to an action correspondent to the refactoring.

The following constructs added to the refactoring language:

  • is applicable refactoring<Refactoring>(target)
    returns true if refactoring target corresponds to the current target (type, single/multiple) and applicable as in refactoring isApplicable method, and there is no refactoring that overrides current refactoring for this target.
  • execute refactoring<Refactoring>(target : project, parameters );
    executes refactoring for target with parameters
  • create refcontext<Refactoring>(target : project, parameters )
    create refactoring context for refactoring, target and fill parameters in context, this context then can be used for refactoring execution or for further work with parameters; UI is not shown during this call

It is necessary to manually migrate user refactorings. Migration consists of

  • create action for refactoring
  • copy caption, create context parameters
  • add refactoring keystroke with the newly created action to KeymapChangesDeclaration
  • create ActionGroupDeclaration for refactoring that modifies jetbrains.mps.ide.actions.NodeRefactoring action group at default position
  • add isApplicable clause to the action created; usually it is just is applicable refactoring< >() call
  • add execute clause to the action created; all the parameter preparations that were in init of refactoring should be moved here; at the end it is necessary to execute refacoring with prepared parameters (with execute refactoring< >(); statement)
  • remove all parameter preparation from init of refactoring, they should be ready on entry to init; you can still validate parameters and return false if validation fails

Suppressing errors

It is possible to suppress errors in editor (and in model checker) now.

If node is instance of a concept which implements ISuppressErrors interface, then all errors in this node and it's children won't be shown. For example comments in baseLanguage implement ISupressErrors.

It is also possible to define child roles, where errors should be suppressed, by overriding interface boolean method suppress(node<> child).

Also if node has attribute of concept implementing ISuppressErrors, errors in such node will be suppressed too.

There is default implementation of ISuppressErrors node attribute. It can be applied only to nodes that are instances of ICanSuppressErrors.

Here is an example of using this attribute and corresponding intention:

There is an error in editor:

Image Removed 

BaseLanguage Statement imlpements ICanSuppressErrors, so user can apply highlighted intention here:

Image Removed

Now the error isn't highlighted, but there is a cross icon in the left pane. SuppressErrorsAttribute can be removed either by pressing on that cross or by applying corresponding intention

Image Removed

Extensions support

Extensions provide a possibility to extend certain aspects of a solution or a language, which are not covered by the standard language aspects and the plugin mechanisms.

Support for extensions exists in

  • languages
  • plugin solutions

Quick howto

  1. Create an extension point
  2. Create one or more extensions
  3. Both must be in the plugin model
    1. Each extension must provide a get method, returning an object
    2. Each extension may opt to receive activate/deactivate notifications
    3. An extension may declare fields, just like class

Extension language

The language jetbrains.mps.lang.extension declares concepts necessary for building extensions.

Extension point

ExtensionPoint concept represents an extension point. The extension object type must be specified as a parameter.
Image Removed

Extension

Extension concept is used to create a concrete extension.
Image Removed

Accessing extension point

An extension point can be accessed by reference using extension point expression.
Image Removed

Accessing extension objects

An extension point includes a way to access all objects provided by its extensions.
Image Removed

Note
titleBe Careful

Objects returned by the extensions have transient nature: they may become obsolete as soon as a module reloading event happens. It is not recommended to e.g. cache these objects, instead is it better to get a fresh copy each time.

Java API

...


public interface Extension<T> {

  String getExtensionPointId ();

  T get ();

  void activate ();

  void deactivate ();
}

public class ExtensionPoint<T> {

  public ExtensionPoint (String id, Class<T> type) { ... }

  public Class<T> getType () { ... }

  public Iterable<Extension<T>> getExtensions () { ... }

  public Iterable<T> getObjects () { ... }

  public String getNamespace () { ... }

  public String getId () { ... }

}

Extension points and extensions are managed by the ExtensionRegistry core component.

Saving Transient Models Status In The Status Bar

A button in the status bar allows to enable and disable saving transient models with one click.
Image Removed

If transient nodels saving is enabled, this button shows a notification popup when generation starts.
Image Removed

Popup can be disabled in Settings -> IDE Settings -> Notifications -> Saving Transient Models Is On.

New XML language

Custom persistence for MPS models

Make process improvements

  • Faster ANT generate task; no dependencies on the idea platform

Editor improvements

  • Table selection improvements (check if it was done in 2.5)
  • Table column selection

Generator improvements

  • .hash# files are not generated anymore
  • new generator macros (if any?)

Collections language improvements

  • MutliForEachStatement
  • others?

Build language redesigned

  • ...
  • Cross-project variables support
  • Base-directory management in buildScript
  • Project dependency management

New Scopes

MPS.Classpath was split into: MPS.Core, MPS.Editor, MPS.Platform and MPS.Workbench

Migration

  • Moving code from plug-in aspect to separate solutions
  • Solution types (plug-in/core/editor)

Version control

More reliable merge conflict handling

...

Distribution

  • MPS plugin structure/ability to switch on/of some parts of MPS by disabling plugins.

Section 2 - New Build Language

Build Language

Build Language is an extensible build automation DSL for defining builds in a declarative way. Generated into Ant, it leverages Ant execution power while keeping your sources clean and free from clutter. Organized as a stack of MPS languages with ANT at the bottom, it allows each part of your build procedure to be expressed at a different abstraction level. Building a complex artifact (like an MPS plug-in) could be specified in just one line of code, if you follow the language conventions, but, at the same time, nothing prevents you from diving deeper and customize the details like file management or manifest properties.

Image Added

Modular builds

Build script dependencies allow you to organize your build as a sequence of steps, each of which may potentially run on a different machine. At generation time, a sophisticated resolution mechanism transforms the high-level dependencies into the appropriate ANT tasks. For example, a dependency on a java module is replaced with its compiled jar location. Referring to and depending on the elements packaged inside existing archives will implicitly extracts them without any extra effort on your side.

Image Added

Plug-ins packaging

Distributing languages as plug-ins for either IntelliJ IDEA, MPS or as your own standalone IDE has become an extremely easy task. The functionality has been packaged into an extension to Build Language, which knows how to build MPS modules and supports all kinds of packaging. You can either write the whole script by hand or rely on the Build Solution Wizard, which helps you start with a new script.

Image Added

You can refer to the User Guide and to the Build Language documentation for more details.

Section 3 - Improvements to the out-of-the-box languages

Customizable scopes

An element that contains a reference to some other element typically knows nothing about the scope applicable to the reference. In such cases the best solution for finding applicable elements is to forward the request upwards in the AST. By implementing the ScopeProvider interface you can intercept such requests coming from your descendants and have full control over their scopes. Since BaseLanguage itself now also follows this strategy, you can easily restrict visible elements in embedded statements or expressions.

Image Added

Textual references

The reference representation can now vary depending on the reference location, as it is in many existing textual languages. It allows languages to support the notion of qualified reference when simple name of the target element is not enough. The new API requires developers to provide the referenceText value as a part of the Scope implementation (see jetbrains.mps.scope.Scope). All references in BaseLanguage now support java-style resolving. Also, in case of broken references the referenceText serves as a hint to the developer to fix it easily.

Image Added

Custom persistence for MPS models through stubs

With the improved jetbrains.mps.lang.stubs language, which now supports write as well as read operations, it is now possible to declare a custom stubs model manager that supports model saving functionality. Using this extension point you can teach MPS how to interoperate with any custom persistence syntax. You can load and save your models from and into a format that fits your needs best. Read more at the Stubs and custom persistence page.

Image Added

Suppressing errors

One of very effective ways to maintain high quality of code in MPS is the instant on-the-fly code analysis that highlights errors, warnings or potential problems directly in code. Just like with other code quality reporting tools, it is essential for the user to be able to mark false positives so that they are not reported repeatedly. MPS now provides the language developers with a customizable way to suppress errors in their languages. This functionality was used to implement Suppress Errors intention for BaseLanguage:
One place where this feature is also useful are the generators, since type errors, for example, are sometimes unavoidable in the templates.

Image Added

New XML language

A new language named jetbrains.mps.core.xml was introduced in MPS 2.5. This XML language has been designed in accordance to the XML specification.

Image Added

Anchor
refactorings
refactorings

Changes in the Refactoring language

In order to make the structure of MPS core languages more consistent and clear, the Refactoring language has been changed considerably. Several new and easy-to-use constructs have been added and parts of the functionality was deprecated and moved into the Actions language.

Section 4 - IDE enhancements

Dependencies analyzer

The Dependencies Analyzer can analyze and report dependencies among modules or models. It detects and highlights the elements that your code really refers to.

Image Added

Module Dependencies Tool

The Module Dependencies Tool allows the user to overview all the dependencies and used languages of a module or a set of modules, to detect potential cyclic dependencies as well as to see detailed paths that form the dependencies. The tool can be invoked from the project pane when one or more modules are selected.

Image Added

Save Transient Models indicator

It's not a secret that you can save transient models during code generation for debugging purposes. In MPS 2.5 you can switch now on/off saving of transient models just by clicking onto a button in the status bar:

Image Added

Version control

In MPS 2.0 the Merge Driver has been introduced to resolve merge conflicts inside MPS-specific files. In MPS 2.5 the Merge driver has been modified in order to handle merge conflicts in a more reliable way:

  • Merge driver is now handling .msd/.mpl files in addition to the model files
  • Model files are always kept in a valid state, even during merge conflict resolution
  • Merge dialog would appear each time you try to open a model with conflicts

Image Added

Debugging

Using MPS projectional editing functionality and improved debugger support it is possible to implement cell-based highlighting of DSL code instead of the usual single-line highlighting typical for text-based debuggers:
Image Added

Java Debugger

In addition to changes in the general debugger framework a number of improvements were implemented for Java-specific debugging

  • "Copy value" popup menu action for inspected variables in the variables view
  • Special highligting for incorrectly placed breakpoints
  • Use Alt+F8 to copy selected code from the editor into the Evaluate window
  • High-level (Domain-specific) types and variable names are calculated for variables in the evaluation and watches windows. Low-level (java) types are shown in brackets.
    Image Added

Comfortable way to run MPS from MPS

A Run Configuration, which starts another instance of MPS from MPS, can now automatically open a selected project on start. You can either choose an arbitrary project path or open the current project that is already open in the current MPS instance.
Image Added

Section 5 - Other

New Productivity Guide

Good command of the tools is undoubtedly one of the attributes of an efficient developer. MPS 2.5 can monitor your actions and give you statistics on how frequently you use its most prominent editing and refactoring capabilities. Go to Help | Productivity Guide to see how well you do. Additionally, we've prepared a list of a couple dozen tricks you could learn through the Tip of the Day window to become more fluent with the MPS editor.

Image Added

MPS.Classpath module removed

There are four specific modules used to expose all available Java API of the platform and MPS as JavaStub models:

  • MPS.Core
  • MPS.Editor
  • MPS.Platform
  • MPS.Workbench

These modules were created as a substitution for the MPS.Classpath module that existed in previous versions. In essence, MPS.Classpath has been split into these four modules to isolate the core functionality from any dependencies on UI-/Editor-/Platform- specific APIs.

Distribution

One of the goals for MPS 2.5 release was making our platform modular. By exploring Plugins page in setting dialog it's easy to see increased number of plugin forming MPS 2.5 platform. If some plugins are not necessary for current tasks those plugins can be simply switched of increasing performance of the platform. Same trick can be used to create reduced IDE for some specific DSLs based on MPS.

Image Added

Migration

If you already use MPS in your projects, you may benefit from reading our migration guide with detailed description of the migration process.