Audio
Backup
Bash
C
Crittografia
CSS
Debian
Git
GNU/Linux
Google X
HowTo
HTML
Javascript
Kernel
Perl
Personale
PHP
Progetti
Regex
Rete
Source
SpaceShooter
Tips
TwitShell
Virtualizzazione
Web
Write It
In Progetti, SpaceShooter on
19 marzo 2010 with no comments
È inutile che fate quelle facce, tanto lo so che non vedevate l’ora di una nuova versione. Passiamo quindi subito all’elenco della spesa delle nuove funzioni.
Innanzitutto ho finalmente aggiunto una modalità a schermo intero, configurabile tramite il file di configurazione (~/.SpaceShooter/config), inoltre ho aggiunto una comoda funzione (soprattutto per me che devo aggiornare ogni volta la pagina del progetto) che permette di fare screenshot del gioco (il formato predefinito è bmp), le immagini vengono tutte salvate nella cartella ~/.SpaceShooter. Un’altra modifica che interesserà il giocatore più incallito (cioè in pratica solo me) riguarda l’aumento della velocità del proiettile del giocatore che ora va a 12 (non so bene quelle sia l’unita di misura.. tipo pixel a sessantesimo di secondo, o qualcosa del genere), mentre prima solo a 8. Altri aggiornamenti riguardano bugfix e riorganizzazioni del codice varie (se vi interessano date un’occhiata alla cronologia dei commit del repo Git, altrimenti ciccia).
Il tutto sempre al solito posto… ‘Notte.
In GNU/Linux, Kernel, Source, Tips on
18 marzo 2010 with no comments
In questo breve articolo vedremo come utilizzare un comodissimo script per aggiornare i sorgenti del kernel all’ultima versione disponibile.
Lo strumento di cui sto parlando è ketchup, uno script in python sviluppato da Matt Mackall (manutentore del set di patch -tiny) ed è scaribabile da qui.
Per gli utenti Debian sarà sufficiente un:
# apt-get install ketchup
ketchup permette, tra le altre cose di:
- Scaricare e decomprimere l’ultima versione disponibile del kernel.
- Aggiornare una versione locale dei sorgenti, scaricando e applicando le dovute patch.
- Controllare le varie firme GPG dei sorgenti.
- Gestire i diversi rami (e set di patch) di linux, come -stable, -mm, -ck, -git, ecc…
Per prima cosa è necessario creare una cartella in cui verranno scaricati i sorgenti. La cartella consigliata è ‘/usr/src’ (ricordatevi di aggiungervi al gruppo ’src’), e, una volta lì:
Potete ovviamente dare il nome che volete alla cartella, vedremo in seguito che comunque verrà modificato.
Una volta nella cartella è venuto il momento di scaricare i sorgenti, ma prima è necessario decidere quale ramo del kernel utilizzare. Come forse saprete esistono diversi rami di sviluppo del kernel. I principali sono -stable (l’attuale versione stabile del kernel), -mm (la versione di sviluppo) e -git (l’ultimo snapshot dal repository git), ognuno di essi ovviamente presenta pregi e difetti, starà poi a voi decidere qual’è la più indicata (anche se mi sentirei di consigliare vivamente il ramo -stable, che, a meno che non siate sviluppatori, va più che bene).
Esistono inoltre diversi altri rami che rappresentano varie versioni modificate attraverso set di patch, in modo da rivestire particolari campi di applicazione: tra i principali ci sono le patch -rt (real-time), sviluppate da Ingo Molnar, indicate per quei sistemi in cui la latenza deve essere al minimo (vedi ad es registrazioni musicali), le -ck sviluppate da Con Kolivas, ideali per sistemi desktop in cui la responsività (responsiveness, suona meglio in inglese) è molto importante ed altre.
Per ottenere una lista completa e una breve descrizione dei rami supportati da ketchup è sufficiente:
Scaricare il kernel
Una volta scelto il ramo (in questo il 2.6 che rappresenta lo -stable) è venuto il momento di scaricarlo, molto semplicemente:
Sostituite ovviamente a 2.6 il ramo da voi scelto. “Questa operazione potrebbe richiedere qualche minuto” (cit.)
Una caratteristica piuttosto carina di ketchup, è quella di modificare il nome della cartella in cui viene scaricato il codice in base alla versione dello stesso, semplicemente aggiungendo l’opzione ‘-r’ o ‘--rename-directory’:
Quindi se prima la cartella si chiamava ‘dir’, ora si chiamerà ‘linux-2.6.xx’ dove xx è l’attuale versione del kernel.
È inoltre possibile scaricare una particolare versione del kernel, come ad esempio la ‘2.6.22′ (giusto per prenderne una a caso):
Una volta scaricata sarà comunque possibile aggiornarla all’ultima versione, sempre con:
Tutto molto intuitivo.
Configurazione
È anche possibile gestire il comportamento di ketchup attraverso una file di configurazione: ‘~/.ketchuprc’. Le variabili disponibili sono pochine (solo tre) ma risultano più che utili.
Le variabili valide sono:
- default_tree – Che permette di impostare il ramo predefinito da cui scaricare il kernel e non sarà più quindi necessario passarlo via linea di comando; nel caso però che venga impostato via command-line verrà data priorità ad esso.
- precommand – Indica un comando da eseguire prima della sincronizzazione dei sorgenti.
- postcommand – Indica un comando da eseguire dopo la sincronizzazione dei sorgenti.
Per fare un esempio ecco il mio file ‘~/.ketchuprc’:
default_tree = "2.6"
postcommand = "rm ../linux && ln -s `pwd` ../linux"
Come potete vedere il ramo di sviluppo predefinito è il 2.6, mentre la variabile ‘postcommand’ è impostata in modo da aggiornare il link simbolico ‘/usr/src/linux’ alla nuova cartella (in pratica prima rimuove il vecchio link e poi lo ricrea passando la cartella corrente con ‘pwd’), da usare insieme a ‘--rename-directory’. La variabile ‘precommand’ è invece vuota perchè non mi serve a niente.
Questo è tutto, e come al solito, nel caso vogliate approfondire l’argomento, vi rimando al manuale:
In Progetti, SpaceShooter on
16 marzo 2010 with no comments
Lo so, lo so… “eccheppalle tutti ’sti aggiornamenti che non si fa in tempo ad installarne uno che subito ne spunta fuori un altro”… ma che ci volete fare, mi diverto troppo. “[...] e lasciatemi divertire.” (cit.).
Scherzi a parte, questa volta l’aggiornamento riguarda la modifica degli sprite per i nemici (esatto, ho detto “degli”, non è più soltanto un singolo e schifoso sprite), il supporto ad un file di configurazione (“~/.SpaceShooter/config” trovate tutte le informazioni nel link qui sotto, inoltre presto potrei aggiungere un man) e l’aggiunta di alcune funzionalità (legate alla appena aggiunta configurabilità) come la possibilità di disabilitare l’audio, la visualizzazione degli FPS e una più intuitiva nonchè completa modalità di debug.
Come al solito trovate tutte le informazioni necessarie qui.
In Progetti, SpaceShooter on
14 marzo 2010 with no comments
Nuovo aggiornamento a distanza di poco tempo. La principale novità riguarda il salvataggio del record di punteggio del giocatore in un file nella sua home (~/.SpaceShooter.record), inoltre ho fatto diversi aggiustamenti come i punti ottenibili dall’uccisione di un nemico (ora +5) e quelli perdibili ogni volta che se ne lascia passare uno (sempre -1), o la formattazione del testo a schermo.
Per tutte le modifiche potete consultare il file CHANGELOG.
Come al solito vi rimando alla pagina del progetto.
In Progetti, SpaceShooter on
12 marzo 2010 with no comments
Era da un bel pò di tempo che non dedicavo un pò di tempo a SpaceShooter… ebbene oggi l’ho fatto. L’aggiornamento riguarda principalmente l’introduzione di un timer (fa parte di Allegro) in modo da non dover impostare manualmente ogni volta la velocità del gioco (cosa assai scomoda). Una’altra piccola aggiunta riguarda la nuova schermata di aiuto che spiega quali sono i (pochi) comandi del gioco. Poi ho migliorato notevolmente il codice (almeno per i miei standard) ora è decisamente più leggibile e meno incasinato.
In occasione di questa nuova versione ho anche deciso di aggiornare la sua pagina dedicata, aggiungendo, tra le altre cose, il tarball dei sorgenti, un paio di pacchetti deb (i386 e amd64) e qualche screenshot.
Per tutte le informazioni andate qua.
In Progetti, TwitShell on
9 marzo 2010 with no comments
Con questo aggiornamento ho aggiunto una funzione per mostrare le date dei post con una “data relativa” come si vede nell’interfaccia web di Twitter, quest’aggiunta comporta l’utilizzo di un nuovo plugin (Date::Format:HTTP) ed allunga peciò la lista delle dipendenze.
Come al solito trovate tutto nella pagina dedicata.
In GNU/Linux, Perl, Source on
8 marzo 2010 with no comments
Piccolo e semplice script che imposta uno sfondo desktop casuale, dalla lista di sfondi ‘~/.gnome2/blacklists.xml’ (modificabile tramite l’opzione ‘Cambia sfondo scrivania’ nel menu del desktop), utilizzando gconftool.
L’utilizzo è abbastanza basilare: si avvia lo script (senza nessun argomento) e fa tutto lui. Un utilizzo tipo potrebbe essere quello di metterlo come applicazione di avvio in Gnome (Sistema -> Preferenze -> Applicazioni d’avvio) in modo da far cambiare lo sfondo ad ogni sessione, oppure creare un nuovo job in cron (sono solo esempi, ovviamente).
Trovate tutte le informazioni e il codice qui.
In Progetti, TwitShell on
7 marzo 2010 with no comments
Altro aggiornamento a TwitShell. L’unica modifica è l’aggiunta di un file Makefile.PL in modo da semplificare notevolmente l’installazione. Inoltre ho deciso di mettere a disposizione un tarball e dei pacchetti debian (i386 e amd64), in modo che non sia più necessario utilizzare Git per ottenere i sorgenti.
Trovate tutte le informazioni nella pagina del progetto.
In Git, HowTo, Tips on
6 marzo 2010 with no comments
In molti team di sviluppo software che si appoggiano a Git come CVS (vedi Linux) è necessario, per far accettare una modifica al codice, inviare una patch via email alla mailing list/maintainer interessati.
Partiamo con un esempio. Sto lavorando sul programma xyz (ovviamente utilizzando Git e di cui non sono amministratore) sul branch ‘dev’, mentre la versione aggiornata al repo remoto, e quindi non modificata, si trova in ‘master’ (chi non sapesse di cosa sto parlando, può dare un’occhiata a questo post).
Creare la patch
Dopo ore e ore di estenuante lavoro è venuto il momento di inviare il lavoro fatto a chi di dovere per essere unito alla versione ufficiale. Innanzitutto, come già detto, è necessario creare una patch. Il metodo tradizionale per creare una patch è ovviamente diff, ma Git ci viene in aiuto agevolandoci il lavoro.
Per prima cosa facciamo un commit:
Normalmente in questi casi il testo di un commit consiste in due parti, la prima, di una sola riga, contenente una breve descrizione del commit, e la seconda di un’altra manciata di righe con qualche informazione in più, ma ovviamente voi potete fare come vi pare, a seconda anche delle regole di stile del team di sviluppo in cui lavorate.
A questo punto il branch ‘dev’ è avanti di un commit rispetto a ‘master’. Per creare la patch a questo punto è sufficiente utilizzare il comando ‘format-patch’ di Git:
$ git format-patch dev..master
Che dovrebbe creare un file nella cartella corrente, con estensione .patch, e con nome uguale al testo del commit fatto precedentemente.
Inviare la patch
Per inviare la patch, si potrebbe ad esempio copia-incollare il file in una email e chi si è visto si è visto, purtroppo però molti client email tendono a modificare il testo delle email (ad esempio tabulazioni in spazi, simboli in maledette emoticon, ecc…) e richiedono perciò una certa configurazione (che spesso è diversa da quella utilizzata abitualmente) per funzionare.
Anche in questo caso Git ci viene in aiuto con la comodissima funzione ’send-email’.
Dovrebbe essere installata in modo predefinito (su debian il pacchetto git-email è tra quelli raccomandati da git-core), ma se così non fosse, risolviamo velocemente il problema:
# apt-get install git-email
La configurazione è abbastanza semplice:
Bisogna definire il server SMTP tramite cui mandare le email,
$ git-config --global sendemail.smtpserver <indirizzo server> \
# es smtp.example.com
l’utente (se richiesto)
$ git-config --global sendemail.smtpuser <email> \
# es utente@example.com
e la porta del server
$ git-config --global sendemail.smtpserverport <porta>
opzionalmente (se richiesto) è possibile definire il tipo di cifratura da utilizzare per inviare le email
$ git-config --global sendemail.smtpencryption <tipo>
Per tutti gli utenti che hanno già configurato in locale un MTA (tipo exim4, postfix, ecc…) o anche solo una MSA (tipo msmtp, ecc…) è possibile indicare semplicemente il percorso dell’eseguibile sendmail:
$ git-config --global sendemail.smtpserver /sbin/sendmail \
# oppure /usr/bin/sendmail
Per gli utenti che utilizzano msmtp (quindi per tutti quelli che hanno seguito questo articolo), al posto di /sbin/sendmail devono utilizzare /usr/bin/msmtp.
Dopodiché per inviare non bisognerà fare altro che digitare il comando send-email indicando il/i destinatari, tramite le opzioni –to e –cc (carbon copy, in genere usato per indicare le mailing list) e il file (quello creato prima) da inviare.
$ git send-email --to sviluppatore1@example.com \
--to sviluppatore2@example.com \
--cc mailin.list1@example.com \
--cc mailin.list2@example.com
Per maggiori informazioni:
In Progetti, TwitShell on
20 febbraio 2010 with no comments
Come promesso ecco un nuovo aggiornamento per TwitShell.
Come già annunciato ho modificato e riattivato la funzione di accorciamento degli URL, che ora si appoggia a Tr.im. È utilizzabile tramite i comandi ‘update’ e ’send’, aggiungendo, oltre a quelle già richieste, l’opzione ‘-s’ che permetterà di accorciare automaticamente tutti gli URL presenti nel testo dell’aggiornamento nel caso di ‘update’ o in quello del messaggio diretto nel caso di ’send’. Forse in futuro l’opzione ‘-s’ sarà attivata in modo predefinito (non ne sono ancora molto sicuro.
Inoltre ho riscritto una parte di codice per renderlo un tantino più efficiente.
Anche per oggi questo è tutto, ciao ciao.
AlexBio's Blog