Archivio

Archivio per la categoria ‘Programmazione’

Assemblare la piattaforma target con Eclipse 4.6

Scritto il 2 luglio 2016 da

Pochi giorni fa è stata rilasciata la nuova versione 4.6 “Neon” di Eclipse e come tutte le volte che viene rilasciato un aggiornamento ho iniziato ad assemblare la piattaforma target per lo sviluppo delle applicazioni rich client (RCP). L’amara sopresa è stata quella di non trovare più il file delta pack contenente i plugin e i launchers binari per tutti i sistemi operativi supportati tra i file disponibili per il download. Già qualche anno fa uno dei pacchetti che facilitavano la creazione dei target, il platform sdk, è stato eliminato dai downloads. Non un grosso problema, lo si può ricavare dal pacchetto Eclipse SDK standard eliminando le feature e i plugin non necessari con un po’ di lavoro in più, aggiungendo poi il delta pack per avere le opzioni di esportazione multi piattaforma. Ora, senza il delta pack, anche questo non è più possibile.

Prosegui la lettura…

Codice Overlay con il Parallax Propeller e GCC

Scritto il 7 aprile 2016 da

I programmi che utilizzano codice overlay erano molto popolari nell’era dei primi home computer quando la memoria a disposizione non era molta e la possibilità di caricare porzioni di codice solo quando necessario permetteva di realizzare programmi molto più grandi della memoria disponibile.

Con i microcontrollori siamo in una situazione simile con programmi a volte molto complessi e una memoria piuttosto limitata, basti pensare ad esempio alle librerie per la gestione del file system di una SD card o per l’accesso ad internet che posso esaurire o limitare fortemente la memoria a disposizione per il programma vero e proprio, specialmente se devono essere utilizzate contemporaneamente.

Il Parallax Propeller è un microcontrollore dotato di 32K di memoria RAM interna e utilizza una EEPROM esterna per caricare il programma da eseguire al momento dell’accensione. Poichè solo i primi 32K della EEPROM vengono utilizzati per il programma è possibile dedicare l’eccedenza delle memorie più ampie alla memorizzazione dei dati. Fortunatamente con il compilatore GCC e gli strumenti standard messi a disposizione è possibile anche memorizzare porzioni di programma da caricare nella ram principale quando necessario.

Prosegui la lettura…

Test JUnit con Eclipse Databinding

Scritto il 14 luglio 2011 da

Quando abbiamo iniziato ad usare il Databinding framework di Eclipse abbiamo affrontato il problema di come testare le classi che utilizzano il databinding con JUnit. Il framework Databinding richiede un Realm predefinito e tutte le classi devono essere eseguite all’interno di questo Realm. Il framework Eclipse inizializza automaticamente un Realm predefinito all’avvio dell’applicazione con un codice simile a questo (da 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 permette di ridefinire il metodo utilizzato per eseguire tutti i test definiti in una classe permettendoci di aggiungere un codice simile a quello riportato sopra per inizializzare il Realm di default. Di seguito le due classi che utilizziamo per eseguire i test delle classi che usano il databinding con JUnit.

 

JUnit 3

Abbiamo scritto una classe DatabindingTestCase derivata dall’originale TestCase e ridefinito il metodo run aggiungendo il codice per inizializzare il Realm predefinito. Le classi contenenti i test saranno quindi derivate da DatabindingTestCase anzichè 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

Leggermente più complicato poichè utilizza le annotazioni e le cassi non derivano da una classe base. In questo caso abbiamo scritto una class runner di rimpiazzo DatabindingClassRunner derivata da BlockJUnit4ClassRunner e ridefinito il metodo run, come abbiamo fatto per JUnit 3. Le classi contenenti i test saranno quindi annotate con @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);
            }
        });
    }
}

 

 

Collegamenti:

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

http://www.junit.org/