Editor state is saved into workspace file, including folding state, selected cell and text selection inside the selected cell.
Referent set handlers acted like listeners: a referent was always set and only then they were invoked. Now you are able to specify whether original referent is to be set or not. Use "keeps original reference" clause.
- Ctrl-N is much faster
- Some of project tree operations are slightly faster
- Model loading was optimized
- Faster indices rebuild
- Memory consumption and reallocation optimized
- A couple of memleaks were fixed
- Support for partial model loading (only roots)
- Imported models (import, visible, languageAspect elements) section was simplified
- Direct links to model elements were added
JUnit run configuration was able to execute tests written on unitTest language. Now it also supports tests written on baseLanguage using both JUnit 3 and JUnit 4 technology.
Added "Mute Breakpoints" button which disables all breakpoints for current debugger session.
Annotation is a form of a root editor presentation that shows detailed information for each line of code. In particular, for each line you can see the version from which this line originated, user ID of the person who has committed that line, and the commit date. Shortly, annotated view of a root node helps you find out who did what.
To open it, use context menu of left editor margin.
Once you opened annotation, you can see the following information for each line:
- revision number (e.g., commit hash for git), which contains annotated change;
- date when the annotated change was commited;
- a person who checked in the annotated change;
- revision number whithin annotated root node.
If you hover mouse cursor over annotation line, you can see tooltip with commit description. If you click on it, you will see list of changes for the current commit. Using context menu, you can also view full difference for this commit and copy revision number to clipboard.
This is an experimental feature that we are releasing early in order to let our users see what we're up to for the next major version.
The traditional workflow cycle in MPS has always been like the following: edit – generate – reload classes. The generation phase here understood as "generate Java files and compile", if you're working with the Java as the target language that is. For the next version of MPS we're planning to make this process more transparent and extensible. For that we're introducing the Make Scripting Framework.
The key concept in the make framework is facet. A facet contributes a set of targets, which represent states in the (abstract) make script to be executed. Targets are interlinked with the dependencies such as "before" or "after", organizing themselves into a DAG (direct acyclic graph). The script is constructed at runtime from the facets declared in the languages used in the model being made, and the targets are executed in the natural order, starting with the "earliest" target and proceeding forward to the requested final target, which is usually "make". Facets can be extended by introducing new targets and/or overriding existing targets.
The set of targets in the current implementation (which BTW is only a prototype and is expected to change greatly) is roughly the following:
The set of facets (Generate, TextGen, ...) is defined at the time the make script is constructed and should be controlled by the languages imported into each of the models. For now this set is statically defined to reflect the exact same generation workflow has been used before.
The above mentioned facets and corresponding actions can be found in the language jetbrains.mps.make.facet. The two actions provided – Make and Build – can be used instead of Generate and Regenerate on a single model. They will replace the traditional actions in future releases of MPS.