Three of our scientific papers have been accepted recently. These papers are centered around the usability improvements in MPS' projectional editor and program analyses:

• Efficient Development of Consistent Projectional Editors using Grammar Cells was accepted for Software Language Engineering, Research Track
• IncA: A DSL for the Definition of Incremental Program Analyses was accepted for Automated Software Engineering, Research Track
• An Extensible Framework for Variable-Precision Data-Flow Analyses in MPS was accepted for Automated Software Engineering, Tools Track.

You can find a small overview over these papers if you head to the Learn section, and you can also download them if you want to dive deeper into the details.

 

 

If you were ever wondering how you could debug the generated sources for your MPS languages and solutions then the following video may be a good starting point. The video shows how IntelliJ can be set up to remotely debug a running MPS, gives pointers on how you can identify parts of your MPS programs in the generated code, and walks you through a concrete debugging scenario for intentions.

Note that the video was recorded while setting up the debugging environment on OSX. On Windows, the MPS installation has separate files (for 32 bit and 64 bit environments) for specifying extra VM arguments. These files can be found under MPS folder / bin / mps.exe.vmoptions and MPS folder / bin / mps64.exe.vmoptions. Simply add the extra VM arguments for the remote port to these files if you are using a Windows OS.

 

 

It has been a little bit more quiet on this channel. This is mainly because we are working on all kinds of customer projects, very interesting DSLs in a wide variety of domains. However, we cannot publicly disclose a lot of things about these projects -- hence the silence.

However, we have recently added a new notation to the mbeddr.platform. It can be used to render tree structures. We have since used it for decision trees and feature models, as the following two screenshots show:

The notation supports arbitrary tree structures, with decorators at the bottom end of connectors and decorators between connectors at their roots (both used in feature models). It also supports collapsing of partial trees, as well as horizontal and vertical orientations. The respective editor cell can be found in the com.mbeddr.mpsutil.treenotation language. A demo is in com.mbeddr.mpsutil.sandboxlang.

 

 

We have built installers for Mac OS X (a DMG file) and for Windows (an interactive installer). They come with MPS itself as well as all necessary plugins. While we have not yet built an "official" release with those, the nightly builds already ship with these installers.

Currently there are still a few limitations. For example, the Mac Installer does not ship with dot and gcc/gdb/make, but you easily install those via brew. The Windows Installer comes with everything, including an msys environment. Both do not yet automatically install the tutorial; but that can be downloaded and unzipped easily.

So: not perfect yet, but significant progress.

 

 

We have been working a lot on usability-related issues recently: we are almost done with installers for the various platforms. More specifically, we have built what we call the interactive editing guide. This is an interactive tutorial that walks you through how to use the mbeddr/MPS editor. Check it out a Youtube.

 

 

As we have mentioned before several times, one important aspect of mbeddr is the support for formal verification, directly integrated with the languages and the IDE. Dan has recently created an introductory screencast. Check it out a Youtube.

 

 

Grammar Cells (com.mbeddr.mpsutil.grammarCells)

MPS projectional editor affords users a lot of flexibility in terms of notational flexibility and language composition. This blog is full of examples of this, so we don't have to provide more examples.

However, this comes at a cost: building editor in MPS that don't just look nice but that also are nicely usable can be challenging. In particular, editor developers have to create so-called actions -- wrappers, side transforms, substitutions, delete actions -- that, for example, allow entering expression tree structures linearly. Enabling the insertion of parentheses in cross-tree locations, or splitting a number literal in two is even more challenging. Implementing all of this correctly can be a challenge, even for practiced users of MPS. More importantly, it is easy to forget some of those actions, which then leads to editors that behave inconsistently: good in some cases, and bad in others. Such inconsistencies are a major source of frustration for new MPS users.

To address this issue, we (mostly Sascha) have built the grammar cells infrastructure. These are new editor cells that have enough semantic richness so that the necessary actions can be generated automatically. To implement a nicely usable expression language, developers do not have to write a single line of action code. Check out this video:

Even though language developers have to invest a little bit of effort into learning how to use these new cells, it is certainly simpler to work with than the actions. In particular, it is easier to get things consistent. Check them out, they are in the master branch.

 

 

Context Actions (com.mbeddr.mpsutil.contextactions)

MPS supports the use of non-textual notations as a consequence of its projectional editor. This means that programs may contain notations that cannot be typed in the same way as they look on the screen. Examples include sum symbols or fraction bars. Currently these are entered using textual aliases such as sum or frac.

However, this is not easily explorable: users cannot easily find out which such "hidden" aliases are available in a given context.

To solve this issue, we have created the context actions. These look like a palette in a graphical editor. Depending on the user's selection (cursor position), the context actions shows what is available for the user to do. Context actions can include

• Code completion menu entries
• Intentions
• Left and Right Transformations
• Refactorings
• Existing UI-actions
• ... as well as arbitrary, directly inserted code.

The context actions language ships with a DSL that supports the convenient deployment of the above mentioned artifacts into the context action palette.

 

 

Custom Project Views (com.mbeddr.mpsutil.projectview)

For many applications (and their end users) the default MPS Project Explorer (aka Logical View) is too complicated -- it shows too much "unnecessary" stuff. Also, depending on the use case and the stakeholder, the structure of the primary navigation device must be different, adapted for the use case or stakeholder.

The platform contains a DSL to describe the structure of arbitrary alternative tree views in the project explorer; MPS already provides a drop down menu to select from various views, and the DSL can contribute additional ones.

The DSL supports the definition of arbitrary structures, labels, icons and actions, and also lets you add additional nodes useful for structuring the tree. As an example, we have built a new (and more flexible) favourites view. Below is a screenshot:

 

 

As you know, we (particularly, itemis France and Stephan Eberle) have been working for a few years on implementing a real-world smart meter with mbeddr. Together with Arie van Deursen we spent the last few months writing a detailed case study paper that evaluates this process as well as the resulting software. The paper has now been accepted for OOPSLA 2015. A preprint of the paper is now available for download..

 

 

If you are reading this, we don't have to explain to you what mbeddr and MPS is, so we can just get down to business: we are growing the team and we are looking for new developers. If you are a great software developer with good communication skills and want to work on exciting technology in a creative and fun team, then send an Email to Bernd. Being a great developer is all that's really required, but of course the following additional skills are very helpful as well:

• Come up with your own ideas to problems and generally be self-motivated
• Explain complex technical issues to colleagues or customers
• Receive, accept and give constructive feedback
• Language Engineering skills with MPS, Xtext or other language workbenches
• Experience with embedded software (even though we also do other projects here, not just mbeddr)

We're looking forward to meeting you!

 

 

Data-flow analysis derives information about the dynamic behavior of a program by only examining the static code. The derived information consists of, for example, (1) the set of uninitialized variables at a given point in the program, (2) the possible targets of a pointer or (3) liveness of assignments to see if the assigned variable is used at a later point in the program. A clever compiler can use this information to produce better code, where better may mean faster, safer, more robust or even more energy efficient.

In mbeddr, the above described analyses are executed immediately on the typed-in code, which helps you to reason about the program code and also to better understand what may be going on during the actual execution. We have implemented these analyses using the powerful data-flow facilities of MPS and tweaked them a little bit with additional language extensions. This blog post aims at giving a glimpse of what these analyzers can do. If you are more interested in the technical details, please refer to this presentation: https://prezi.com/_mtayndadtv_/data-flow-analysis (this was used to guide an in-house session on the topic) or to http://www.itu.dk/people/brabrand/UFPE/Data-Flow-Analysis/static.pdf.

Points-to analysis

The analysis is responsible for computing the set of targets that a given pointer variable can point to. It is often a building block for further analysis and, in mbeddr, we use it in the uninitialized read analyzer to derive more precise results.

Liveness

A variable is said to be live at a given program point, if its value may be read during the remaining execution of the program. The liveness analyzer gives hints about assignments which are useless, because the assigned variable does not appear later on in the right hand side of another assignment. In the example code snippet the last assignment to z is underlined and a warning is given, because (1) at the next iteration of the loop we assign a new value to z before we would use the old value or (2) we exit the loop and z is not used afterwards.

Uninitialized read

An uninitialized variable is a variable which is declared but is not set to a definite known value before it is used. This is a major source of program errors in all programming languages and C is not an exception, in fact, pointers just complicate the problem even further because uninitialized pointer variables just point to some junk in the memory. Dereferencing these memory addresses can cause serious flaws in the program.

mbeddr comes with an analyzer to check for reads from uninitialized variables. According to the classification among data-flow analyzers, the current implementation is a flow-sensitive, path-insensitive and context-insensitive analyzer;

• flow-sensitive: it takes into account the order of the statements in your C function.
• path-insensitive: we do not perform any kind of interpretation on conditional branches, loops, etc so the analyzer doesn't know about this information.
• context-insensitive: all functions are analyzed in separation and we do not follow function calls, nor rely on context information. This is less precise than a context-sensitive analyzer, but it was a design decision to implement it that way, because we execute the analyzer in an interactive fashion after editing the source code. Performing a full context-sensitive analysis would require a longer time and would break the editing flow in the IDE. In order to compensate for the lost precision, we have extended the core C language of mbeddr with annotations on function arguments.

Improving the precision of the analyzer

Two extensions are used to improve the precision of the analyzer and make up for the precision that may be lost due to the context-insensitive nature.
(1) The analyzer uses the results of the points-to analysis to get accurate information about pointer mappings.
(2) The user can annotate the function arguments with the in/out keywords which have the following semantics:
An IN argument must be initialized at the time when the function is called and cannot be modified in a way that has an effect outside of the function. This means that if the argument has a pointer type, it cannot be dereferenced and assigned inside the function.
An OUT argument must be initialized at the time when the function is called and must be modified in a way that has an effect outside of the function. This means that an OUT annotation can only be used for pointer types and the argument must be dereferenced and assigned inside the function body. These semantics are enforced while editing the code and error markers are used on the offending arguments if they do not fulfil them.

Examples

This is the basic example of reading from an uninitialized variable (a). The IDE marks the read as an error.
We create a pointer b, which points to the address of a. Then, we dereference b and assign a value to it. After this point, a can be safely read, its value is initialized. The analyzer relies on the results of the points-to analysis to provide accurate results.
We pass the address of a to the function call2. The argument in call2 is marked as OUT, which means there must be a write to it which is visible to the outside. Doing otherwise would yield an error in the call2 function. In the call1 function we rely on this information and know that after the function call we can use the value of a because it is initialized.

---

The topic of analyzers is a rather new feature in mbeddr so feel free to try it out and play around with it. On the other hand, these analyzers will always compute only an approximation of the program properties. Ultimately, our goal is to rather provide a smaller number of true positive examples for probable bugs, then to underline everything in the source code due to false positives.

 

 

Modern Languages use exceptions for error handling. The big plus of exceptions is that they provide, if you will, a kind of additional return value that is handled differently from the regular return value. In older languages such as C, the return type of a function is often used to return an error code, and if actual data should be returned, it has to be done through an out parameter. This is awkward. C provides another way, of course, with is the errno global variable. A function can set errno and a caller can inspect this variable directly after calling a function. But there is no information in a function's signature which errors it may raise and the IDE cannot force the programmer to write code to handle them. Exceptions (depending on their specific implementation) can provide this feature. A big disadvantage of exceptions, however, is that they require longjumps "up the stack". These are expensive and hance often not used in embedded software.

Based on these constraints we have designed a compromise feature for error handling into C:

• Error types are declared in way similar to constants
• Functions declare the errors they may raise
• Only those declared errors can actually be raised by the implememtation
• The caller is required to handle the error with a try/catch-like syntax

The feature is implemented by transparently adding an out variable to the function, so no long jump is required -- but of course the "exceptions" cannot propagate up the stack and must be handled locally.

Currently this only works for functions, but we plan on adding this to components and interfaces as well. Note that, as usual, this is an independent language extension and can be used optionally. The feature resides in the com.mbeddr.core.util language.

 

 

Did we ever mention recently that MPS is a wonderful language engineering tool? We have recently added the following features to mbeddr C:

• Tasks that contain executable code that is to be scheduled concurrently
• Cyclic tasks that are executed with some specified period and offset
• Blocking tasks that are allowed to block their execution and reschedule themselves
• An event mechanism that can be used to signal between tasks (waiting up blocked tasks)
• Shared variables, plus an 'atomic' statement that provides locks to the shared variables (using global lock ordering to prevent races)
• Data queues for communication between tasks, with nice APIs that provide locks (non-blocking and blocking variants).

We have built the language extensions, the type system, IDE support, generation to a pthreads-based implementation plus tests for the type system and the semantics in 25 person-hours! There are still a few open language design questions that may need revisiting, but that low number is nonetheless a clear testament to the productivity of MPS.

Let us investigate where this productivity comes from. mbeddr already has a language extension for queues. We reused this queue extension when building the concurrent queues used in the concurrency extension. In particular, we designed an 'enqueue' and 'dequeue' statement that takes care of locking the queue itself. To do this, we relied on the 'atomic' statement we built earlier to coordinate access to shared variables. So in building the extension for queue-based communication between tasks, we reused other extensions we built earlier: the queue extension itself plus the atomic statement for coordinating access to shared variables. And of course the stuff runs inside of tasks, reusing the scheduling. Later we built blocking read access to queues: when grabbing an element from the queue, the task blocks until an element is available. To build this, we reused the event mechanism we built earlier.

Here is the kicker: in both cases, the tests worked correctly on the first try! The generators ran through, the code compiled successfully and the tests ran through.

So why is this interesting? We think it is interesting for two reasons. First, we did "test-driven language development". We started with the language syntax (if you will, the API of the to-be-built system). Then we wrote type system tests that asserted the error messages we wanted to get from the IDE. We then implemented the type checks to satisfy these tests. Next we wrote tests for the execution semantics. They failed, because we had no generators yet. We then filled in the generators to generate low-level C code from the new concurrency extensions. So test-driven language development is a reality with MPS.

Second, we stacked higher level extensions on lower-level extensions. This allowed me to reuse the generators for the lower-level extensions, making the generators for my high-level concurrency extensions much simpler (this is the reason that they worked on first try). Stacking abstractions is not a new idea, of course. Computer science is all about that. However, it is remarkable that MPS lets you do this with languages (syntax, type systems, IDE support, and, importantly, generators). And all while keeping the language definitions modular! This is a major ingredient to the productivity afforded by MPS.

If you want to check out the code, go to the mbeddr repository, check out the 'concurrency' branch, open the 'com.mbeddr.ext' project and look at the concurrency folder. It's still a prototype, but you can certainly inspect the stuff we wrote about here. Stay tuned for more news on concurrency support in mbeddr.

 

 

Here is more good news from the usability perspective. We have introduced groups into the intentions menu to clean up the typically long and diverse list of intentions:

The intention declarations get a annotation that specifies the group label they belong to. In the UI the intentions are grouped, using the label. In addition to bringing structure to the intentions menu, the labels are also searchable: if, in the example above, you type "comps", then only those intentions that belong to components are shown in the menu, further reducing clutter.

This feature is part of the platform.

 

 

For a while now, we have been working on trying to simplify the MPS UI (not the languages, but the tool "chrome") for use by end users: our experience has been that end users are intimidated by the large number of "stuff" in the menu and especially the context menus. Removing actions that are perceived as unnecessary by end users goes a long way in making the tool look more friendly.

A new language extension can be used to customize the actions. Every single UI action (main menu, toolbar buttons, context menus for nodes, roots, models and solutions) can be removed. The extension supports the interactive customization through a preference page, the definition of different action profiles that can be changed at runtime as well as the definition of such profiles as part of plugin solutions (so they can be shipped with a set of languages).

We are also working on customizing the New Model, New Solution and New Project dialogs, and we are thinking about how to easily plug in additional or other project structure views. Together with the existing ability to change splash screens and icons, we are positive we'll have a good solution for "RCP-style" MPS variants in the very near future.

 

 

We have worked on the platform and added additional, reusable MPS utilities:

• Targer Chooser: A dialog to choose nodes in a model, typically when trying select a location where to put something in a refactoring or intention
• Selection Intentions: Intentions that can be used with more than one node at a time
• Model Listeners: A listener that reacts to changes (children added or removed) in a model

Check them out on the master branch; they will be in the next platform release as well.

 

 

As you know, the user guide is written and maintained in inside MPS using mbeddr’s documentation language, because this supports close integration with the mbeddr artifacts documented in the user guide. We have since worked on the HTML export, and the user guide is now available online as well.

It still has a few shortcomings including the size of some pictures as well as the layout of some of the embedded sources (because of an MPS bug regarding to-text transformation of collection layouts). On the plus side, you can use the small blue arrows associated with example code to directly select the corresponding node in MPS (MPS has to be running, and the tutorial project must be opened for this to work).

 

 

Some use cases require to share some common API between multiple compilation units. For instance the standard library is one of these. But also if a library needs to delegate some part of its implementation to the user of the library. C does not offer a native way for this. The way it is done usually is that a prototype of a function is defined in a header and this header is shared between the library and the user. In mbeddr only systems interfaces would be used for this. But not all software is written in mbeddr and there are several C libraries out there that use this which we want to be usable with mbeddr.

It was already possible to implement such functions in mbeddr in a way that it works correctly when the binary is linked. To do so the external module that represents the header has to be imported, the function needs to have the ‘prevent namemangling’ set and the name and parameters have to match the function that was implemented. But at this level of integration mbeddr did not know about the fact that this function implements some public interface. Just like in good old plain C.

The mbeddr way

In order to make such an implementation explicit we have added an extension to C. The natural way to this is by adding an annotation to a function. First of all the header file has to be available as a EternalModule in mbeddr. This can be either be done by typing the function signature manually or by the importer that will be released in the near future. After that by pressing alt + enter on a function signature and selecting the “Add Implements External Function” item form the intention menu the editor will allow to specify the function declaration to implement. Then the name, parameters and return type will be synced with the referenced function. The generator will take care of generating the appropriate C code so the linker will pick the implementation done in mbeddr.

This feature is included in the new 1.0 RC1 release.

Here is a little demo of it:

 

 

We are happy to announce the first release candidate of the upcoming mbeddr 1.0 release. This is also the the first mbeddr release for MPS 3.2.

In addition to many bugfixes and improvements this release contains several new features:

• JUNG Graph framework
• Graphical state machines
• Graphical component wiring
• Signed bit types
• Improved string handling
• Explicit implementation of function prototypes from external module (@implements annotation)
• General generator speedup
• C90 compatible code generator support (limited but sufficient for most compilers)
• Lots of new features in the mbeddr platform (Unique Names, rich strings and many more)

MPS 3.2.1 is available from JetBrains

In order to make installing mbeddr on windows easier we are currently working on one click installer for windows. The installer will be ready with the next release candidate.

You can grab the current release candidate from our Github release page here.

 

 

In this blog we have often talked about the fact that many of the things we build for mbeddr are not really specific to C. We have consciously modularized these into a separate thing called the mbeddr.platform. It is available as a separate download. And since today, there is also a separate page for it. As of now it provides a brief overview over the most important MPS extensions available in the platform. There are some more goodies available in the platform, we'll add those over the next days and weeks. And yes, this is not a comprehensive documentation of all these features, it is just an overview: you'll still have to dig around in the mbeddr code base to learn from examples. But now at least you know what to look for. And you can always ask for help.

 

 

A weak aspect of mbeddr has always been the interoperability with existing textual C source. We have made many attempts at parsing C sources and importing them into mbeddr, all with different degrees of success and various different problems.

Out latest, and so far most successful attempt is based on TypeChef by Christian Kästner and friends). Check out this video to get an impression of the current capabilities..

We are still working on importing whole header files (as external modules) and C files. We also have a good handle on the preprocessor (defines, macros, ifdefs), because TypeChef deals with them gracefully.

Stay tuned.

 

 

Wow, long time no blog. Sorry for that. Here's some news:

As an additional means of displaying relationships between nodes (next to PlantUML and the tree views) we have integrated the JUNG framework for graph display. As a language developer, you can implement an interface IJGraphProvider and implement a method that creates the graph:

• Programmable with high-level API
• Specify initial layout
• Configurable node size, color, line style and color, fill color, shape and label
• Configurable edge width, style, color and label
• Configurable tooltip text for nodes and edges
• Extensibility to plug in your own layouters (such as the one from yWorks)

Once you have created a graph, your users have many options to view the graph in an MPS tool window:

• Double-click selects node or edge in editor
• Zoom and Pan
• Tooltips
• Selectable Layouts
• Selection and highlighting of outgoing and incoming nodes and edges
• Filtering based on node and edge type
• Filtering along a continuous axis (for example, time)
• Incremental, node-based collapsing and expansion

The JUNG integration is available as part of mbeddr, but also as part of the mbeddr.platform, so you can use it for your own languages. Check out the Chunk node for an example of how to use it.

A demo video of the viewer can be found here.

 

 

In addition to text and tables, mbeddr now also supports graphical state machines. Here is a screenshot:

As with other graphical editors, the state machine editor is embedded in the C program, and inside the diagram you can use code completion and other IDE features for the embedded textual code. Watch this video to see a demo of graphical state machines in mbeddr.

 

 

Together with Eldar Khalilov and Michal Antkiewicz, we are currently developing an implementation of Clafer in MPS. Clafer uses Phython-style indentation for block (or substructures). The video below demonstrates how to build such languages with MPS.

 

 

We have just published mbeddr 0.9-EAP. This release is based on MPS 3.1.4 / 3.1.5 and comes with some bugfixes for the 0.8.1 release, but as well with some additional features:

• fully updated user guide
• graphical editor for visualizing component wiring
• ability to specify file system locations of gcc, make and gdb
• debugger provides extension points for integrating additional debugger backends

MPS in version 3.1.5 can be downloaded and installed from here:
http://confluence.jetbrains.com/display/MPS/JetBrains+MPS+3.1+Download+Page

You can get the 0.9-EAP Release from our GitHub release page:
https://github.com/mbeddr/mbeddr.core/releases/tag/0.9-EAP

 

 

Together with the MPS team, the mbeddr team (and in particular, Sascha) have been working over the last few months on the ability to use graphical notations as part of MPS languages. While this is still an ongoing effort, it is now mature and complete enough to be used for real. If you have downloaded the recent mbeddr master branch, you will have noticed that, for example, component wiring can now be done graphically. The screenshot below shows a simple example of graphical component wiring:

This screenshot shows a few interesting features: you can embed diagrams anywhere in "text", you can use different shapes (at this point drawn by custom Java code), you can use various line styles, the framework supports ports (i.e., connection endpoints on the boxes), inside boxes you can use arbitrary MPS text (or other) editors, and the system also supports edge and endpoint labels. Port labels are also supported, but they are only shown if the mouse is "in the vicinity" of the port to not clutter the diagram. Below is a second screenshot of a bigger diagram:

This one illustrates that the approach scales to reasonable sizes, shows that zooming is supported and also demonstrates the auto layouting capability. The graphical notation also integrates with things such as tooltips. Below is another example diagram that shows a different language:

The definition of a graphical editor is based on the same "cell" abstraction used in other MPS editors: the language for defining editors contains additional cells that are then rendered as a diagram. Similar to tables, these abstractions for defining graphical editors rely on queries to make sure that the structure of the graphical editor does not have to directly correspond to the structure of the AST (for example, in terms of ownership).

The next steps for the graphical notations include improvements to robustness, and support for hierarchical diagrams. In addition, a shape library and a framework for simplified shape definition is being developed.

JetBrains is also developing a framework for graphical notations in MPS that has a number of different trade-offs. However, we are in the process of agreeing on a common definition language so that the concrete rendering engines can be exchanged with very limited effort.

To experiment with this stuff, make sure you download the mbeddr.platform and/ or check out the sources of mbeddr. The graphical notation itself lives at github.

 

 

As announced earlier, this week was the User Guide week. The whole team worked on the user guide, together. As part of this process, we brought the contents of the user guide in line with the actual system, we've added a bunch of additional chapters, and we have also migrated it to the mbeddr documentation language.

While the documentation language supports generation to HTML and Latex, the new primary target platform is the Presentation Mode: this means, that the User Guide is supposed to be read right inside MPS. The big advantage of this approach is the very tight integration with the code in the Tutorial and other samples. In the future, we'll also add the ability to press F1 in mbeddr code and jump directly to the relevant locations in the User Guide.

To access the user guide, please download our tutorial project from the GitHub release page: . After building all solutions/languages in this project, you can access the user guide by clicking on the mbeddr symbol in the tool bar, or by selecting it from the bottom of the Help menu. For this to work, the mbeddr Tutorial project must be visible. This means that you either open the tutorial as a project, or that the project has to be visible to MPS by adding it via your project or global libraries (settings page).

If you have feedback (beyond typos; we don't have a spellchecker in MPS yet), you can send that to our mailing list. Alternatively you can also clone the repository, fix the problems, and send us a pull request.

 

 

At this year's EclipseCon Europe Tamas Szabo presented a talk about an integration project between MPS (and mbeddr) and the EMF-IncQuery (Eclipse) project. During the summer we had started working on the MPS-IncQuery project which aims to bring IncQuery’s powerful features to the world of the Meta Programming System (MPS). The need for such an integration between the two projects has risen from the context of mbeddr; specifically the graph query engine of IncQuery could come handy for many use-cases in mbeddr.

This includes assessments on requirements documents (the demo was about this use case), computing scoping information in the IDE to figure out what variables/functions are visible at a given point in the C code or to specify constraints. Additionally, projectional editing brings a whole lot of other usages where live maintenance of graphical viewers is important and the response time of the queries is crucial for larger diagrams and models.

The talk was rather technical, due to the complexity of the many involved projects and because we tried to give details on as many of the following challenges as we could:

• Mapping the Xtext language of the EMF-IncQuery project to the MPS world to be able to express the queries right in the workbench.
• In order to use the queries in the languages we needed to implement the code-generators. These generate Java code in the end, but due to MPS' nature the user will never interact with this code. This code will just be used to drive the query engine under the hood.
• Providing a type-safe API with an extension to the Java base language of MPS. Here, new statements have been introduced in MPS’ Java language to access the queries that you have written previously.
• MPS itself has also been extended with the Query Explorer view, which aims to ease the debugging of queries right in the IDE. It works similarly to a database browser with the functionality to automatically refresh the contents of the view when the underlying models are changed.
• Implementing the backend which is responsible for handling the notifications coming from the observed MPS models. Here, we tried to reuse as much as possible from the already existing EMF-IncQuery backend. By the way EMF-IncQuery is moving towards the refactoring that all kinds of model representations could be plugged in by simply rewriting the modeling-paradigm-specific parts of the backend (to handle the notifications, for example).

We also gave a short live demo during the presentation which was centered around the requirements engineering language of mbeddr. This extension is used by many end users of mbeddr to write requirements documents and create various assessments on them. An assessment is simply a query which reports certain program elements and constructs which satisfy given conditions. The following screenshots briefly describe the scenario:

• The requirements document in mbeddr, where you can also see the workpackages with additional properties like responsible company, priority and scope.
  
  
  
  
• The assessment container and the report inside it. The report has the same properties as the workpackages so that the user can specify the conditions and only those workpackages are listed in the result which meet these conditions.
  
  
  
  

Additionally you can see the query that we have written for the assessment. This establishes a connection between the WorkPackagesAssessmentReport and the WorkPackages. We access the interesting properties (company, priority, scope) of these concepts and use check expressions to specify the conditions when a tuple should appear in the match set of the query.

Finally, here you can see parts of the Java code that is used in the language for the assessment. In MPS you can write constraints and behavior methods (basically derived features) for you language in the Java language of MPS. This language has been extended with additional constructs and types (in runtime) to access the matchers for the queries: Here, we create a matcher for our query and the scope of the query is specified as this.model which will evaluate to the model of the given assessment during “runtime”. Runtime is quite interesting here, because everything happens in the same JVM; query development, code generation and reloading of their classes and using the queries for your own instance model. After this we create a partial match where we set the first parameter to be the assessment and then we retrieve all the values for the second parameter which will be the workpackages found in the model.

---

Currently we are at the phase of trying out the possibilities with the project; we have already used it in the assessment language of mbeddr (as shown in the demo). The next step would be to reimplement the scoping computation in mbeddr with graph queries of IncQuery and perform some measurements compared to the old solution. Future work will investigate the usability for the graphical editors (this may also have impact on the commercial projects also). The integration project can be obtained from GitHub, while the modified assessment language and the other IncQuery related codes reside in a separate branch of the mbeddr repository.

This integration project faces a dual-licensing situation, where MPS is licensed under Apache 2.0, while all the other tools (EMF-IncQuery, MPS-IncQuery) are licensed under Eclipse EPL. We are planning to provide automatic builds for the project, these will be available through the mbeddr build infrastructure.

 

 

We created a wiki page describing Dependencies and Classpath in MPS in great detail. If you ever wondered which entries are required into Solution Dependencies or Model Used Languages, this is the place to look at.

The wiki page describes all settings influencing scoping, classpath, and using languages. It points out where to find them and the effects of every setting. It also contains a recipe section containing step-by-step instructions on the required settings for various situations.

Please drop a mail to mbeddr team if you're missing a recipe or spot an error.

 

 

Bastian Gorholt of TU Darmstadt recently finished his Master's Thesis on Parallel Programming for Embedded Software with mbeddr:

Multiprocessing is becoming steadily more important for raising the performance of computers. Par- allel programming is the key to leveraging such increased processing power. However, parallelization impedes the reasoning about side-effects of application code, which may cause data-races and, thus, non- deterministic behavior. Synchronization via locks is one measure to overcome this menace, by serializing conflicting parallel memory accesses. However, it can also impair an application’s run-time significantly. This thesis shows how mbeddr’s first-class language extension support and IDE integration can be used to partially overcome these issues for embedded software. The new language abstraction, ParallelMbeddr, offers convenient-to-use concepts for explicit parallelization. It provides a thread-safe communication approach by using the typesystem to prevent low-level data-races. Furthermore, it uses mbeddr’s com- piler integration to prototypically optimize the generated code in terms of synchronization overhead. The evaluation indicates that these goals are accomplished, although much potential for improvements and enhancements remains.

The thesis is available as a PDF, and the code is available on github. The thesis has been supervised by Sebastian Erdweg and Markus Voelter.

The mbeddr team congratulates Bastian to his successful thesis. Good luck for your future career :-)

 

 

Jan-Philipp "Janosch" Jägers has finished his Bachelor Thesis on schedulability analysis with mbeddr:

Multiple tools are necessary to prove the satisfaction of timing constraints a real-time system has. This thesis addresses the integration and implementation of all components required to perform static schedulability analysis in a single IDE. A domain specific language is defined to provide an abstraction for tasks. With this task language a programmer can define and configure the tasks of his system. The entered information is then used for static schedulability analysis. The usage of the mbeddr project as a basis allows a tight integration of the task language with the mbeddr C programming language and the IDE. An external tool is integrated to get the worst-case execution time of the defined tasks. To validate the results of the worst-case execution time analyzer, a dynamic execution time analysis capability is implemented for mbeddr. The features of the schedulability analyzer are demonstrated by an example compiled for the Atmel AVR 8-bit hardware platform.

The thesis is available as a PDF, and the code is available on github. From the mbeddr side, the thesis has been supervised by Kolja Dummann.

The mbeddr team congratulates Janosch to his successful thesis. Good luck for your future career :-)

 

 

Breadcrumbs are a way to improve the user's awareness where in a (big) file he is currently editing. It is essentially a "horizontal tree" shown at the top of an editor that reflects the hierarchical structure of an editor's contents. Niko has made an MPS extension that displays a breadcrumb in an MPS editor. By clicking on a label the user can jump to the corresponding level of the containment hierarchy. By clicking on the little triangles one can see the remaining nodes in the hierarchy.

To use breadcrumbs in an editor, only two simple steps are required. Nodes that form the hierarchy (and should show up in the breadcrumb) must implement the interface IBreadcrumb. The root of the editor that should show the breadcrumbs must include a breadcrumb editor cell at the top.

The breadcrumbs are available as part of the mbeddr.platform.

 

 

We have long been (made) aware of the fact that the mbeddr user guide is outdated. It was once a really nice document, but then mbeddr evolved, and the user guide didn't. And now it is only marginally useful. We have since started a project to write the user guide in mbeddr's own documentation language, but we have not worked enough on it to bring it to a useful degree of completeness.

To solve this issue, we have decided that the whole team will spend the week of November 3 working on the user guide. In other words, by November 10 the user guide should be back in good shape. So please bare with us until then.

 

 

We have recently blogged about a new paper we wrote on MPS editor usability. We have now supplanted this paper with a video that illustrates all of MPS' efforts to make editing code in the projectional editor as convenient as possible. Check it out, especially if you are skeptical about projectional editing.

 

 

We have just published mbeddr 0.8.1-EAP. This is a bugfix release for the 0.8 release. It fixes two major bugs introduced in 0.8. The first one prevented users from running and debugging out of mbeddr on Windows. The second is a mistaken error message from the type system when using Boolean types. Though this issue is resolved in the most common use cases it might still surface in some corner cases when using number literals with physical units. Since the physical units are getting a major overhaul in the next mbeddr release we decided to not fix this in the current version.

 

 

We have just added a new paper to the Learn page In this paper we provide an overview over the notations supported by JetBrains MPS, including text, prose, math tables and graphics. The various supported notations are illustrated with examples from real-world systems, most of them are taken from mbeddr. The paper includes graphical notations, about which you'll hear much more soon.

 

 

We have just published a bunch of new papers on our Learn page. The first one, Towards Usable Projectional Editors discusses how MPS has improved the usability of the projectional editor over the last few years. The second one, Automated Domain-Specific C Verification with mbeddr is the definitive paper on integrating C-level verification tools into mbeddr in a user-friendly way. Finally, Preliminary Experience of using mbeddr for Developing Embedded Software discusses our experience so far with using mbeddr to develop real systems.

 

 

We have just published mbeddr 0.7-EAP. This is the first release of mbeddr that works with (and requires!) MPS 3.1.

You may wonder about our version numbers, and whether we're ever going to remove the EAP tag and get to a 1.0. Rest assured, we do have such plans. As it looks currently, we'll most likely get to a 1.0 ca. one year from now. This is aligned with out development process of the commercial SIEMENS PLM add on to mbeddr. All of this may change of course, but this is the plan.

 

 

Sascha has added support for tooltips to MPS. The respective languages are part of the mbeddr.platform. Tooltips are defined using the regular MPS projectional editor and hence have all its notational flexibility. Check out the video below:

 

 

On Thursday, June 19 at 14:40 Kolja Dummann will give a talk about mbeddr and how it can be used to create language extensions for hardware features and how to easily interact with protocols like MQTT. If you want to meet him at the conference and talk about the project or MPS you can contact him via Twitter.

 

 

MPS 3.1 will come with a number of enhancements in the editor usability. I will support setting parenthesis at arbitrary locations in expressions, as well as automatic rebinding of broken references. In addition, it is possible to clean up the contents of the project explorer by only showing root nodes. Check out the video below (click on the image, it open in Youtube).

 

 

In order to prove the extensibility of mbeddr, and to support customer interest we have been working for some time on building a C++ support for mbeddr. In September 2013, a Master’s Thesis has been defended by Zaur Molotnikov (advisors: Markus Völter, Daniel Ratiu; supervisor: Bernhard Schätz), which addressed the research question of whether mbeddr’s extensibility can accommodate C++. The goals were to explore mbeddr’s and MPS’s extension points, and to define a restricted version of C++ that improves safety, similar to what mbeddr does with C. The Z++ programming language (aka Projectional C++ or C++ for mbeddr) was born. Back then it was a rather prototypical language, and it was not maintained.

In early 2014, Sioux decided to explore the use of Z++ in an industrial context. Developers at itemis, Sioux, JetBrains and Fortiss worked jointly on the development of Z++. In particular, Zaur has spent the last week at Sioux, working on Z++ with Eugen Schindler, Klemens Schindler and Remi Bosman to migrate it to the newer current versions of MPS/mbeddr and to improve it generally. One of the major issues turned to be GenericDotExpression. Using this concept it is amazingly easy to create notations with dots, such as MyClass.helloWorld(). The only thing the language developer must do is implement the IGenericDotTarget interface to represent the code after the dot! Using the GenericDotExpression in Z++ turned out to reduce the code base significantly.

Z++ template support has always been tricky. We improved it at Sioux, making the overall design cleaner, and reducing the code base. A simple C++ example project was investigated that made use of templates and dynamic polymorphism. By the end of the day, it worked well: it was implemented and compiled by Z++.

In addition, several bugs have been discovered and fixed, including some curious C++ language quirks. Despite the progress, Z++ does not (yet) represent the complete C++, but it can already be useful, for example as a generation target. We encourage you to check it out at https://github.com/qutorial/zplusplus. Sioux, Fortiss, JetBrains and itemis will continue to work on it in the coming months.

To install the latest mbeddr, with which Z++ works, please, follow the instructions on fortiss'es web site.

 

 

In MPS, each language concept has its own editor. While this is useful in 99% of all cases, sometimes it is a problem: imagine you want to change the editor of many different language concepts at a time. Then you have to change the editor for all these language concepts. This is tedious and error prone.

As an example, consider projecting a little arrow over all "things with names" in C that are pointers as a means of highlighting pointers throughout the program. This is shown in the example below.

The problem here is that there are separate language concepts for local variable references, global variable references, argument references, etc. All these have to be changed.

Enter conditional editors. A conditional editor is almost like an aspect. It can be applied "around" existing editor, and whether it applies or not is determined by a condition and the applicable concept (similar to a pointcut in AO). The figure below shows the definition of the pointer arrow editor.

It applies to all language concepts that are references and hence implement the IReference interface. It is conditionally applied only if the type of the reference is a pointer. As the editor itself, it shows the arrow (hiding behind the custom cell on top of the already existing editor ([next-editor]).

Using this approach, it is now possible to essentially decorate any editor with any decoration based on arbitrary conditions. The plugin that enables this behavior can be found at github: https://github.com/slisson/mps-conditional-editor, and it is also part of the mbeddr platform.

 

 

We have updated the mbeddr documentation language (as part of our and Sioux' efforts to improve the user guide!). In particular, we have developed a new Presentation Mode that allows users to conveniently read documentation directly in MPS. We have also built a cool way of incrementally "building" example code as part of documents without having to duplicate the various code snippets. Check out the video below (clicking on the image takes you to Youtube):

 

 

Performance is an important concern in embedded software. As a consequence, it is important to make the developer of the performance implications of the code a developer writes. This is even more important if and when developers use higher-level abstractions to express the system's functionality, as mbeddr recommends.

As part of his Bachelor's thesis, Janosch Jägers is currently building a profiling infrastructure for mbeddr. To profile a module, a developer can attach the Profiling annotation to the module. Running the program, the execution statistics are collected and displayed inline, as the following screenshot shows; the length of the bar shows the relative average timespan used to execute the respective function. Clicking on the bar reveals additional details in the inspector.

While embedding the bars in the code is useful to connect the results to the program, it is also useful for the developer to compare the various execution times. To achieve this, an assessment can be used. The following screenshot shows an example.

In terms of the implementation of the profiling infrastructure, the solution is portable: it uses no compiler-specific features. Since mbeddr generates the low-level C code in any case, the generator can simply be used to inject the profiling code. This generator functionality is of course modular in the sense that it does not invasively change the existing C generators: it is implemented as a model-to-model transformation that runs before the to-text generator.

The next step for the profiling infrastructure is to provide convenient facilities for profiling the language extensions available in mbeddr, and not just functions. Stay tuned.

 

 

Over the last few years, Markus had been working on a PhD thesis with Eelco Visser at the TU Delft. The thesis, called Generic Tools, Specific Languages is about using language workbenches and language engineering to tackle the adaptation of (engineering) tools to specific domains. mbeddr is the the example discussed in the thesis. So in essence, the thesis is more or less an mbeddr book -- at the very least it is the most comprehensive discussion about mbeddr's idea, the implementation and the experiences so far. You can download the PDF version from Markus' website (click on the cover). A printed version will be available in the future.

 

 

So far, MPS has only been able to project nodes at the location where they resided physically on the model. So, while the rendering of nodes could be designed arbitrarily, the structure of the projection itself always had to conform to the structure of the underlying AST. In other words, real views were not supported.

Enter querylist. A querylist is a list whose contents are the result of an arbitrary query over the model. The elements in the list can be editable, there are callbacks for what should happen when things are added or deleted, and it is even possible to define wrapper editors for the result elements or override the result element's editor completely.

We are using this currently in two places. First, we use it to show the signature of inherited operation-like constructs. In this case, the queried elements are rendered in grey, and they are readonly. The following picture shows this.

The second location where we currently make use of this feature is in assessments. So instead of just showing pointers to the result elements in the assessment result, we can now show the actual element inline. If the assessment is used to detect errors, then that error can be fixed directly in the assessment instead of navigating to the respective program location.

The querylist is not yet in MPS, but it is available on the mbeddr.platform.

 

 

This week, most of the mbeddr team (except Dan and Zaur) had been visiting the JetBrains office in Prague to meet with the MPS team members located there, and with a few other MPS developers who flew in from St. Petersburg.

(Left to right: Fedor, Vaclav, Sascha, Artem, Markus, Domenik, Bernd, Kolja, Viktor, Alex, Simon, Michail)

We spent about three days briefing each other about upcoming plans, we discussed bugs and upcoming features, and just generally got to know each other better.

Thank you, MPS Team: it was a nice and productive week, in a very nice office :-)

 

 

Fabien Campagne's book on MPS is now available on Google Play Books. It is a comprehensive introduction to the MPS language workbench. We have used this occasion to link to a few MPS learning resources on our Learn page.

 

 

Tree views are a proven way of showing and navigating structure in IDEs. MPS of course has several of them for various purposes. We have now added a nice tree view that can be used for various tasks. The screenshot below shows a call stack for functions.

Selecting a node in the tree automatically selects the corresponding node in the editor. In addition, tree nodes can contribute user-defined actions that are shown in the context menu. As with visualizations, a node can contribute different categories of tree views. All of this can be defined without dealing with any Swing code. The code below shows the implementation of the callgraph; the framework is part of the platform and can be used for any MPS language.

 

 

Imagine you are working with the mbeddr requirements tracing facility. You add a trace to some program element. The trace points to one or more requirements. While you can see the name of the target requirement in the trace, the requirement's content is not visible, since it resides in the editor for the target requirement. To see it, you have to follow the link to the requirement (Ctrl-Click) and then later go back.

To address this situation (and similar situations like that) we have added the InfoView. A language concept can implement an interface that defines one method that returns a node. If the view is open, that node is shown in this view, as soon as the context element is selected. The requirements tracing example shows the target requirement as soon as the trace is selected.

This view is different to the inspector, since it can show nodes from anywhere in the model. Also, the content remains visible until another node that implements the interface is selected; it does not change for every selection change.

The facility is generic, and has been added to the mbeddr platform as well.

 

 

As part of mbeddr, we are developing a lot of useful utilities around MPS that are not at all specific to mbeddr itself. They just generally make MPS more useful or convenient. While these things have always been modularized in terms of languages, they are available as a separate set of downloadable plugins since the last release. It is called the mbeddr.platform.

The platform includes things useful for the language developer (and hence, invisible to the end user), as well as things that the end user will directly interact with. Here are some examples for the first category:

• Utilities for logging in BaseLanguage
• Utilities for working with intermediate nodes in generators
• A BaseLanguage extension for writing AST interpreters
• A type system trace/profiler
• A number of smaller useful extensions to BaseLanguage incl. a builder expression

The second category, things visible to end users, include:

• Sascha Lisson's tables
• Sascha Lisson's richtext facilities
• The assessment framework for querying and auditing models
• A namespace/module/import/visibility framework based on Chunks
• Utilities for commenting code
• An Outline view of models that pops up when pressing Ctrl-O
• A file/path picker concept
• Utilities for debugging expressions by showing their values inline
• The PlantUML-based visualization plugin
• A model/solution-wide full-text search utility

... and many more smaller utilities. While the documentation could be better (currently, there's none), you can always check out mbeddr and explore the use of these utilities by using Find Instances on the respective constructs and see how they are used. You can also drop us a line.

By the way: some of these extensions are scheduled to become part of MPS itself. As this happens, we'll remove them from the mbeddr.platform.

 

 

As a consequence of the Apple goto fail, everybody seems to feel the need to point out how their particular system would have prevented this problem. So I guess we should do this with mbeddr as well.

One can make out several causes for the problem (in addition to the obvious, which is that somebody made a mistake). So here are some thoughts relative to these causes and mbeddr.

First, there is a mix up between indentation and actual block structure. The goto fail code clearly shows, that the developer intended to make the gotos part of the if. After all both gotos were indented. In mbeddr developers have no control over indentation (as a consequence of MPS' projectional editor). So the second goto would not have been indented, avoiding the visual confusion.

A second reason for the goto fail could be the missing curlies in the body of the if statement. Since the if statement executes conditionally the one statement that follows the if condition, it is good style to use a block statement there (curlies). In mbeddr, the definition of the if statement forces the use of a block statement as the body of an if statement. Thus, an if is ALWAYS followed by curlies. This really does prevent errors like the one that caused goto fail.

Some people argue that the goto statement should not be used in code in the first place (even though the C code in the goto fail example is idiomatic C). In mbeddr, it is trivial to define a modular language extension that contains a constraint that prevents developers from using gotos, if this is so desired.

If no gotos should be used, then some other means of handling errors need to be provided. Obviously, in C++, exceptions could have been used; the fail part is an exception handler. However, exceptions do incur some runtime overhead, they don't work with functions that return an error code, and, of course, they are not available in C. However, in mbeddr, one could simply develop a language extension for the following syntax:

This extension could be translated in the following way:

While the implementation uses the same pattern used by the Apple code, the pattern is automatically generated, and hence users cannot make mistakes for error handling. This is a little bit like exception handling, but it works only locally (it doesn't use longjmp) and it works with existing library functions. And of course this language could easily be extended to where the error handler can get information about the failed call (by passing a step variable to the error handler). One could also easily have several error handlers that each handle a specific (range of) error code(s).

By the way, you can find this language extension in the mbeddr repository now. It took 30 minutes to build :-)

So this is in fact a nice example how, by avoiding unnecessary detail, a language extension can improve the robustness and security (in this case!) of low level code. It simply prevents users from making mistakes in the (unnecessary) details. In addition, the intent of what the users wanted to do is much clearer.

There are many things like that in (embedded) software. The goal of mbeddr is to make it simple to extend C with "little languages" that prevent these problems.

 

 

A while ago, we had submitted a proposal for making mbeddr an Eclipse project. The creation review has now been completed successfully, and the first version of the project page is now online.

So, why do we want to become an Eclipse project even though mbeddr is not based on Eclipse technologies (but instead on JetBrains MPS)? The main reason is that we can apply the Eclipse governance process to mbeddr. This is very useful for companies who want to use mbeddr for real world applications. Two advantages are particularly important. The first one is the IP review (which we still have to complete), which indicates to prospective users that the code does not infringe on patents. Second, Eclipse defines a process how new people can become committers and hence contribute to, and influence the direction of mbeddr.

Another reason for joining Eclipse is that it's a nice community, in which many of the mbeddr team members have been active for a long time. We are looking forward to it :-)

 

 

This release uses MPS 3.0.3 and contains a number of refactorings performed early 2014, such as Chunks and the dot expression refactoring. This is also the first release that contains the mbeddr platform, a set of reusable utilities for MPS that are not mbeddr-specific. Unfortunately the user guide is still not yet updated (but will be soon). This is also likely the last release on the MPS 3.0.x train, since we are now switching the master branch over to the EAP of MPS 3.1.

 

 

mbeddr will be featured as part of the itemis booth at the Embedded Software Engineering Kongress in December in Sindelfingen. As part of the preparation, we have created a new two-page Flyer. It provides a brief overview over mbeddr.

 

 

This post is a bit funny. Because if you read it, you wouldn't have to read it, because you already know what it says. And if you don't read it, you probably should. Anyway :-)

We have new website. It is built on top of Twitter Bootstrap (like any modern website, it seems). We have actually copied the structure/code from the Xtext website (with their permission; Thanks!), so it was easy to build even though no one in the team actually knows anything about Bootstrap :-)

The only thing we haven't figured out yet is how to create an RSS feed from this News page. We'll work on that. (Anybody got an idea?) So we'll keep the blog at the wordpress site going for the time being.

Let us know what you think about the new site (design and content).

 

 

We may have mentioned this before, but we are in the process of making mbeddr an Eclipse project. We have been working on the proposal for a while, and it is now online at eclipse.org. So if you are interested in using or participating in the development of mbeddr, there will soon be a well-defined governance process. If you are interested in the project, why don't you register as an interested party for the project?

 

 

After making it easier to use mbeddr on Debian-based Linux system, we are proud to announce that Windows users are now also able to use a simple installer to install mbeddr and all it's required tools. This will make using mbeddr on Windows much easier. The installer will run on any Windows system with .Net 4.0 installed. This is the case for Windows Vista and newer, or if you have manually installed it on XP.

The installer is available from now on with the install packages. After downloading it, you have to extract the zip file and run the mbeddr-installer.exe. It will ask you for administrator permissions and then download all the dependencies of mbeddr. We are able to download and install most of them but some need your interaction. The installer will guide you through the process. If you experience any problems with the installer please file an issue at our github repository. Beside a detailed description of the problem please also include the debug log of the installer. It is located in %TEMP%/mbeddr/.

The installer also deploys the mbeddr tutorial, in the subdirectory "tutorial". After opening it, you will likely get two errors. First, it complains about an undefined path variable mbeddr.github.core.home. Select Fix It, and delete the path variable. Second, it will complain about VCS root errors. Select Ignore, and the problem is solved. Both errors are a consequence of the fact that we take the tutorial from an environment that requires these two variables, it is currently not so simply to avoid the (easy to fix) errors in the deployed version.

 

 

From Oct. 29 to Oct. 31, the European edition of Eclipsecon will take place in Ludwigsburg, Germany. As usual it is packed full of interesting talks on topics around Eclipse -- and others! For example, there is a talk about mbeddr on Tuesday the 29th in the Bürgersaal room. In the talk, Stefan (from BMW Car IT) and Markus will talk about how mbeddr was used to simplify the development of AUTOSAR software. Of course, it includes an introduction to mbeddr itself as well. So if you are at Eclipsecon, please join us for the talk!

 

 

We have just created a new EAP release for mbeddr. You can get it at the download page. While we have called it an EAP, this is a fairly stable release that runs on the 3.0.1 version of JetBrains MPS. We are targetting a final 0.5 release for Eclipsecon next week. The code is probably ok, but we are struggling with updating the user guide in time. Keep the fingers crossed :-)

 

 

Till today mbeddr was always released as a zip file that you had to unpack to your MPS installation. Which is fine on windows but since Linux systems ship with a powerfull package management system out of the the box, we are happy to announce that mbeddr is now also available as a Debian package. You can either download it from the Github release page or we have setup a repository containing the MPS and mbeddr package.

 

 

Introduction

As some of you might already know I have worked on an Arduino extension for mbeddr. Because such systems run headless, you can't just use printf for displaying messages. These systems usually ship with a serial or USB port which can be used to communicate with the outside world. There are actually two ways to deal with this. First we could replace the printf-backing file handle with a handle that writes to the serial port. Second we can use mbeddr's own reporting infrastructure: this approach also gives us more flexibility because we could either write messages to the serial port or store critical errors in EPROM for further investigation.

Here I will talk about how to build your own reporting backend for mbeddr, in this case a backend that writes to the serial port.

Architecture

First I will give you an overview about the reporting architecture of mbeddr. It consists of four main parts: MessagesDefinition, MessageDefinitionTable, theReportStatement and a ReportingStrategy.

MessagesDefinition

Messages, as the name suggests, define messages. They have a name to reference them, a text that is written out when the message is reported and they may have parameters. These parameters are basically key-value pairs. A message also has additional attributes:

• MessageSeverity: similar to a priority it can be ERROR,WARN and INFO

• active: a boolean flag that defines if the message is active or not.

• count: a boolean flag that defines whether the number of times the messages was reported should be counted (useful in test cases).

MessageDefinitionTable

A collection of messages. Any MessagesDefinition belongs to a MessageDefinitionTable. It acts as a kind of namespace for messages.

ReportStatement

The ReportStatement is used to report a message. It references a message and provides the actual values for parameters, if the message defines any. The parameters can be any value matching the type of its definition, for instance a local variable or a value obtained from an external sensor. The statement also provides so called checks which is a guard. Only if it evaluates to true will the message be reported.

ReportingStrategy

The ReportingStrategy is used in the build configuration to configure which kind of reporting the project uses. In mbeddr there are already predefined reporting strategies: printf and nothing. As the name suggest the first one uses simple printf statements to report a message and the later does nothing with them.

Implementation

Now that we have a overview about what we need let's start implementing our own reporting.

ReportingStrategy

The first thing we need is a ReportingStrategy. To do so we create a new concept and name it SerialReportingStrategy:

The editor also looks straight forward, just a constant cell with the words serial reporting in it:

Now we can select this new strategy in the mbeddr build configuration:

So thats it for the visible part. We can select it but it doesn't really do anything, because there is no generator that generates the code to write the serial port. To change this we need to add a generator that reduces the concepts discussed above to C, in case serial reporting is selected.

Generator

First we create a new Generator in MPS:

As you can see the is applicable rule checks if the selected reporting in the build configuration is the SerialReportingStrategy; otherwise this generator will not do anything (hoping that another generator will reduce the reporting concepts to C).

Let's start with the easiest thing the generator should handle: disabled messages! We create a reduction rule that only applies to messages that have the active flag set to false and then abandons the input:

The reporting architecture of mbeddr contains two core elements: a MessageDefinition and a MessageDefinitionTable which combines multiple messages. Messages are always part of a message definition table. So we need to reduce the table first. The generator is also quite simple. It take a MessageDefinitionTable and calls the $COPY_SRCL$ for its messages. Which loops over all of the massages and tries to reduce them in turn:

To get all the messages to reduce we use the nonEmptyMessages method of the MessageDefinitionTable behavior:

Next we need to reduce the message definition itself. We do two things in this reduction rule. First we generate a counter variable for the message. This variable can be used in tests to check how often a message occurred. In normal C code this variable is not relevant. And second we generate a char* variable that is initialized with the message text for later usage when the message is fired.¹

The property macros for the names are quite simple, they just generate a unique name for each variable so that we can reference them later. The macro for the initializer of the string is a bit more interesting. It generates its value from the name of the message and the text but also appends a \n at the end for line ending.

Now that we have the texts and the counters generated, we can start with the part that emits the code to post the message to the serial port. I our case we have a library that does all the details. All we need to do is call a function with a char* as a argument. The library is added via the make file, the corresponding header file is called serial.h. So the next thing to do is reducing the ReportStatements, but in order to keep the generator clean we implemented two different reduction rules one for a message with parameters and one for messages without parameters. Later you will see why. Here is what the generator for messages without parameters looks like:

The condition checks if there are no arguments and it does not contain an check guard. The reduction rule then defines some dummy variable and a dummy function. Inside the function an ArbitraryTextExpression is used to insert some text which is not a expressed with mbeddr semantics. In the inspector you see that it also specifies a header to include and a type.

Both variables use reference macros, and the message counter is also guarded with an if in the generator to avoid emitting this code in the case the message is not counted.

Next is the ReportStatement with properties. It requires some more work to be done because we can not use printf we have to use sprintf and store that result in a buffer before we can put it to the serial port:

The major difference here is that it first generates a buffer variable to use it with sprintf, then prints the message and after that loops over all properties of the message where it prints them to the buffer and finally writes them to the serial port. The size of the buffer is also calculated in the reduction rule. It takes the maximum length of the property name and adds 24 to which is the maximum length of a 64 bit integer printed as a string plus the characters added to make it look pretty. There is downside of this hard coded number, it will cause long strings to be corrupted.

What's next?

As you may have noticed, the whole part of checks is missing. I omitted this because it would blow up the post and shouldn't be that hard to do for you if you are familiar with the generator. To prevent data corruption of long string parameters you can either prohibit the usage of anything else than a number as parameter by using a type system check rule or calculate the length at runtime. It's up to you!

The main part of this code was written while adding serial reporting support to the mbeddr.arduino project. You can have a look at the code there for further references.

 

 

The release of MPS 3.0 is imminent, and one of the new features of MPS 3.0 is the ability to have several independently defined editors for the same concepts. In addition, there is also a new add-on developed by Sascha Lisson that can do really nice tables. We have used these two features in mbeddr to support editing tables using a tabular notation. Take a look at this video:

 

 

As you probably know, JetBrains has been working on a new major release of MPS, version 3.0. They are currently in the final phase of publishing release candidates and will release the final 3.0 in the next few weeks. Over the last few weeks, the mbeddr team has been working with EAP and RC versions of MPS 3.0 to move mbeddr to the new version.

We have been working with MPS 3.0 for a few weeks, and we think MPS and mbeddr are reasonably stable. We have since merged the 3.0 version into the mbeddr master branch. So if you update from github, you will get the version of mbeddr that runs on MPS 3.0. We will create a new release shortly.

So, to run mbeddr (from github), you will need MPS 3.0. You can get the current release candidate of MPS from the respective blog entries. Soon, of course, the final version will be available from the official MPS download page.

 

 

On our github release page we have just released a new version of the mbeddr MPS plugins. This is the first release based on MPS 3.0 (see previous post on how to get it).

While we have been working with this state of the code on MPS 3.0 for weeks now and consider it stable, there may still be a few bugs as a consequence of the migration (hence the EAP: Early Access Preview). Also, we have not updated the user guide in a while, so it may not be correct in every detail.

We have scheduled time for working on the user guide later this year, and we are also working on more convenient versions of getting mbeddr. Among them an mbeddr-specific MPS build that contains all mbeddr-relevant plugins (and only those!) as well as a one-click installer (at least for Windows) that also installs all the necessary tools (cygwin, git, verifiers, etc.).

Stay tuned.

 

 

It's summer time, so people are on holiday, and we're progressing on mbeddr only relatively slowly currently. Also, we are mainly working for the big-secret-customer-project that is based on mbeddr. However, there's changes to our team.

First, we have a new team member, Kolja Dummann. In his professional life, he has worked for various companies in technical and enterprise software development. In his spare time, he has worked on the internals of Android in the CyanogenMod project. He has also developed an integration of mbeddr with Arduino: this is how we got in contact with him. As part of the mbeddr team, he is now working on the mbeddr RCP version and on a convenient installer. Stay tuned.

The second change in our team is that Domenik is now working for mbeddr full-time, since his master thesis is now finished. He continues to work on the debugger, the legacy code importer and the build server.

So as you can see, we are making progress, even though that progress is more in infrastructural aspects, and not so much on language extensions. However, these infrastructural aspects are just as important, and it is high time that we focus on those.

 

 

Just a quick update from the mbeddr machine room: as you may know, the release of MPS 3.0 is just around the corner. It will have quite a few improvements in usability, one can add multiple editors for the same concept, and there will also be much improved table support. Over the last few weeks we have been on and off migrating mbeddr to MPS 3.0, and we are almost done. We are currently working on updating the build server. Once this is done, we are planning to create a new binary release of mbeddr, and we are also going to update the user guide to reflect the most recent version.