Java assertions

December 30th, 2008

Oggi, immerso nello studio della semantica assiomatica, mi stavo chiedendo se ci fosse qualche modo per controllare la validità di varie asserzioni durante l’esecuzione di un programma. Nello specifico, ho cercato subito dei riferimenti per il linguaggio che utilizzo maggiormente: Java. Ebbene, seppur poco noto, Java prevede un semplice comando per gestire le asserzioni.

Si tratta del comando assert. Il funzionamento è molto semplice, ecco un esempio:

int x=100;
assert x==100;

In questo caso si vuol verificare che la variabile x abbia il valore 100. Se la condizione non è verificata, Java produrrà un errore. Sebbene in questo esempio il comando sia inutile, in molti casi le asserzioni consentono di scovare parecchi bug. Inoltre, sono anche utili per la comprensione del codice. Si può infatti, invece di utilizzare un commento, rimarcare che vale una data proprietà in un dato punto. Per fare un esempio, si può specificare che deve valere un invariante all’interno ciclo:

final int N=100;
int x=0;
int y=N;
while(x<N) {
  assert (y+x)==N : “Errore nel ciclo x=”+x+”, y=”+y;
  x++;
  y–;
}

Come si nota è anche possibile inserire un messaggio di errore, nel caso in cui la condizione non sia verificata. Un’altro aspetto positivo è che il controllo delle asserzioni è disabilitato di default. In questo modo durante la normale esecuzione non si avranno penalizzazioni in termini di performance (notare che la condizione può anche essere una chiamata ad un metodo…quindi un’asserzione può essere anche molto onerosa da verificare). Duranta lo sviluppo, invece, basterà abilitare le asserzioni tramite l’uso di un semplice parametro (-ea).

The future of programming

December 6th, 2008

Ho già avuto modo di sottolineare in un post precedente, come nel futuro aumenterà notevolmente il numero di core nei processori. Del resto i modelli quad-core stanno già invadendo progressivamente il mercato, mentre quelli dual-core sono ormai la norma.

Visto che la potenza del singolo core non sarà destinata (probabilmente) a grandi aumenti, è necessario sfruttare più core possibili, parallelizzando il programma. Un interessante idea è quella dell’uso dei linguaggi funzionali che, sebbene ideati prima degli anni 60′, non hanno mai riscosso gran successo. Sebbene infatti vengano usati in alcuni contesti, la loro diffussione è ancora molto scarsa.

Oggi mi sono imbattutto in questo articolo, che da una brevissima introduzione dei concetti di fondo. Inoltre suggerisce alcuni linguaggi per iniziare a provare (per chi non l’avesse mai fatto) le potenzialità di un linguaggio funzionale.

Leggermente legato a questi temi (programmazione parallela), vi segnalo nella sezione articoli, una mia breve introduzione ad MPI.

Boring problems…

November 26th, 2008

Gli aggiornamenti di programmi e librerie, portano troppo spesso a problemi. Sebbene sia in qualche misura divertente scovarli e risolverli, a volte non se ne ha né il tempo né la voglia. La questione peggiora quando si scopre che non c’è alcuna soluzione immediata.

Qualche giorno fa, sul caro OSX, ho provveduto a cambiare la versione di default di Java. Il tempo scorre e dal rilascio della versione 6, anche se sembra avvenuto ieri, sono ormai passati quasi 2 anni. L’operazione sembra semplice, il cambio di un link simbolico e qualche modifica tramite interfaccia grafica. Sembra funzionare tutto….ma all’avvio di Eclipse, un bell’errore.
Inizia la ricerca e dopo parecchio tempo scopro il problema…si tratta di SWT. SWT è un toolkit alternativo ad AWT o Swing, utilizzato da Eclipse per gestire l’aspetto grafico (disegno delle finestre con i relativi componenti). Il toolkit utilizza del codice specifico per ogni piattaforma (per avere un look nativo) e, al momento, per la piattaforma OSX supporta unicamente le API Carbon e non le più recente Cocoa.

Il problema è che Java 1.6 presente su Mac (almeno di default…ma non credo ci siano alternative) è unicamente a 64 bit. Il framework Carbon invece pare funzioni solo a 32 bit. Risultato: tornare a Java 1.5 (almeno per lanciare Eclipse) o attendere le SWT con supporto Cocoa (data prevista giugno 2009).

:(

Cool stuff everywhere

November 7th, 2008

L’informatica è forse uno dei campi in cui è più facile produrre qualcosa, senza grandi mezzi. Con a disposizione un semplice personal computer (i cui prezzi sono ormai molto bassi) è possibile fare davvero molto. Per citare una famosa frase da un libro di Linus Torvalds:

Sono convinto che l’informatica abbia molto in comune con la fisica. Entrambe si occupano di come funziona il mondo a un livello abbastanza fondamentale. La differenza, naturalmente, è che mentre in fisica devi capire come è fatto il mondo, in informatica sei tu a crearlo. Dentro i confini del computer, sei tu il creatore. Controlli – almeno potenzialmente – tutto ciò che vi succede. Se sei abbastanza bravo, puoi essere un dio. Su piccola scala.

Con un semplice programma è possibile costruire quasi tutto quello che si vuole, rendendo certamente un programmatore più vicino ad un artista che ad un tecnico.

La cosa bella è che a volte, con un po’ di ingegno, si può fare anche di più. Girovagando in rete, mi sono infatti imbattuto in due idee molto semplici, ma proprio per questo interessanti.
Non servono infatti complicati macchinari o attrezzature da migliaia di euro. Basta un semplice mouse, un po’ di inventiva, di tempo e la voglia di sperimentare.

Il primo progetto, utilizza un mouse PS/2 dotato della “vecchia pallina”. I sensori che servono per determinare lo spostamento della sfera, sono stati utilizzati per creare un segnavento.

Il secondo progetto invece richiede un più recente mouse ottico. L’autore infatti ha utilizzato il sensore CCD del mouse per realizzare una cam o uno scanner. L’immagine è naturalmente molto piccola, l’autore fa riferimento ad un particolare chip, ed è necessario smontare il mouse…tuttavia i risultati ottenuti sono carini.

Finding the bad patch

October 13th, 2008

In questi giorni stavo utilizzando il noto software Wine, per provare a lanciare un gioco. Sfortunatamente non ci sono riuscito, ricevendo una serie di errori che facevano presupporre un problema di Wine. Infatti il software è ben al di la che completo (il lavoro da fare è gigantesco), quindi succede spesso di avere applicazioni che non funzionano o con problemi.

Ho provato allora ad aggiornare all’ultimissima versione, purtroppo però ho ottenuto gli stessi risultati. Un po’ scoraggiato, ho deciso di ripiegare giocando un po’ al buon vecchio GTA. Anch’esso gira tramite Wine e ha sempre funzionato senza alcun problema. Niente da fare però questa volta, va in crash subito dopo il menu.

E’ evidente quindi che c’è stata una Regression, ovvero nella nuova versione in sviluppo sono stati introdotti dei bug, che non consentono più il funzionamento di qualcosa che andava bene nelle versioni precedenti.

A questo punto è importante identificare il commit incriminato, ovvero l’aggiornamento che ha causato il problema. Spulciando le pagine di Wine, trovo una simpatica guida per mettere in atto questa ricerca.

L’idea è abbastanza semplice, effettuare una ricerca binaria! In maniera analoga ad un algoritmo di ricerca su un insieme ordinato, si divide sempre a metà l’insieme, fino a trovare l’elemento che si sta cercando. Tale ricerca può quindi essere condotta in tempo logaritmico.

Wine utilizza Git, un sistema di controllo di versione creato da Linus Torvalds ed utilizzato anche per lo sviluppo del kernel Linux. Git consente di effettuare questa ricerca in maniera semplice (tramite il comando bisect).
Bisogna specificare una versione in cui non si riscontra il problema ed una (più recente) in cui invece il problema si manifesta. A questo punto Git scarica la versione intermedia tra le due (in base al numero di commit). Si testa quindi se il problema è presente e si informa Git. Se il problema c’è, allora il bug si troverà tra la prima versione e quella intermedia, se invece non c’è si troverà tra quella intermedia e quella finale. Git calcola ancora la media su questo insieme (grande metà del precedente) e l’indagine può continuare in maniera analoga. Dopo una serie di passi, si troverà la patch incriminata.

Si tratta di concetti semplici, ma di grande utilità nello sviluppo di un software, specie se di grandi dimensioni.

Java porting issues

September 30th, 2008

Oggi stavo proseguendo la realizzazione della mia tesi che prevede, tra l’altro, la creazione di un programma in Java. Una delle peculiarità di questo linguaggio è il fatto di essere multipiattaforma, visto che gira quasi ovunque senza necessità di ricompilazioni o pesanti adattamenti.
Tuttavia ogni tanto è necessario operare dei piccoli aggiustamenti, caso che mi si è presentato (in maniera un po’ inaspettata) proprio oggi.

La mia applicazione prevede una semplice interfaccia grafica, utilizzando le note librerie Swing. Si tratta di una finestra con una visione “a schede” ed un menu. Il problema è proprio rappresentato da quest’ultimo, quando l’applicazione gira in ambiente OS X. Infatti la gestione dei menu del sistema operativo di casa Apple è leggermente diversa da quella utilizzata da Windows, KDE o Gnome. Infatti in OS X c’è un unica barra di menu sempre visibile posizionata in alto, le cui voci cambiano a seconda dell’applicazione che possiede il fuoco.
Inoltre ogni applicazione ha sempre un menu con il nome della stessa in cui compaiono le voci per accedere alle preferenze, avere le informazioni sull’applicazione, chiuderla.

Inutile dire che realizzando un menu in Java nel modo “standard” non si ha assolutamente alcuna integrazione con il menu “globale”, ma la barra di menu viene invece inserita nella finestra, come in qualsiasi sistema. Tuttavia qualche ricerca in internet permette di risolvere il problema con una sola riga:

System.setProperty(”apple.laf.useScreenMenuBar”, “true”);

La soluzione sembrava troppo semplice, però ha avuto esito positivo. Tuttavia il problema del menu predefinito non viene risolto, cosa ovviamente prevedibile (come farebbe ad esempio Java a sapere quale delle mie voci serve per accedere alle preferenze, ammesso che ci siano ?).

Ancora altre ricerche mi portano al sito Apple, dove viene descritto l’utilizzo di una libreria che promette di integrarsi perfettamente con la piattaforma di Cupertino. Tuttavia non è fornito nessun link per scaricare il JAR in questione…scopro poi che è incluso con tutte le distribuzione di Java su Mac. In sostanza quindi è sufficiente modificare il proprio codice utilizzando tale libreria per integrarsi perfettamente sulla piattaforma Mac. Rimane tuttavia un problema, ovvero la necessità di averla sempre a disposizione anche quando si lavora in altri ambiente (per consentire la compilazione del codice).

Questa soluzione non mi soddisfa affatto, e così dopo un po’ di ricerche trovo un’altra libreria che fa al caso mio: Macify (download qui). Si tratta di qualche classe da pochi Kb, che utilizza la tecnica Reflection per chiamare i metodi della libreria fornita da Apple.
La cosa interessante è che la libreria di Apple non è richiesta in compilazione. Inoltre è necessaria in esecuzione solo se viene utilizzata (quindi se ci si trova su un Mac, che però la ha già di default nella distribuzione Java).

In sostanza dunque non sempre l’integrazione tra le varie piattaforme avviene in maniera scontata, nemmeno con un linguaggio come Java. Tuttavia va ricordato che, in questo caso specifico, non si possono effettuare “miracoli”. Ovvero la JVM non può dedurre quali voci del nostro menu siano da associare a quelle predefinite (es. opzioni) e quindi è necessario un intervento manuale di questo tipo oppure la modifica del funzionamento dei menu di Swing.

More cores, more threads

September 13th, 2008

Fino a pochi anni fa il concetto di multiprocessore era parecchio lontano dall’ambito desktop. Ultimamente invece le cose stanno cambiando molto, con l’avvento delle CPU multi-core di cui sono ormai dotati quasi tutti i pc desktop e notebook venduti attualmente.

Sebbene agli utenti “inesperti” la presenza di n CPU (o core) può far pensare ad un aumento delle prestazioni di n volte (rispetto ad una singola unità elaborativa), chi si occupa di informatica sa bene che le cose non stanno così. Semplificando molto la questione, al fine di sfruttare a pieno la capacità di elaborazione, è necessario avere dei processi (o dei thread) separati da eseguire su ogni CPU presente. Le cose funzionano “naturalmente” avendo diversi programmi in esecuzione, tuttavia lo scopo da raggiungere è sicuramente parallelizzare il singolo programma.

Una evoluzione dell’hardware coinvolge quindi in maniera importante il campo del software. Bisogna infatti costruire i programmi in maniera differente, cercando appunto di “dividere” per quanto possibile le varie parti, in maniera da eseguirle in maniera concorrente.
La questione non è affatto semplice, ed uno dei primi problemi è naturalmente il fatto che solo una parte del codice è parallelizzabile. A tal proposito ci viene in aiuto la legge di Ambdahl, che limita chiaramente le prestazioni ottenibili. Se ad esempio solo metà del codice fosse parallelizzabile, potremo ottenere uno speed-up teorico di fattore 2 (quindi solamente il doppio delle prestazioni avendo a disposizione infiniti processori).

Resta comunque il problema di come dividere il programma nelle varie parti per migliorare le prestazioni. Allo stato attuale se ne deve far naturalmente carico il programmatore, strutturando opportunamente il software che sta realizzando.

Un’altra strada che potrebbe riservarci il futuro è invece quella della parallelizzazione automatica, effettuata direttamente dal compilatore. Si tratta di un campo di ricerca ancora aperto e sicuramente con obiettivi molto ambiziosi. Tuttavia progressi in questo settore migliorerebbero le prestazioni, facilitando anche la vita del programmatore.
C’è chi sostiene che progetti di questo tipo siano inrealizzabili, non la pensa sicuramente così Frances Allen, vincitrice del premio Turing 2006 che ha dedicato una vita a tecniche di ottimizzazione dei compilatori.

X.Org…not so bright

August 21st, 2008

Oggi ho provveduto a sostituire il mio monitor, passando da un 19” con rapporto 5:4 ad uno di tipo widescreen con rapporto 16:10 (non 16:9 come molti credono…ma questo è un’altro discorso).
Ovviamente i due schermi lavorano a risoluzioni diffirenti, sono quindi passato da 1280×1024 a 1440×900.

Dopo aver ritoccato un po’ il file xorg.conf ho avviato il server X, ma non ha funzionato. Purtroppo il monitor lamentava una modalità “non corretta”. Ho continuato a trafficare parecchio, impostando la risoluzione, la frequenza di refresh verticale e orizzontale ma senza risultato.
Alla fine ho dovuto spulciare il log di X alla ricerca di ulteriori parametri, come il “Pixel Clock”. Impostando quindi una modeline appropriata, sono finalmente riuscito a farlo funzionare.

La cosa simpatica è che tali parametri non arrivano da posti “magici” o da siti web, ma è proprio il monitor che li comunica secondo lo standard EDID.
Mi pare davvero incredibile essere ancora a questo punto. Naturalmente alcune distribuzioni hanno il loro sistema per impostare risoluzioni ed altri parametri in modo più “amichevole”. Tuttavia mi sembra eccessivo dover andare ancora ad inserire nel file di configurazione tutti questi parametri che come detto il monitor comunica direttamente.

Il progetto X11 ultimamente mi pare un po’ addormentato. Il fork di XFree86 e la creazione della X.Org Foundation di qualche anno fa non hanno portato a gran miglioramenti (anche se il fork era stato effettuato solo per problemi di licenza). Inoltre l’ultima release (la 7.3) risale ormai a quasi un anno fa.

Naturalmente non è molto corretto criticare il lavoro di altri, senza contare che spesso (nei progetti Open) chi sviluppa lo fa nel tempo libero e senza essere retribuito, tuttavia ultimamente lo sviluppo di X11 mi pare alquanto deludente.

Play FLAC in Leopard 2

July 21st, 2008

Come evidenziato qualche post fa, ero alla ricerca di una “soluzione” per evitare di dover cambiare il file type della mia intera libreria FLAC, un file per volta.

La ricerca di un programma che si occupasse di ciò ha avuto esito negativo, così ho colto l’occasione per sperimentare la programmazione in ambiente Mac. Ho quindi realizzato una applicazione utilizzando Cocoa.
La programmazione in Objective-C non è stata molto difficile, anche se bisogna un po’ abituarsi al linguaggio che in realtà ha poco a che fare con il C++. Per disegnare invece le finestre Interface Builder è davvero, dalle prime impressioni, un ottimo ambiente. E’ un tool simile a Qt Designer, che consente la posizione grafica dei vari componenti in maniera molto intuitiva e soprattutto li collega alla parte “di codice” in modo davvero semplice.
Infine una nota negativa (sempre a mio parere) per l’IDE che consente lo sviluppo dell’applicazione, il noto XCode. Non ho trovato la possibilità di avere un aspetto all-in-one, ciò significa una nuova finestra per ogni file aperto il che rende davvero scomodo lavorare. Warning ed errori vengono evidenziati inserendo delle linee all’interno del sorgente in maniera alquanto scomoda. Anche la funzione di Code Completition lascia un po’ a desiderare. Insomma rispetto ad un IDE come Eclipse, secondo me, siamo davvero anni luce indietro.

Il programma (si chiama SetFileType), lo ho realizzato in qualche giorno, senza grandi pretese e funzionalità. Comunque svolge egregiamente il suo compito e mi ha consentito finalmente di importare in iTunes la mia libreria musicale.
Nel caso vi possa essere utile, lo potete trovare (unitamente ai sorgenti, è GPL) qui.

Inside Micropolis 1

July 5th, 2008

Come promesso, ho trovato un po’ di tempo per iniziare a sbirciare il codice sorgente di Micropolis.
C’è da dire innanzitutto, che non si tratta certo di una operazione facile. Tanto per cominciare il gioco è scritto interamente in C, con i relativi svantaggi dei linguaggi procedurali. Inoltre le righe di commento si contano sulle dita di una mano e si fa un ampio uso di variabili globali, rendendo ancora più complessa l’analisi. Ad ogni modo ricordiamo che si tratta di un progetto di 20 anni fa.

Il funzionamento della simulazione avviene, per certi versi, come mi aspettavo. C’è infatti un grande ciclo infinito che si occupa di monitorare costantemente l’attività di simulazione. Ricordando sempre l’epoca di realizzazione, si notano subito alcuni “trucchi”, fondamentali per aumentare le performance e consentire di giocare. In particolare ogni iterazione del ciclo non si occupa di tutte le cose da monitorare/aggiornare, ma vengono fatte “un po’ per volta”. Ad esempio, tra le varie cose da fare, c’è una completa scansione della mappa per effettuare tutte le elaborazioni su ogni componente che si è posizionato. Questa scansione viene portata a termine in 8 passi, dividendo la mappa verticalmente in 8 rettangolini, ciascuno analizzato in iterazioni differenti del ciclo principale.

Passando a questioni meno “tecniche”, ho iniziato ad analizzare come vengono calcolate varie cose durante il gioco. Quando si attiva il pannello “Evaluation”, vengono mostrare una serie di informazioni. Per esempio il “valore” della città (Assessed Value) viene calcolato come segue:

strade*5 + ferrovie*10 + stazioni_polizia*1000 + stazioni_vigili_fuoco*1000 + ospedali*400 + stadi*3000 + porti*5000 + aeroporti*10000 + centrali_carbone*3000 + centrali_nucleari*6000

Il tutto poi espresso in migliaia di $. Ovviamente con la notazione “strade” o “porti” si intendono il numero degli stessi.

Passando a qualcosa di più interessante, sempre nel pannello Evaluation, troviamo il sondaggio sul gradimento. Per calcolare la percentuale di SI e di NO, relativamente a “Is the mayor doing a good job?”, viene fatta una cosa molto semplice. Vengono generati 100 numeri casuali tra 0 e PUNT_MAX (che è 1000), ogni numero minore del punteggio corrente aumenta di un punto percentuale il SI (viceversa il NO). In media quindi la percentuale di SI rispecchierà il punteggio ottenuto, ma sarà comunque influenzata dalla casualità, come del resto in un vero sondaggio (per certi versi).

Le componenti da analizzare sono ancora moltissime, cercherò di farlo quanto prima…riportando magari parti più interessanti (che sarà però più difficile estrapolare dal sorgente).