Archive

Archive for the ‘Programming’ Category

Building the rich client target platform with Eclipse 4.6

Written July 2nd, 2016 by

Few days ago the new Eclipse 4.6 “Neon” was released and as usual when a new update is released, I started to build the target platform required to develop rich client applications (RCP). The unhappy surprise was that the delta pack file containing the plugins and binary launchers for all supported operating systems, is no more available from the downloads page. Few years ago one of the packages useful to build a target platform, the platform sdk, was removed from the downloads. Not a big problem, it can be extracted from the standard Eclipse SDK package removing the unnecessary features and plugins with a bit of work, then adding the delta pack to enable the multi platform export options. Today without the delta pack, this is not possible anymore.

Read more…

Overlay Code with Parallax Propeller and GCC

Written April 7th, 2016 by

Programs that use overlay code were very popular in the era of early home computer systems when the amount of memory was not much, and the ability to load portions of code only when necessary allowed to make programs much larger than the available memory.

With microcontrollers we are in a similar situation with sometimes very complex programs and a rather limited memory, just think for example to the management of the SD card file system or the internet access libraries, that can severely limit the memory available for the program itself, especially if they are to be used simultaneously.

The Parallax Propeller is a microcontroller with 32K of internal RAM memory and uses an external EEPROM to load the code to run at power up. Since only the first 32K of the EEPROM are used for the program it is possible to dedicate the exceeding space of larger memories for data storage. Fortunately with the GCC compiler and the standard tools it is also possible to store portions of the program code to be loaded when necessary.

Read more…

JUnit Tests with Eclipse Databinding

Written July 14th, 2011 by

When we started to use Eclipse Databinding framework we faced the problem of running JUnit tests against databinding-enabled classes. Databinding requires a default Realm to be defined and all classes must be run from within this realm. The Eclipse framework automatically initializes the default realm at application startup with a code that looks like the following (from Workbench.createAndRunWorkbench):

    Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {
        public void run() {
            ULocale.setDefault(new ULocale(Platform.getNL()
                    + Platform.getNLExtensions()));
            // create the workbench instance
            Workbench workbench = new Workbench(display, advisor);
            // run the workbench event loop
            returnCode[0] = workbench.runUI();
        }
    });

 

JUnit allows to override the method used to run all tests defined in a class allowing us to add the code to initialize the default Realm like the above. Following are the two classes we are using to run JUnit tests against databinding-enabled classes.

 

JUnit 3

We wrote a DatabindingTestCase class derived from the original TestCase and overrode the run method to add the code to wrap the default realm, test case classes are then derived from DatabindingTestCase instead of TestCase.

import junit.framework.TestCase;
import junit.framework.TestResult;

import org.eclipse.core.databinding.observable.Realm;
import org.eclipse.jface.databinding.swt.SWTObservables;
import org.eclipse.swt.widgets.Display;

public class DatabindingTestCase extends TestCase {

    public DatabindingTestCase() {
    }

    public DatabindingTestCase(String name) {
        super(name);
    }

    @Override
    public void run(final TestResult result) {
        Display display = Display.getDefault();
        Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {

            @Override
            public void run() {
                DatabindingTestCase.super.run(result);
            }
        });
    }

    public void testEmpty() throws Exception {
        // To keep JUnit happy
    }
}

 

JUnit 4

A bit more complicated because it uses annotations and test cases aren’t derived from a base class. In this case we wrote a replacement class runner DatabindingClassRunner  and overrode the run method, just like we did for JUnit 3, test case classes are then annotated with @RunWith(DatabindingClassRunner.class).

import org.eclipse.core.databinding.observable.Realm;
import org.eclipse.jface.databinding.swt.SWTObservables;
import org.eclipse.swt.widgets.Display;
import org.junit.runner.notification.RunNotifier;
import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.InitializationError;

public class DatabindingClassRunner extends BlockJUnit4ClassRunner {

    public DatabindingClassRunner(Class<?> klass) throws InitializationError {
        super(klass);
    }

    @Override
    public void run(final RunNotifier notifier) {
        Display display = Display.getDefault();
        Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {

            @Override
            public void run() {
                DatabindingClassRunner.super.run(notifier);
            }
        });
    }
}

 

Links:

http://wiki.eclipse.org/index.php/JFace_Data_Binding

http://www.junit.org/