Lesson of the day: Beware the indirect dependencies in Eclipse 4.2

Executive summary: If you cannot move or minimize your views in Eclipse 4.2, always check whether the org.eclipse.e4.ui.workbench.addons.swt bundle is present in your run configuration.

A view misses its minimize icon

Today Eclipse surprised me with a nice feature. I tried to reconfigure my runtime workbench to create some screenshots, but I couldn’t. The views were missing the minimize button, and dragging view parts between groups did not work.

I had some minor issues with the new workbench model, so first I tried to check everything is at its base setting. I reset the perspective, closed all perspectives, restarted the workbench, but nothing helped. Finally, I noticed a short error message in the Error log:

Unable to retrieve the bundle from the URI:
bundleclass://org.eclipse.e4.ui.workbench.addons.swt/org.eclipse.e4.ui.workbench.addons.minmax.MinMaxAddon

That provided the required hint: to conserve memory, I usually start a runtime Eclipse with a reduced set of plug-ins – possibly a dependency is missing. Looking at the uri from the error message, I found, that the org.eclipse.e4.ui.workbench.addons.swt plug-in was not added to the Run configuration. I checked the corresponding box, and voilá – everything worked as expected.

What makes this case more interesting is that the built-in dependency validation report no issues. I had my own debugging sessions because of missing dependencies, so I set all my Run configurations to validate every dependency at startup. This means, this plug-in is not needed for executing the platform (technically true), however, when it is missing, it strongly reduces the usability.

Alltogether, what I am missing is some kind of higher-level validation that could report such issues. But in the meantime, I publish this, hoping, someone else finds it useful.

DIY musical doorbell

A doorbell is not the most important equipment of a home, however it is necessary and it still matters in a way. It is the thing that makes the first impression of your home to any visitor. The standard school-bell type doorbells hurts the ears and freaks out everyone who dares to touch the button and anyone who is unfortunate to be home at the time. A musical doorbell can be really expensive and the sound of the cheaper ones are simply annoying. Why not try to build one at home?

Hardware

It can be easier than it seems at first glance. Almost every part of it can be found in the drawer of an average hardware hacker:

  • Any speaker scooped from an old PC
  • A cheap MCU
  • An NPN transistor
  • An 1K resistor
  • Optionally a potmeter for volume control
  • 4 diodes
  • 2 capacitors
  • An 5V linear regulator (L7805)

The theory of operation is really simple: the MCU drives the speaker with a square wave on an arbitrary frequency to make a sound. Because the MCU usually cannot bear high current enough to make it loud, a transistor is used to drive the speaker.

The power source may be a standard bell transformer, which makes 12V AC from the 230V AC. In my case it was given as in our apartment building there is one generator for more apartments. To provide a stable 5V for the MCU, a simple Graetz-bridge can be used along with a linear regulator.

Doorbell schematic (https://www.circuitlab.com/circuit/3x9m3u/doorbell/)
Doorbell schematic (https://www.circuitlab.com/circuit/3x9m3u/doorbell/)

Software

The software part is just as simple. The first problem is to make the proper frequency for the square wave output. The simplest approach for this is to use a timer integrated into the MCU, and toggle the output on the timer interrupt. Now the frequency can be set by the timer options.

The other task of the MCU to switch the settings of the mentioned timer after a time to make a series of sounds. I’ve used another timer to interrupt in every ~0.2sec, which decrements a counter to determine the delay for the sound. If the counter reaches zero, the new timer settings and delay counter are loaded from the program memory tables.

Calculation of timer settings

The music you want the bell to play, is a series of sounds with determined frequency. This must be converted to a series of timer settings. For the PIC16F1824 I’ve used, this settings includes the compare register value along with the pre- and postscaler settings. To determine the best settings for each sound frequency (best = real frequency closest to nominal within the available set of register values) is a straightforward task, but requires a lot of calculations. It is much easier to write a script that makes all the calculations and generates the proper code tables for the program. This way it is easy to change the music to whatever you want.

Finish the bell

All is left is a bit of soldering and putting it in a suitable box:

https://lh5.googleusercontent.com/-bCo7Z1mv3Jo/UBps6axVuLI/AAAAAAAAL00/Du4SNKyLdjg/s640/IMG_1373_cut.JPG
The finished doorbell

References

Java primitive type comparison – A wat look

Not long ago, we had a not too nice issue related to mismatch between int and long variables. As the concrete variables were coming from 1) a model created by others and 2) another model created by us, the solution did not appear to be simple.

We were thinking, if we could compare the variables by value consistently without the concrete type equality, we would not need to support both int and long numbers in our model, so we asked our collegue, Gábor Bergmann to experiment a bit with the comparison.

Sadly, the result is that there is no reasonable way to compare longs and integers by value. However, we found a truly nice wat moment, almost fitting to the issues presented by Gary Bernhardt in a talk called WAT at CodeMash 2012 (or instead of the video, you could have a look at http://www.shopify.com/technology/5370262-wat-a-funny-look-at-ruby-and-javascript-oddities).

Because of Java is statically typed, most inconsistencies of Javascript do not apply here. However, the implicit contracts of Java are sometimes broken, just as the following code snippet shows (it is Gábor’s work entirely, I only changed only the white spaces):

Basically, when comparing primitive types and their boxed values, if you have two different types, all hell’s might break loose. Sometimes two values are considered equal when using ‘==’ but not when using Object.equals. Even worse, transitivity can also be broken.

I cannot think about any possible reason for this behavior, but we could reproduce it issue consistently across different computers using Java 1.6, so this appears to be according to be designed that way.

If someone could provide some reasonable explanation, I would be glad for it. Then we could learn something nice instead of just laughing a bit. Otherwise, be careful with primitive comparison…

Multitouch gesture support for Zest graphs

When I read Jan Köhnlein’s post about multitouch gestures support in their graph viewer, I was thinking, these gestures would be a nice addition to the Zest visualization library. In addition to that, it could be my first new feature as a Zest committer, so I opened bug 371152.

So I looked into the multitouch API in SWT (btw. it is really to use, check snippet 353). Luckily, only a gesture listener had to be added, that is already supported by the Zest graph widget.

I thought about what gestures could be universally supported in the Zest graph, and found that scrolling is already supported, magnification is easy to implement, and for rotation I found a possible use.

Today, I finished the implementation, and created a short video presentation that shows the features in action. See the Youtube video: http://youtu.be/cVVxOIwHN7s

Additionally, it is possible to replace the built-in gestures by creating the graph with a specific style bit, and adding other gesture listeners manually as below:

//Disabling default gestures
Graph graph = new Graph(parent, ZestStyles.GESTURES_DISABLED);
//Adding own gesture listener
graph.addGestureListener(new GestureListener() {

  public void gesture(GestureEvent e) {
    switch (e.detail) {
      // Do nothing
    }
  }
});

I believe the base implementation of the gesture support is useful, but I am open to change it if someone has a better idea.

Reflective tree editor for Xtext-based languages

Xtext is a great technology. I really mean it. After 15-30 minutes (depending on your previous domain knowledge) you can get a really fancy textual editor, that parses your text into an EMF model. Xbase is even better: you can simply include Java-like expressions into your language, that can be easily translated into pure Java code.

However, while using Xtext I found some minor “paper-cuts”. One of the most problematic of them was the fact that I cannot open my textual models using the Sample Reflective Ecore  Model editor, as I get an exception: java.net.MalformedURLException: unknown protocol: java.

A similar exception occurred if I tried to open the files programatically (but without the help of the generated Xtext editor). When I asked in the Eclipse forums how to open Xtext model files programatically, I was answered (btw. very quickly – kudos for that 🙂 ) that a specific ResourceSet implementation is needed that refers to model files and classes available in a Java project.

This gave me the idea to create an Xtext extension that allows opening an EMF tree editor, the Xtext Reflective Tree Editor. The plug-in consists of two parts:

  1. An extended version of the org.eclipse.emf.ecore.presentation.EcoreEditor class, that opens its ResourceSet using the Xtext API (more specifically, uses an injected ResourceSet);
  2. And an Xtext generator fragment, that can be used to generate a new editor extension to the ui project (with the corresponding dependency added to the reflective editor plug-in).

Usage

To use the plug-in, just follow the following simple steps:

  1. Add hu.cubussapiens.xtext.reflectiveeditor as a dependency to your language project.
  2. Extend your editor generation workflow:
    1. Import the generator package: import hu.cubussapiens.xtext.reflectiveeditor.generator.*
    2. Add the new generator fragment at the end of the generator (file.extensions is the list of file extensions defined in the default workflow):
      fragment = ReflectiveXtextEditorFragment {
      fileExtensions = file.extensions
      }
    3. Regenerate your language.
  3. Unless the plugin.xml files are updated automatically, you have to copy the newly generated editor extension from the end of the plugin.xml_gen file of the ui plug-in to the plugin.xml file. The simplest way to do this is to select both files, and open the compare editor from the popup menu (Compare with/Each other…), the copy the changes manually.
  4. Finally, open the runtime workbench, and open your textual model files from the popup menu using Open with/«LanguageName» Reflective Editor. The result should be similar to the screenshot below.
The Xtext Reflective Editor

In my case, the editor shows both the domain model generated from the file directly (the Pattern Model element), the inferred JVM model classes (the various JVM Generic Type instances), and also the referred Java classes as external resources (the resources beginning with the java:/ URIs).

Download

If you are interested in the plug-in in action, download it from our update site: http://eclipse.cubussapiens.hu, or take a look at the repository on Github: https://github.com/ujhelyiz/xtext-reflective

Version 0.5.3 is already available, and hopefully works well for all languages.