Il problema di fondo era che la chiamata JNI_CreateJavaVM produceva il segnale SIGABRT quando invocato all’interno di un altro framework, nello specifico stavo utilizzando l’SDK BoKS.

La porzione di codice interessata, a parte dovuti accorgimenti, era del tutto coerente con quanto riportato da HP al link

http://www.docs.hp.com/en/JAVAPROGUIDE/JNI_java2.html

Provando ad utilizzare i parametri di inizializzazione della VM più svariati non si è cavato un ragno dal buco, seguendo comunque le linee guida riportate qui http://www.docs.hp.com/en/JAVAPROGUIDE/JNI_java2.html#primordial, si è ipotizzato da subito un problema con lo stacksize su HP-UX, su Solaris, infatti, non erano stati riscontrati problemi di sorta.

Una sessione con tusc ha confermato quanto supposto:

La soluzione?

Un semplice export della variabile PTHREAD_DEFAULT_STACK_SIZE a 524288.

Si sarebbe anche potuta usare la chiamata pthread_default_stacksize_np(), ma poiché la parte di codice che crea i thread non è personalizzabile in quel dato SDK, l’export della variabile d’ambiente è stata l’unica soluzione attuabile.

Alla prossima!

Avere a disposizione una macchina virtuale ha numerosi vantaggi, e VirtualBox è una scelta da non trascurare, gratuito per uso personale (licenza PUEL), veramente semplice da usare e multipiattaforma. Lo uso tranquillamente su OSX e Archlinux, su Windows XP… Non proprio! :)

Volevo aggiornare alla versione 3.0.1, ma il risultato dell’installer era sempre il seguente “VirtualBox setup ended prematurely” seguito da un “Error 1603″. Anche la disinstallazione della versione precedente (2.2) non dava cenni di voler funzionare, di fatto sia l’installazione di una nuova versione che la rimozione della vecchia si interrompevano portando al rollback delle modifiche.

Rimuovendo tutti i file dalla directory “Programmi”, eliminando i riferimenti dal registro (quelli che sono riuscito ad individuare), disinstallando le interfacce di rete virtuali e cancellando anche i loro driver non sono riuscito ad ottenere altro che  un nulla di fatto.

Alla fine ho trovato questo articolo http://www.virtualbox.org/ticket/3701 e riporto di seguito quello che ho fatto anche io per risolvere:

1. tasto windows+r -> regedit ;
2. Export della chiave HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\DIFxApp\Components su un file qualsiasi per comodità sul desktop (per esempio vbox.reg);
3. Sostituzione di tutte le occorrenze di HKEY_CURRENT_USER all’interno del file con HKEY_LOCAL_MACHINE in modo da ottenere il file come di seguito:

4. Import del file .reg nel registro (basta un doppio click sul file);
5. Rimozione della chiave HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\DIFxApp ;

Dopo il passo 5 l’installazione della versione 3 è andata senza alcun problema.

Alla prossima! :)

Con questo tipo di accesso però, avevo notato perdite di dati sul database, non tutto infatti diventava persistente e, certo di non aver scritto codice errato, iniziavo a pensare di non capirci più nulla.

Il fatto è che, a differenza di quanto ero solito fare con altri RDBMS, non è sufficiente chiudere una connessione con

al termine dell’esecuzione del programma, il driver effettua caching delle tabelle per ottimizzare gli accessi al file system e non tutte le modifiche vengono scritte sul file.

È necessario fornire al driver l’istruzione di “SHUTDOWN” di modo che tutti i dati eventualmente ancora in cache vengano correttamente resi persistenti:

Esiste inoltre, una funzione di shutdown che effettua anche una riorganizzazione del database ed una compressione dei dati. Essendo un’operazione lenta è bene non usarla troppo di frequente, il criterio d’uso è lo stesso di “SHUTDOWN”, “SHUTDOWN COMPACT”.

Alla prossima :)

Per poter utilizzare elementary dovrete prima aver installato le EFL (Enlightenment Foundation Libraries). Seguite il wiki al link di seguito

http://trac.enlightenment.org/e/wiki/EFLWindowsXP

Compilate anche elementary col solito

e ricordatevi di impostare la variabile d’ambiente ELM_ENGINE con

Eseguite elementary_test per vedere che sia tutto ok e il risultato dovrebbe essere il seguente

elementary on windows xp

Se qualcosa non va, probabilmente siete incappati nel mio stesso errore: aver compilato evas senza il supporto al ddraw. Ricompilate evas aggiungendo l’opzione –enable-software-ddraw. Io ho usato i seguenti:

Adesso posso iniziare a sviluppare qualcosa che sia crossplatform e che usi un’interfaccia grafica gradevole. Cosa però? Mi verrà l’ispirazione penso… Prima o poi… :)

Non è pienamente testato, potrebbe contenere diversi bug, diverse funzionalità sono ancora da implementare, ma chi volesse provarlo può scaricarlo da questo link:

http://fabiofalcinelli.it/files/archE17svn.sh

Potete testarlo, modificarlo redistribuirlo sotto i termini della licenza GPL.

Installazione

Per usare lo script è sufficiente copiarlo in una qualsiasi directory. Di default lo script creerà una cartella archE17svn nella home dell’utente che lo esegue ed esegurà tutte le operazioni al suo interno.

Configurazione

Lo script accetta i seguenti parametri:
-r popola un repository per pacman (non ancora implementato)
-f forza la ricompilazione di tutti i pacchetti
-R reinstalla la snapshot precompilata presente in community
-d compila con simboli di debug
-o=name1,name2,… checkout e compilazione dei soli pacchetti elencati
-w=dir cambia la directory di lavoro (il default è ~/archE17svn)
-h stampa a video il messaggio di aiuto

Una volta compilato, potrete usare e17… Di seguito un piccolo screenshot :)

e17 and wallpaper module

L’immagine mostra il modulo wallapaper che permette la configurazione dello sfondo del window manager. La cosa veramente interessante del modulo è l’ordinamento in scala cromatica delle immagini: ho sempre pensato che ordinare le immagini in base al nome (quindi in ordine alfabetico) non abbia molto senso e questo modulo ne è la prova.

Per vedere il modulo in azione, potete visualizzare il video al link sottostante

http://www.rasterman.com/files/wp2.avi

Alla prossima!

Vi descrivo di cosa avevo bisogno e di come ho risolto. Supponiamo di avere un programma che generi output, ma che questo output sia sprovvisto di timestamp. Se il programma deve essere eseguito ad intervalli regolari diventa un po’ difficile capire cosa sta succedendo analizzandone l’output che ne è stato eventualmente redirezionato su un file.

Se invece di redirezionarlo direttamente al file, lo diamo prima in pasto ad awk sarà però possibile aggiungere, per ogni riga, il timestamp di generazione della riga stessa. Ecco di seguito come, utilizzando il tool svnsync come esempio:

In realtà ho utilizzato nawk la cui implementazione supporta alcune funzionalità in più. Non ci dovrebbero essere problemi usando la stessa procedura con gawk.

Come al solito, spero che possa essere d’aiuto a qualcuno facendogli risparmiare qualche minuto del suo tempo :)

Chi secondo voi se non Microsoft con il suo Internet Explorer 6?

Per esempio, il fatto che non supporti nativamente il formato PNG trasparente è veramente fastidioso. GIF non è minimamente paragonabile con le sue limitazioni ed allora ho dovuto creare una semplice condizione per cui chi utilizza Explorer 6 vedrà qualcosa di diverso:

C’è anche una soluzione lato client, utilizzando Javascript, che potete trovare a questo indirizzo, ma per il mio scopo di cambiare solo una immagine di testata è stata sufficiente la soluzione di prima, che non esegue nulla lato client.

Molti sono i browser in circolazione ed utilizzare la variabile ‘HTTP_USER_AGENT’ per distinguere l’uno dall’altro è la scelta più semplice, sebbene non sia affidabile: è possibile mascherare e cambiare tale variabile, alcuni proxy la filtrano… La soluzione? Solo il rispetto degli standard.

Fortunatamente browser come Firefox e Opera prendono piede sempre più, Chrome si arrampica ed Internet Explorer 7 anche sembra aver intrapreso la strada della standardizzazione.

Perdonate il tag

ma il plugin che uso sembra avere ancora qualche problema. Vedremo se si potrà risolvere anche questo :)
Il plugin “CodeColorer” lo risolve egregiamente direi :D

Il codice in questione sembra, infatti, causare un piccolo problema chiamato deadlock.

La cosa non si presenta sempre, ma dipende fortemente dalla quantità di output che genera il comando e da come il sistema operativo gestisce il buffering della system call “write”. Lanciando truss da dentro al codice java, infatti, notavo che l’esecuzione delle system call si bloccava in attesa:

Non è stato facilissimo arrivare alla causa, il metodo è infatti molto semplice, ma adesso che ho identificato il problema l’errore appare quasi evidente. Il problema risiede infatti nel canale di standard error letto prima dello standard output:

1. Prima di poter leggere lo standard error è necessario che il processo che esegue il comando termini, e non è detto che vi siano errori;
2. Prima di poter avere tutto l’output disponibile c’è bisogno di qualcuno che consumi i dati nel buffer, ma quel qualcuno è in attesa sullo standard error;
3. Deadlock!

Sinceramente, questa spiegazione, seppur sensata non mi convince ancora appieno e appena avrò più tempo analizzerò meglio i trace delle system call, nonostante ciò riporto di seguito la versione del metodo che risolve il problema.

Questo è quanto, il metodo main d’esempio del post precedente però è ancora valido :)

In realtà i due costrutti sono molto più diversi di quanto non si creda. Ogni comando SQL ricevuto dal DBMS viene elaborato seguendo 3 fasi:

1. Compilazione (parsing del comando SQL);
2. Esecuzione;
3. Fetching (restituzione del risultato al client).

Supponendo che vengano eseguite molte operazioni, la classe PreparedStatement permette di eseguire il passo di compilazione una sola volta, la prima, e poi di aggiornarne i valori in seguito:

Questo si concretizza in un miglioramento delle performance, generalmente. Ciò non è sempre vero, ci sono altri fattori che entrano in gioco che possono rendere uno Statement più veloce di un PreparedStatement. A mio avviso anche se fosse, una leggera diminuzione di performance (che dipende moltissimo dal database utilizzato) per il PreparedStatement è sicuramente ben accetta data la sua grande flessibilità. Non solo, dalle FAQ Oracle ho appreso anche che ci sono dei benefici in termini di sicurezza nell’utilizzo di PreparedStatement: il binding dei dati, infatti, eviterebbe un considerevole numero di attacchi di tipo SQL Injection. La FAQ infatti riporta:

“Statements may be slightly faster if you are only going to execute the SQL once. PreparedStatements are much faster when the SQL will be executed more than once. If you are using the statement cache, which you should, getting a statement from the cache is the same as executing the same statement.

In general we strongly recommend that you use PreparedStatements. This is especially true if you are sending user provided data in the SQL. By binding the data to a PreparedStatement parameter you can prevent most SQL injection attacks. Any performance advantage of using Statements is negligible.”

Insomma, per i miei gusti, non c’è motivo di usare Statement e PreparedStatement è la classe vincente.

L’idea è semplice: se il comando fallisce, restituisco l’esito del comando (lo standard error) come un’eccezione di I/O, altrimenti il metodo torna l’esito del comando (lo standard output).

A questo punto possiamo, per esempio, scrivere il seguente main, un po’ inutile, ma rende l’idea

Ovviamente il codice non è ottimizzato essendo la prima stesura di getto, alcune cose potevano essere evitate (i due BufferedReader per esempio), ma spero che a qualcuno questo metodo torni utile.