Separate MPS caches for different MPS distributions based on the same MPS major version

Between MPS major versions, the MPS global caches are nicely separated (e.g. for MPS 2017.1, the cache directory is $HOME/.MPS2017.1 and for MPS 2017.2, the cache directory is $HOME/.MPS2017.2, where $HOME is your home directory, e.g. C:\Users\<yourusername> on Windows or /home/<yourusername> on Linux). Sometimes, there are reasons why you would want to change the cache for a specific MPS distribution on your filesystem. Some of these reasons are:

  • Run different distributions or RCPs of MPS that have the same major version at the same time on your machine
  • Separate two MPS global caches (e.g. a cache for production in some project you work on and another cache for a course you have to give tomorrow), so they don’t interfere with each other.
  • Be able to open two modules (language or solution) with the same name/ID, without the two getting intermixed in the global cache (or MPS thinking that one has already been loaded, making the other read-only).

By default, the MPS cache-directory for an MPS major version called <version> (located under your $HOME directory) is .MPS<version>, e.g.: .MPS2017.2.

You can change this default location by adding a line like this in your vmoptions (for Windows, it’s located under your <mps installdir>\bin\mps64.exe.vmoptions):

-Didea.paths.selector=MPS34-MYOWNTHING

This would lead to the MPS that you run from <mps installdir> to maintain a cache directory called .MPS-MYOWNTHING in your $HOME directory.

 

How I make an open source mbeddr developer release

The mbeddr RCP is great, because it gives you a focused MPS-based IDE, including mbeddr.platform, which you can use to write models in the embedded software domain.

However, I find it often useful to have the mbeddr.platform plugins (which are generic pieces of functionality useful for any DSL development) available for development as a language engineer, not as someone who wants to write mbeddr models.

If you want the full-blown mbeddr development environment (which requires you to do a build of the entire mbeddr.platform and mbeddr DSL stack), just follow the mbeddr build environment setup howto.

However, I often have the use case where I just quickly want to setup an MPS distribution (e.g. for student courses or student projects) with the mbeddr DSLs included. In this case I just perform an easy procedure:

  • Look on the mbeddr.core github releases page for the latest nightly build
  • Determine which MPS major and minor versions are used by the latest nightly build:
    • For a specific release on the releases page, download the source code (e.g. zip file)
    • Look in the upper subdirectory of the zip for the file called build.gradle. There is a line in this file that starts with ext.mpsBuild =, e.g.: ext.mpsBuild = “2017.3.4”. The version number is the specific MPS build that this mbeddr nightly is using.
    • In the same build.gradle file, there is a line that starts with ext.mpsMajor =, e.g. ext.mpsMajor = “2017.3”. This is the MPS major version used.
  • Download the unified package (zip-file) of the MPS version you found in build.gradle. Currently the MPS download links are nicely formatted like this: https://download.jetbrains.com/mps/<mpsMajor>/MPS-<mpsBuild>.zip.
    So, e.g. for MPS 2017.3.4 you can manually construct the download URL (which will be https://download.jetbrains.com/mps/2017.3/MPS-2017.3.4.zip) and then use your favorite download tool (e.g. wget or your browser) to download it.
  • From the mbeddr releases page, download, depending on what you need:
    • com.mbeddr.allInOne.zip (full mbeddr distribution including mbeddr.platform and embedded development DSLs)
    • platform-distribution.zip (mbeddr.platform only).
  • Unzip the MPS zip (extract here, this will create a subfolder called MPS <mpsMajor>, e.g. MPS 2017.3) and then unzip the chosen mbeddr zip (either com.mbeddr.allInOne.zip or platform-distribution.zip) into the MPS folder (which places all the mbeddr plugins into the plugins subdirectory of your MPS folder).
  • Inside your MPS folder, copy all the files from bin/<platform> (where <platform> is the platform you work on: win, Linux, or mac) one directory up (so the executables for your platform end up in the bin directory).
  • Either set a command line variable called MPS_JDK which points to your Java JDK installation, or edit your relevant launcher file (e.g. for Windows this is bin/mps.bat) and locate the line where JDK= is set and put your JDK path there).

Additional info on 25 July 2018: JetBrains nowadays uses a self-maintained JDK for MPS. So far I haven’t been able to find it on the JetBrains site, but Itemis provides downloads of these JDKs for all three platforms (Linux, Windows, Mac) at https://projects.itemis.de/nexus/, e.g.:
https://projects.itemis.de/nexus/service/local/repositories/mbeddr/content/com/jetbrains/jdk/jdk/8u152b851.2/jdk-8u152b851.2-windows_x64.tgz
https://projects.itemis.de/nexus/service/local/repositories/mbeddr/content/com/jetbrains/jdk/jdk/8u152b851.2/jdk-8u152b851.2-linux_x64.tgz

Additional info on 29 July 2018: Instead of unzipping mbeddr plugins into MPS, you can also just install a native version of MPS (using setup.exe or the Linux or Mac installation package) and then use global libraries to point to the mbeddr plugins:

How to add default to a property in a concept

This post assumes that you have an MPS with mbeddr preloaded.

Go to the constraints aspect for the concept you want to add a default to a property:

hdp-01

Create a new constraint for this concept:

hdp-02

Press Ctrl+L and import the language com.mbeddr.mpsutil.propertydefault:

hdp-03

hdp-04

Go to the property constraints and press Enter to make a new one:

hdp-05

Choose the property to which you want to apply a default value:

hdp-06

Select the entire constraint by pressing ctrl + uparrow twice:

hdp-07

Press Ctrl + Space and choose default to convert the constraint to a default specification:

hdp-08

Choose your default value:

hdp-09

If you now make an instance of MyConcept, you will automatically get the myProperty filled in with the default value:

hdp-10

 

Welcome to DSLFoundry!

Here we create and collect tools and libraries for Domain Specific Languages (also see about). You can see these on our projects page.

In addition, we will post some handy tips about DSL tools now and then in the posts further down this blog.

Please feel free to reuse our code and if you find bugs, please let us know via one of the github issue trackers. And of course you are welcome to contribute if you have any additions or enhancements.