Scritture (molto) asincrone

Ho appena aggiunto nella lista dei TODO per il progetto Hyppocampus la menzione al prossimo sistema di schedulazione delle scritture che vorrei implementare per supportare l'API di salvataggio "discreto".
Non ricordo se ne ho gia' fatto cenno qui, ma un riassuntino non guasta mai: l'idea e' quella di fornire in LibHyppo un set di funzioni che permettano di aggiungere ed eliminare dati pure nel mezzo di un file esistente, in modo da poter poi includere in Kiazma tutto il necessario per eseguire sempre e comunque salvataggi automatici a bassa latenza (nell'ordine di secondi) dei contenuti editati dall'utente all'interno dei widgets.
Il problema sta ovviamente nel fatto che le operazioni di scrittura nel mezzo di un file implicano lo spostamento sequenziale di tutti i blocchi che seguono, e sarebbe assai poco conveniente procedere con la riscrittura completa ad ogni byte cambiato; introducendo in Hyppocampus una sorta di coda di richieste, che scheduli i dati e le posizioni in cui vanno scritti, si dovrebbe riuscire a raggruppare ed ordinare tali dati ed eseguire accessi al disco un po' piu' consistenti ed efficaci, si' da sfruttare l'operazione di memorizzazione effettiva su ROM per far transitare piu' materiale in una volta sola.
L'effetto di tutto cio' sarebbe la disponibilita' di un sistema di salvataggio automatico in tempo reale, per cui ogni modifica ai contenuti viene mantenuta senza esplicita richiesta da parte dell'operatore: niente piu' pulsanti "Salva" o "Salva con nome", solo un costante salvataggio.
Maggiori dettagli a seguire.

Apriti Xesam

Ne avevo sentito parlare, me ne accenno' nuovamente l'amico Gigi tempo addietro, solo adesso ne guardo la documentazione. E non mi e' piaciuta.
Xesam si propone come uno standard per astrarre un qualunque storage di metadati (solitamente ad esso viene associato il ben noto Beagle, ma altri indexer sono gia' compatibili o sulla strada per esserlo) e permettere dunque a qualunque applicazione di attingere alla ricca base dati messa a disposizione; un ottimo esempio ne e' un curioso file manager che organizza i files in funzione della data di creazione...
Peccato che l'intera specifica dello standard sia... un protocollo XML! D'accordo che in questo modo si separa nettamente il formato dell'interrogazione dall'implementazione, e che dunque si puo' usare con qualunque linguaggio e nel modo piu' congruo a seconda dell'occasione, ma... Diamine: non esiste uno straccio di libreria di nessuna forma che implementi una qualsivoglia parte della specifica, non un esempio effettivo, l'unico punto di riferimento e' il codice gia' esistente (per lo piu' in C#... Mah...), e manco son riuscito a trovare una lista vagamente completa (e neppure abbozzata) di attributi che secondo il formato e' legittimo chiedere da una parte all'altra.
Mi ero proposto mesi fa' di rendere SubConsciousDaemon compatibile con lo standard, in modo da sfruttare la base dati di Hyppocampus appunto come collezione di metadati interrogabile da applicativi esterni, ma negli ultimi venti minuti mi e' quasi passata la voglia: con delle indicazioni del genere non so fino a che punto il formato si possa diffondere e radicare, e quanto possa realmente affermarsi nella prossima tornata di software desktop-oriented. A parer mio, o chi sa davvero come funziona la baracca (ed ha dunque le necessarie competenze) provvede a fornire qualche strumento piu' concreto che non una sommaria lista di tags XML piu' o meno validi, si' da incentivare l'utilizzo della tecnologia, o non si va da nessuna parte...

Modu

La notizia non e' nuova, gia' l'amico Ninja me ne fece cenno un mese fa', ma solo adesso leggendone menzione su TechCrunch mi e' venuto in mente di riportare la cosa su questo mio blog.
Pare che dei pazzi israeliani stiano mettendo a punto una sorta di telefono cellulare espandibile: forniscono da una parte il core (una piastrina grossa come un biglietto da visita, in cui risiede l'hardware essenziale del telefono) e dall'altra tutta una serie di gadgets elettronici in cui piazzare sto' cosino, dagli chassis stilosi per ogni occasione alle sveglie agli impianti audio alle console portatili. Consiglio di dare uno sguardo al sito di riferimento (na' zozzeria completamente in Flash, ma tant'e'...), tanto per farsi una idea.
L'idea non mi sembra male, si tratta forndamentalmente di una forma di integrazione hardware (e gia' in passato ho menzionato quanto sia importante l'integrazione software...), sebbene credo che una connessione wireless tra componenti sarebbe piu' appropriata: a naso, mi sembra un tantino scomodo il fatto di arrivare a casa la sera e dover sfilare la piastrina dal guscio usato durante il giorno per infilarlo nella sveglia o in qualche altro arnese posto sullo scaffale... E c'e' inoltre chi mette in discussione le potenzialita' prettamente commerciali di questa soluzione...
Il progetto e' interessante, ed e' comunque una fonte di ispirazione in vista del giorno in cui alla FIC si decideranno a mettere in vendita il tanto discusso OpenMoko...

Uno, Nessuno, Centomila Linguaggi

La lettura di questo brevissimo articolo (trovato oggi su Slashdot) mi ricorda uno dei propositi che vorrei concretizzare nel prossimo futuro in SubConsciousDaemon: permettere la creazione di plugins in ogni possibile linguaggio di programmazione.
La realizzazione di per se' non dovrebbe essere complessa (basta creare un unico plugin che lancia l'eseguibile esterno e ne parsa l'output secondo un certo criterio predefinito... Brutale, ma rapido da implementare ed efficace), ma al di la' dell'utilita' o meno dello strumento ammetto che vorrei fare cio' anche e soprattutto per avere un modo (ed un pretesto) per scrivere un po' di codice in linguaggi diversi da quelli che sinora ho manipolato in modo semi-serio (ovvero: C, PHP, Java e poco altro).
Uno dei punti chiave di "The Pragmatic Programmer" (tomo menzionato anche nell'articolo sopra linkato, e di cui consiglio la lettura a tutti) e' appunto quello di sforzarsi per imparare almeno un nuovo linguaggio ogni anno, giusto per tenere la mente allenata e sufficientemente elastica per saper approcciare ogni sorta di problema secondo punti di vista diversi. Chiaramente, il suggerimento nasconde tra le righe un messaggio ben diverso che non "studia C++, Java, e Perl, PHP e Python ad oggetti": lo scopo dell'esercizio e' quello di affrontare diversi modelli di programmazione, che vadano oltre quella imperativa o ad oggetti, addrendrantosi magari nella programmazione funzionale, logica o di qualche altro tipo.
Sta di fatto che magari gia' stasera daro' una occhiata veloce ad Erlang, che viene citato da piu' fonti in special modo come linguaggio dedicato alla programmazione concorrente...

... e vissero tutti paralleli e contenti

Sebbene negli ultimi due giorni avrei dovuto scrivere un po' di roba (documentazione, articoli e quant'altro...), ho "perso" un po' di tempo a leggere un paio di interessantissimi documenti che segnalo qui su questo blog.

Il primo e' una serie di slides in merito a OpenMP, framework dedicato alla computazione parallela e da non molto tempo incluso anche in GCC.
La cosa fenomenale di questa tecnologia e' che e' sufficiente aggiungere nel proprio codice C poche direttive di preprocessore laddove si voglia suddividere la computazione su piu' blocchi da eseguire contemporaneamente (sfruttando magari un processore multicore...), e lasciare al compilatore il compito di occuparsi di immettere le istruzioni necessarie a caricare i threads, chiuderli, pescarli da un pool permanente, proteggere le variabili condivise per evitare race conditions, schedulare e molto altro. Il set di direttive e' limitato, e dunque facilmente maneggevole (soprattutto per me che ho scarsa memoria ;-) ), eppure appaiono strumenti per ogni sfumatura e per tutte le necessita'.
Mi spiace non avere sottomano un processore multicore su cui sperimentare pienamente i vantaggi della parallelizzazione, ma mi ripropongo comunque di metter mano a questa potente tecnologia, e chissa' che non finisca con l'usarla pesantemente in Lobotomy... Sarebbe interessante scrivere addirittura una libreria standalone di "utility" che implementi algoritmi e strutture dati disegnate a priori per la parallelizzazione...

Il secondo documento, piu' di carattere teorico ma comunque ricco di spunti di riflessione ed ispirazione, e' in merito ad un kernel scritto con finalita' di sperimentazione e ricerca da quello che era uno studente universitario qualche decennio fa': Synthesis.
In esso sono descritti una quantita' di concetti di fine computazione ed ottimizzazione estrema del codice, soprattutto riguardanti l'implementazione del kernel ma usabili in parte anche a piu' alto livello logico. Anche qui, ampio spazio e' riservato a divagazioni sulla parallelizzazione delle operazioni, col fine di ridurre la latenza e massimizzare la computazione pura, e sulla loro sincronizzazione.
E' un peccato che il tutto sia stato scritto in assembler, e su una architettura hardware oggi visibile al piu' in qualche museo...

Buona lettura :-)

Tutorial su DBus

Poiche' un po' di spam non fa mai male...
L'altro giorno ho messo online, su BarberaWare, un tutorial in italiano sull'utilizzo di DBus, demone di inter-process communication di alto livello largamente usato dalle ultime implementazioni dei componenti in Lobotomy.
Al contrario di quanto precedentemente accennato non ho tradotto il tutorial esistente (in inglese), ma ne ho steso uno mio completamente da zero: spero di essere stato abbastanza chiaro nei contenuti, sebbene per forza di cose taluni argomenti sono complicati e tali rimangono.
Spero che questo documento possa essere utile a qualcuno (primo tra tutti: HS1, cui lo avevo promesso almeno un mese fa' :-P ) e contribuisca a far radicare DBus come standard di interconnessione tra le applicazioni sul desktop Linux: come piu' volte detto, c'e' tanto bisogno di integrazione...
Attendo feedback in merito :-)

Lobotomy nella Blogosfera

Segnalo qui la pubblicazione dei primi due brani della prevista serie di articoli dedicati al progetto Lobotomy, da me scritti e gentilmente ospitati sul blog Pettinix. Lo scopo e' quello di fornire una presentazione informale, stringata e globale del progetto, ad uso e consumo degli occasionali lettori che bazzicano la blogosfera italiana.
Qualcuno si domandera' "Ma perche' sta roba non la pubblichi sul blog tuo, o sul sito di riferimento???". Una risposta non c'e', semplicemente qualche giorno fa' ho lasciato un commento ad una news riguardante un filesystem basato su MySQL ed il maintainer mi ha chiesto di scrivere qualcosa su Lobotomy per conto suo, tutto qui. Del resto, un po' di spam non guasta :-P
Accorrete e leggete numerosi! Io intanto corro a stendere il pezzo sulla LibHyppo!

Scatole Cinesi

Negli ultimi giorni ho piu' volte preso a lavorare sulla nuova incarnazione di Kiazma, la libreria grafica del progetto Lobotomy, ma solo ieri sera sono giunto ad una di quelle conclusioni che implicano un cambiamento radicale nella progettazione e nel processo di sviluppo. Ad una visione rivoluzionaria deve corrispondere una implementazione rivoluzionaria, o quantomeno assai diversa da quanto visto fino a quel momento.
Come piu' e piu' volte detto (e spero prima o dopo di completare il draft di presentazione dell'approccio in discussione) nella piattaforma a tuttora in sviluppo le applicazioni non saranno altro che descrizioni del layout degli elementi sul video, con forti limitazioni per chi stende i template nel linguaggio formale di riferimento (onde non garantire troppa liberta' e mantenere coerenza nell'ambiente) e pesante sfruttamento delle implicazioni dovute alle relazioni tra le informazioni visualizzate. A questo punto, andando a stravolgere il fondamento dello sviluppo di software per il desktop e ponente uno strato di astrazione tra il programmatore e cio' che viene presentato sullo schermo, quanto vale ancora il paradigma delle "scatole cinesi" implementato in tutti i moderni toolkits grafici? Vale ancora la pena di preoccuparsi di realizzare widgets di contenimento e formattazione variegati, secondo l'ottica di fornire al developer quanti piu' possibili strumenti e mettendo tutto nelle sue mani? Forse no...
In questo momento sto rivoltanto la logica gerarchica in cui dovranno essere organizzati i vari elementi inclusi in Kiazma, e credo proprio che alla fine dell'opera non sara' piu' particolarmente corretto chiamare questa libreria "toolkit", almeno non riferendosi al significato canonico del termine.
Al momento non approfondisco i dettagli, un po' perche' li devo a mia volta studiare ed un po' perche' sarebbe inutile senza l'accompagnamento del gia' menzionato draft sul linguaggio XML il cui interprete dovra' essere incluso in Synapse; rimanete sintonizzati per maggiori informazioni ;-)

Per la cronaca: tra una compilazione e l'altra sto anche esplorando tecniche ed elucubrazioni sulla programmazione parallela e la virtualizzazione... E' probabile che nel prossimo periodo questo blog si popoli di idee bizzarre :-P

Giramento di Palle

Chiaramente il titolo di questo post non si rifa' a qualche mio aneddoto particolare (sebbene ne avrei tanti da raccontare su questo tema...), ma ad un curioso dispositivo di input visto or ora in un articolo linkato da Slashdot. Si tratta di una sorta di joystick / mouse / leva / trabiccolo tridimensionale, usato nel video incluso come strumento di interazione con un videogioco ma potenzialmente usabile per tutto.
L'opportunita' di codesto genere di nuovi devices di puntamento sta nell'abbattimento dei limiti imposti dall'odierno mouse, con il quale e' gia' tanto riuscire a manipolare una interfaccia bidimensionale sullo schermo, ma l'altra faccia della medaglia sta appunto nella propagazione dell'oggetto e nell'effettivo sfruttamento della tecnologia: per spremere al meglio la potenzialita' dell'arnese sarebbe bene costruire intorno ad esso un nuovo modello di interazione "fisico" (cioe': non "interazione" nel senso di rappresentazione dei dati, come nel caso di Lobotomy, ma di manipolazione e navigazione di tali informazioni, magari in un ambiente 3D o comunque su piu' livelli), ma come si puo' pensare di intraprendere tale avventura senza manco avere sottomano sto' coso? Indubbiamente un cambiamento del genere imporrebbe una distruzione degli schemi odierni, ma quali sono i margini di una azione siffatta?
Personalmente sono un sostenitore dei nuovi strumenti fisici di interazione con la macchina (e per il mouse nutro lo stesso sentimento che esprimo per la nozione corrente di desktop environment: esiste da trent'anni, ha fatto il suo tempo...), ma sono conscio del fatto che essi prevedano uno shift ben maggiore che non una diversa rappresentazione astratta dell'informazione.
Tempo addietro (mi accorgo adesso di non averne mai fatto menzione sul blog) pensavo alla trackball come parziale alternativa al mouse, in particolare a qualcosa del genere: una grossa sfera e' facilmente maneggiabile, non ha il difetto di dover essere spostata (come appunto il mouse), sa essere veloce o precisa a seconda della necessita'. Vedrei bene la BigTrack sul tavolo della cucina di casa mia ;-)

Una Shell User-Friendly

Ho appena scoperto un simpatico progetto, che mi ripropongo di mettere alla prova una volta arrivato a casa e messo mano al portatile.
Il progetto si chiama fish, ed e' una shell. Si, una shell, come bash o zsh, ma orientata all'usabilita'.
E' forse un po' bizzarro associare una shell, applicazione completamente incentrata sulla linea di comando e dunque per definizione ostica per l'utente medio, al concetto di usabilita', ma ammetto che la lettura del breve documento introduttivo al design adottato per l'implementazione e' illuminante: vengono riportate poche e semplici regole universali, che trascendono la presentazione del software nei confronti dell'utente e sono applicabili a qualunque tipo di applicativo.
E fu cosi' che anche la command-line divenne a prova di utente...

Modularizzare Kiazma?

Da qualche giorno galleggiava nella mia testa l'idea, e per coincidenza giusto pochi minuti fa' ho scoperto che forse la cosa si puo' fare senza particolare sforzo.
L'idea consiste nel permettere l'estendibilita' di Kiazma con moduli esterni: definendo a priori una interfaccia cui devono aderire i widgets rappresentanti ad esempio un result set sarebbe possibile implementare un proprio elemento grafico e piazzarlo in un plug-in, da linkare a runtime a Synapse ed usare quando direttamente menzionato da un viewer. In questo modo sarebbe facile ad esempio costruire un widget che rappresenti un result set come una struttura tridimensionale, o che evidenzi le relazioni di un certo tipo tra gli elementi coinvolti, o in forma di acquario in cui gli items galleggiano (e' solo un esempio, se qualcuno si azzarda a fare una porcata simile gli mozzo le gambe...), ed arricchire le applicazioni costruite per Lobotomy.
Ebbene: trovandomi per non so piu' quale ragione sul sito di GTK ho trovato un breve tutorial su come usare GTypeModule per gestire per l'appunto GTypes dinamici usando l'astrazione dei GModules (inclusa in Glib). Come parte integrante del documento viene fornito anche un simpatico esempio di cui devo ancora esplorare attentamente il codice, ma che in linea di massima sembra fatto apposta per venire incontro alla mia necessita'.
Devo ancora meditare sulle solite implicazioni "tecniche" che si aprirebbero offrendo questa possibilita' agli sviluppatori esterni (come gia' detto tante volte: meno liberta' viene garantita, piu' coerente e' il sistema nel suo complesso), ma e' una idea che andra' analizzata in futuro.

Un Toolkit in 47 Righe

Questa sera, dopo lunghe e difficili elucubrazioni, sono riuscito ad ottenere un risultato per lo schema XML di cui vado parlando da qualche giorno (e non solo): un DTD di 47 righe, che include quasi tutto quello di cui ci sara' bisogno per definire "applicazioni" nel prossimo Lobotomy.
Manca ancora la definizione di un micro linguaggio di scripting che permetta di aggiungere controlli condizionali e fare qualche minima trasformazione al volo sui contenuti, e chiaramente la lista di funzionalita' che sara' possibile invocare dalla "viewer" verso la componente "controller" del nuovo sistema (ovvero: alla serie di daemons che dovrebbero girare indipendentemente dall'interfaccia grafica), ma almeno gli elementi di formattazione ci sono.
Come e' possibile formalizzare un toolkit in 16 tags e qualche attributo XML? La risposta e' semplice: la stragrande maggioranza delle rappresentazioni e' implicito. Sapendo a priori come trattare un certo metadato (in funzione del suo tipo, definito nella lista in LibHyppo: stringa, numero, o booleano che sia) non c'e' necessita' di esporre ad alto livello text entries, checkboxes o altro; c'e' bisogno solo dell'identificativo univoco di tale metadato. E un riferimento al file da cui tale valore si vuole prelevare.
Ora vorrei scrivere il solito paper informale di presentazione del primissimo draft (che sara' di certo pesantemente rielaborato prossimamente) per meglio illustrare i principi su cui si fonda il tutto, e preannuncio che ho gia' definito un prototipo di client di posta in un paio di files XML da 50 righe l'uno da usare come esempio.