domenica 19 giugno 2011

Packing..

Today I started packing, because on the 26th of June (next week!) I'll leave for Dublin. I'll stay there 7 months, and I'll spend them by working at Google as a Software Engineering Intern.

Needless to say, I am truly excited about working at such a great place, and I had to pass 4 hard-ish phone interviews before being accepted as an intern (about which I can't write because I signed an NDA).

I know it will be great, but today I have a bit of mixed feelings; I still have to find a room for the stay and I am a bit confused about leaving house and going to live alone for a few months. Luckily, a friend of mine will stay with me in the first 3 weeks, so I'll feel less alone.

That said, I'm going to do my best in those 7 months. It is a great opportunity that will shape my future if I play it well. And I'm going to have a lot of fun working at Google, there are some of the brightest minds working there and I'll have plenty of things to learn.

Well, I'll try to update this blog more often, to record the most important bits of this journey. 

For now, I'm going back to packing.

mercoledì 6 aprile 2011

The EduMIPS64 development blog

I just started a new blog about the development of EduMIPS64, a free (as in free speech) CPU simulator that I've been developing together with lots of other fellow students (and friends) some years ago.

I am writing a paper on EduMIPS64 and its usage in teaching Computer Architecture courses with other colleagues, and I feel that the current simulator version can benefit from some hours of my free time and get features that are already developed but not integrated and released.

All the EduMIPS64 developers are welcome to join me in this effort and in writing posts for the development blog, where I aim to write about the design choices of the simulator and the future development directions, like a sort of moving documentation of the development process.

Of course, if you are a developer and want to contribute to the simulator, contact me!

domenica 20 marzo 2011

My configuration files for Vim and GNU Screen are available on GitHub

I decided to put my configuration files on GitHub, mainly because in this way it's easier for me to sync them among the different machines I use, but with the nice side-effect that everyone can now get, use and improve them.

You will find

  • my GNU Screen configuration file, with a script that displays your current IP in the screen bar;
  • my Vim configuration file, with the plugins I use (for Python programming, LaTeX editing and GNU Gettext files editing)
You can get everything on GitHub: https://github.com/lupino3/config

giovedì 27 maggio 2010

Pomodoro technique for GNU Screen

The Pomodoro Technique (http://www.pomodorotechnique.com/) is "a way to get the most out of time management" (cit. website).

I've been trying the Pomodoro Technique and various software timers, but none of them satisfied me, mainly because I work using a full-screen shell (Guake: http://guake.org/) and I find distracting to switch to another window to check out the time.

So I wrote a small set of shell scripts that allow me to see the remaining pomodoro time in the lower-right corner of my window, thanks to GNU Screen, a software that I always use to manage virtual screens inside my full-screen terminal (http://www.gnu.org/software/screen/).

Screen allows you to heavily customize the appereance of the virtual screen. I changed mine using bits of code taken around the Internet to display date, time and other info. I exploited this customizability in order to make screen display the residual time of the pomodoro.

Here are the scripts:

start-pomodoro.sh

#!/bin/bash

SECONDS_IN_A_POMODORO=1500 # 25 * 60
ACTUAL_SECONDS=$SECONDS_IN_A_POMODORO
STEP=10
OUTPUT=/tmp/pomodoro

while [[ $ACTUAL_SECONDS > 0 ]]; do
let "will_print = $ACTUAL_SECONDS % $STEP"
if [ $will_print == 0 ]; then
let "minutes = $ACTUAL_SECONDS / 60"
let "seconds = $ACTUAL_SECONDS % 60"
printf "%02d:%02d\n" $minutes $seconds > $OUTPUT
fi
sleep 1
let "ACTUAL_SECONDS = $ACTUAL_SECONDS - 1";
done

stop-pomodoro.sh

#!/bin/bash
killall start-pomodoro.sh
echo stop > /tmp/pomodoro

read-pomodoro.sh

#!/bin/bash
cat /tmp/pomodoro

Now we have to add the command in the GNU Screen configuration file, and to add the output of read-pomodoro.sh in the status line:

.screenrc

backtick 1 5 5 /path/to/read-pomodoro.sh
hardstatus alwayslastline '[ %1` ]'

This is a minimal screen config file, that just displays the remaining time of the pomodoro. You must replace "/path/to/read-pomodoro.sh" with the real path of the script.

Now you can start your pomodoro with start-pomodoro.sh, and enjoy your pomodoro ticking in GNU Screen. With stop-pomodoro.sh you will stop it. In order to restart, run again start-pomodoro.sh.

Note that start-pomodoro.sh is blocking, so you might need to start it in background (start-pomodoro.sh &).

I hope that you find it useful as I did!

giovedì 20 marzo 2008

Vi mode per la shell bash

Essendo un utente molto assiduo di vim, mi è capitato più volte di utilizzare i suoi comandi in contesti nei quali quei comandi non sono validi, come la finestra di composizione di claws-mail, la finestra del browser, OpenOffice ecc...

Quando mi sono trovato a creare sequenze di comandi molto complesse con la bash, spesso ho sentito l'esigenza di potere utilizzare i comandi a me familiari per potermi muovere all'interno della riga creata.

Giusto oggi ho scoperto che è possibile, sfruttando la modalità vi per bash. È una caratteristica integrata nella shell, e si attiva semplicemente digitando '''set -o vi'''.

Con riferimento alle modalità di ViM, durante l'utilizzo normale della shell saremo proiettati in modalità inserimento, e la pressione del tasto ESC ci consentirà di passare alla modalità normale.

Ovviamente avremo a disposizione solo un sottoinsieme dei comandi di vi, ma che comunque è più che sufficiente per i piccoli task di spostamento all'interno della riga che possono essere utili per velocizzare l'editing del comando.

Se trovate interessante questa caratteristica, date un'occhiata al post che mi ha ispirato quest'articolo.

:wq

domenica 16 marzo 2008

Editing (comodo) di più file in ViM

Finalmente è arrivata la mia copia di Hacking ViM!

La sola visione della copertina mi ha ispirato questo post, in cui voglio descrivere come utilizzo le funzionalità di ViM 7 per gestire l'editing contemporaneo di più file, ovvero split windows e tab.

Come prima cosa, sarà introdotta la funzionalità di mapping di ViM.

Successivamente sarà descritta prima la modalità tradizionale di utilizzo di queste caratteristiche, e successivamente alcune agevolazioni e binding che sfrutto per accelerare di molto il processo di editing.

Mapping


Il mapping permette di definire (o ridefinire) il significato di una sequenza di tasti in ViM. Considerando che ViM è un editor modale, i mapping possono funzionare solo in determinate modalità. Il comando :map sequenza comandi funziona per le modalità normale e visuale (oltre che per la modalità waiting for operator, che non ci interessa), mentre il comando :imap sequenza comandi funziona per la modalità inserimento.

Split windows


La prima, utile caratteristica di ViM che viene in aiuto sono le split windows, ovvero la possibilità di dividere la finestra corrente in più finestre.

La divisione può essere orizzontale o verticale. Il comando per suddividere orizzontalmente la finestra è :sp nomefile, da eseguire in modalità command. Per la suddivisione verticale, si può utilizzare :vsp nomefile. Per chiudere la finestra, basta il semplice :wq, mentre per passare da una finestra all'altra è necessaria la combinazione di tasti <CTRL-w><CTRL-w>.

Quest'ultimo comando permette di spostarsi ciclicamente tra le finestre. Per massimizzare l'ampiezza della finestra corrente, si utilizza <CTRL-w>_.

Iniziando a provarle, vi accorgerete di quanto sia potente questa funzionalità!

Un paio di osservazioni:

  1. È alquanto scomodo premere in continuazione <CTRL-w><CTRL-w> per passare tra le finestre

  2. La finestra non si massimizza totalmente, ma mostra comunque una riga per ciascun file aperto in contemporanea



Per superare l'ultima limitazione, basta utilizzare il comando :set wmh=0, che imposta l'altezza minima di una finestra a 0, lasciando visibile solo una riga con il nome del file invece di due righe,

Per accelerare i tempi di transizione tra le finestre, è sufficiente creare un mapping personalizzato. Con le due istruzioni :map <C-J> <C-W>j<C-W>_ e :map <C-K> <C-W>k<C-W>_ associeremo alla combinazione di tasti <CTRL-J> il movimento allo split inferiore (con conseguente massimizzazione dello stesso), ed alla combinazione <CTRL-K> il movimento allo split superiore (con massimizzazione).

I tab


I tab sono stati introdotti in ViM 7, e sono una funzionalità che ritroviamo in molte applicazioni (principalmente web browser, ma anche altri editor o IDE).

Ecco i comandi di ViM per utilizzare i tab:

  • :tabe nomefile Apre un nuovo tab.

  • :tabn Vai al tab successivo.

  • :tabp Vai al tab precedente.



Vi renderete conto che è alquanto scomodo passare da un tab all'altro. Per questo ho creato questi due mapping:

  • :map <C-L> :tabn<CR>

  • :map <C-H> :tabp<CR>



Questi mapping associano ai tasti indicati i movimenti verso il tab precedente e successivo. Ora mancano solo due passaggi per terminare la personalizzazione.

La modalità inserimento


I mapping che abiamo indicato funzionano in modalità normale ed in modalità visuale. Sarebbe utile che funzionassero anche in modalità inserimento, possibilmente senza dover uscire dalla stessa.

Per fare ciò, sfruttiamo il comando imap:


  • :imap <C-J> <Esc><C-J>a

  • :imap <C-K> <Esc><C-K>a

  • :imap <C-L> <Esc><C-L>a

  • :imap <C-H> <Esc><C-H>a



I comandi di mapping sono ricorsivi, ovvero si può inserire un mapping dentro un altro mapping.

Nei mapping della lista descritta sopra, la prima cosa che viene eseguita è la simulazione della pressione del tasto Escape, e ciò ci porta in modalità normale. Successivamente viene simulata la pressione di una combinazione di tasti, che richiama una delle combinazioni che sono state descritte precedentemente. Infine, viene simulata la pressione del tasto a, che ci riporta in modalità inserimento.

Mettiamo tutto nel file .vimrc


Ovviamente è desiderabile non dover digitare ogni volta tutti questi comandi, quindi inseriamo tutto nel nostro .vimrc, in modo che ogni volta che ViM venga avviato possiamo usufruire di questi mapping.

Ecco la sequenza completa da inserire:

map <C-J> <C-W>j<C-W>_
map <C-K> <C-W>k<C-W>_
map <C-L> :tabn<CR>
map <C-H> :tabp<CR>
imap <C-J> <Esc><C-J>a
imap <C-K> <Esc><C-K>a
imap <C-L> <Esc><C-L>a
imap <C-H> <Esc><C-H>a
set wmh=0


Da notare l'assenza dei due punti all'inizio dei comandi.

Conclusioni


Da quando utilizzo questi mapping, sono molto più veloce nell'utilizzo di vim, e ciò mi permette di concentrarmi su ciò che sto facendo piuttosto che sull'utilizzo dell'editor stesso.

Ciò dimostra come, sebbene la curva di apprendimento sia ripida, imparare ad utilizzare ViM può incrementare notevolmente la produttività.

Ed ora.. godetevi questi mapping!

martedì 15 gennaio 2008

Linux Day: no alla strumentalizzazione!

Come membro del GNU/Linux Users Group di Catania, sento sia giusto dare risalto alla lettera che è stata oggi inviata a buona parte dei LUG italiani ed al coordinamento nazionale di ILS da parte di molti dei LUG siciliani.

La lettera esprime la voglia che noi abbiamo di discutere della trasformazione che, in alcuni contesti, il Linux Day ha subito, da giornata di promozione del software libero e di Linux a vetrina commerciale.

Non mi dilungo oltre, preferisco che a parlare sia la lettera, che propongo con particolare trasporto perché sono stato reclutato dal GLUG/CT proprio durante un Linux Day, e credo fortemente nel suo significato divulgativo.


Sono ormai sette anni che in Italia si organizza il Linux Day, la "giornata nazionale di Linux e del Software Libero". In questi anni, la manifestazione si è allargata in modo impressionante: da circa 40 eventi si è arrivati a superare ampiamente il centinaio. La manifestazione è cresciuta ed è cambiata, ILS ha proposto delle linee guida per i partecipanti, al fine di dare una connotazione unitaria ed omogenea ad una manifestazione che è il momento di massima visibilità per la comunità italiana del Software Libero.

In tutti questi anni noi abbiamo partecipato a questa manifestazione con il massimo entusiasmo: sentivamo il bisogno di un momento comunitario per comunicare all'esterno che l'utopia del Software Libero stava finalmente diventando realtà quotidiana, che GNU/Linux era l'alternativa possibile, e che il LD era l'occasione che stavamo aspettando.

A nostro modo di vedere, il Linux Day è una festa dedicata alla promozione del Software Libero e di GNU/Linux, prima di tutto come scelta etica e sociale e poi come risultato di un processo di
sviluppo "a sorgente aperto" che si traduce automaticamente in software valido, robusto ed efficiente dal punto di vista tecnologico; il Linux Day è il giorno in cui proporre alle persone
una scelta di libertà.

Guardando però i programmi delle decine di LD che sono stati organizzati in Italia negli ultimi anni, spesso ci sembra che lo spirito e gli scopi di queste manifestazioni non siano in linea con
questo nostro punto di vista. Secondo noi alcune manifestazioni locali degli ultimi quattro o cinque anni hanno, poco o nulla a che vedere con quello che dovrebbe essere l'obiettivo principale del LinuxDay, e cioé - secondo le linee guida - "promuovere l'uso e
la conoscenza del sistema operativo GNU/Linux e del software libero".

Alcuni Linux Day ci sembrano veri e propri "congressi" il cui intento principale è spesso quello di promuovere un prodotto o un'azienda. Che questa azienda abbia qualche connessione (più o meno
lasca) con GNU/Linux e col software libero ci sembra secondario. Gli intenti di un'azienda hanno giocoforza poco o nulla a che vedere con la diffusione di ideali di libertà e con la condivisione del sapere, essendo più incentrati sulla promozione di determinati prodotti o sulla pubblicizzazione di determinate realtà commerciali.

Riteniamo che le ragioni dello scollamento che avvertiamo tra chi, all'interno della comunità, crede come noi nel Linux Day come giornata per "promuovere l'uso e la conoscenza del sistema operativo GNU/Linux e del software libero", e chi invece lo interpreta come vetrina pubblicitaria per operatori del settore che hanno scelto di passare a GNU/Linux per motivazioni spesso molto diverse da quelle etiche e sociali, siano da ricercare prima di tutto nelle intenzioni
e nelle motivazioni dei LUG.

Probabilmente alcuni LUG italiani ritengono che promuovere GNU/Linux in qualsiasi forma e con qualsiasi mezzo, prescindendo anche dalle motivazioni etiche che spingono altri LUG e altre associazioni, sia in ogni caso giusto e necessario al fine di allargare il bacino degli utenti Linux. Questa posizione è, per quanto ci riguarda, rispettabile, ma crediamo fermamente che tale tipo di promozione prettamente commerciale o utilitaristica di GNU/Linux sia assolutamente in contrasto con le motivazioni che quotidianamente ci spingono ad impegnarci nella diffusione della Cultura del Software Libero e dell'uso dei sistemi operativi liberi, GNU/Linux in testa. E che sia in contrasto anche con le stesse motivazioni che ci spingono ad investire tempo e fatica nell'organizzazione del Linux Day.

Pensiamo che la promozione commerciale e per le aziende possa essere fatta 364 giorni all'anno, e soprattutto che il LinuxDay non sia il luogo in cui farla. In quest'ottica, le attuali Linee Guida proposte da ILS lasciano forse eccessivo spazio anche a manifestazioni che in realtà non hanno come scopo principale quello di divulgare cultura e di spronare alla consapevolezza, inserendo pertanto nel "Programma del Linux Day" anche eventi locali in sostanziale antitesi con le intenzioni iniziali dei promotori della manifestazione (vedi l'annoso problema, finora non risolto e forse nemmeno affrontato, delle sponsorizzazioni e delle autopromozioni
commerciali....).

Vorremmo pertanto aprire un dibattito all'interno della comunità per capire, finalmente in modo chiaro, quanti sono quelli che credono, come noi, che il Linux Day debba essere una manifestazione libera e commercialmente disinteressata, volta principalmente alla diffusione
di Cultura e alla presentazione di un modello di condivisione di Conoscenze.

Crediamo che porre questa domanda sia importante per la comunità e per le nostre associazioni, dal momento che non ci troviamo più a nostro agio ad aderire ad una manifestazione le cui espressioni locali sono spesso, in sostanza, molto diverse dalla "facciata" che presentano e dai principi ispiratori delle linee guida che, sempre formalmente, rispettano.

Vorremmo che questo chiarimento avvenisse in maniera pacata e serena, e che fosse un vero e sostanziale momento di confronto all'interno della comunità, che ci permetta di capire se la pensiamo allo stesso modo sulle questioni fondamentali, se gli obiettivi che ci poniamo sono simili e se abbiamo la forza di agire e di "camminare" insieme per raggiungerli, rendendo tra l'altro più esplicite le linee guida del Linux Day nell'indirizzare la natura
dell'evento.

Pensiamo che uno dei luoghi piu' adatti per affrontare questo dibattito possa essere la lista lug@lists.linux.it, utilizzata negli ultimi anni come spazio per il coordinamento delle attività dei LUG italiani.

--
Clug - Caltanissetta Linux user group
Freaknet MediaLab - HackLab (Catania)
GLUGCT - GNU Linux user group Catania
LUGSR - Siracusa Linux user group
MeLUG - Messina Linux user group
PALUG - Palermo Linux user group
Poetry - HackLab (Palazzolo Acreide)
Solira - Associazione Software Libero di Ragusa


Per chiudere, sottolineo come l'aspetto commerciale del software libero sia cosa buona e giusta, almeno a mio avviso.

Ma non è durante il Linux Day che vanno portate avanti iniziative promozionali o commerciali, sebbene relative al software libero.

Attendiamo gli sviluppi della discussione.