Itemis artifacts for MPS 2019.3 through MPS 2020.1

A brief update on how the artifacts of mbeddr, mbeddr.platform, and IETS3 have been changed (for the people that have to deal with older MPS models made using one of the mentioned extension packages): up until MPS 2019.2, it was possible to download all artifacts from build.mbeddr.com. Today, I was trying to do this as well, but it seems all the artifacts have been wiped for mentioned MPS versions (maybe some space needed to be made free on build.mbeddr.com, or maybe some internal build process changed). Now you have to actually get the label of a version that has successfully built from build.mbeddr.com (e.g. 2019.3.22698.f4cbbf7 of the mbeddr platform or 2020.1.4698.e240d62 of IETS3.opensource, the latter leading to https://projects.itemis.de/nexus/content/repositories/mbeddr/org/iets3/opensource/2020.1.4698.e240d62/opensource-2020.1.4698.e240d62.zip) and then get the corresponding artifacts from https://projects.itemis.de/nexus/content/repositories/mbeddr. Especially for IETS3 (KernelF), this is really needed.

Note: since MPS 2020.2, it is possible to simply get release artifacts from github (e.g. https://github.com/IETS3/iets3.opensource/releases/download/nightly-2020.2.4726.e49ca16/org.iets3.opensource-with-dependencies-2020.2.4726.e49ca16.zip). And these artifacts even include the dependencies (such as mbeddr platform, which is needed by KernelF/IETS3).

Translating the “Fachlichkeit” term into English

Markus Völter has written a really nice Medium article about making the core of the functionality of a system (he states software system, but I think this can be generalized to system) where the domain is concerned explicit. He calls this embodiment of the accrued expertise of a company (or a person) Fachlichkeit.

Since this is a word that is hard to pronounce, but really important, I have spent some time with Eugen Schindler (@eugenschindler) to find an English term that, in my opinion, does cover the meaning well enough and also enables you to make it into a verb and a verbal noun.

The word is: acumen. Using this word in the context described by Markus, would look like this:

  • Acumen (noun): the ability to make good judgements and take quick decisions
    • A domain expert has domain knowledge and acumen (due to this domain knowledge).
  • Acuate (verb): to make pungent or sharp
    • A domain expert’s knowledge can be acuated (i.e. explain, judge, analyze, decide) into some form (i.e. from writing a document to encoding it into a DSL structure/meta-model) for a purpose (i.e. solving specific problems)
    • Knowledge = WHAT, form = HOW, purpose = WHY, WHO? (i.e. language engineer), …
  • Acuation (noun): the act of sharpening
    • The process of doing so is called acuation.

MPS Extensions available as plugins on JetBrains marketplace

Let me tell you about something awesome that I have been working on with Mike Vlassiev from the JetBrains people (or rather, they have been working on it and I have done testing and provided feedback): the MPS Extensions (https://github.com/JetBrains/MPS-extensions) are now automatically made available on the JetBrains marketplace on every new MPS and MPS Extensions release.

This means that from now on all the MPS (https://www.jetbrains.com/mps/) plugins provided by MPS Extensions (https://jetbrains.github.io/MPS-extensions/extensions/plaintext-gen/) can be simply installed through File –> Settings –> Plugins –> Marketplace.

Why is that cool? Well, the MPS Extensions, which are maintened by the MPS Community and curated by Itemis (https://www.itemis.com/de/), are very useful plugins which make language developers even more productive than an out-of-the-box installed MPS can do.

Some of the most prominent examples in the MPS Extensions are:

  • Diagrammatic, tabular, and math notation for MPS languages (de.itemis.mps.editor.diagram, de.slisson.mps.tables, and de.itemis.mps.editor.math)
  • Incrementally maintained non-editable models from existing models based on model-to-model transformations (de.q60.mps.shadowmodels)
  • Template-based text generation (com.dslfoundry.plaintextgen)
  • … and many more at https://github.com/JetBrains/MPS-extensions!

And now all these goodies have just been made much more accessible to novice users of MPS via the JetBrains marketplace. This also means, that dependencies for plugins are automatically resolved, which is important for MPS Extensions, since the plugins there are built with a high level of re-usability in mind (and hence dependencies over plugins exist).

I think this is a very important step in the direction of getting the results of the community accessible to new users. A next good step will be to make all the MPS Extensions directly available via one meta-package.

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.