Genialità australiana

Se non è comunicazione questa…

Giovani programmatori crescono

Dal cubicolo a fianco, occupato di fresco da un “ciovane”

Se il programma crasha perchè gli hai passato un input sbagliato il problema è tuo, il programmatore che colpa ne ha?

Python c’è solo per Linux!

Certo che ogni tanto Python dà proprio i numeri! (Dopo un “indentation error”, NdA)

Contrattempi

Ecco una delle molteplici forme che possono assumere 85,00 euro + manodopera quando il vento ti richiude la porta mentre esci dal box.

Mi piace pensare che stamattina era destino non prendessi la moto.

The PySide of the moon: la fine di PyQt?

Oggi durante un pomeriggio afoso e un po’ noioso è arrivato un tweet contenente due tags di mio interesse: Python e Qt. Seguito il link al sito vengo a conoscenza di PySide, un’implementazione di bindings Python con licenza LGPL; leggo questa frase e subito penso distrattamente a PyQt che non ha seguito le orme di Nokia ed è rimasta su un modello dual licensing. Mentre scorro rapido le pagine del sito di PySide mi immagino il progetto come l’iniziativa un po’ velleitaria di qualcuno cui farebbe comodo una licenza meno restrittiva per PyQt, eppure a fondo pagina campeggiano dei logo di marchi piuttosto importanti, primo fra tutti Qt: quel logo sarà autorizzato?

Leggo le FAQ e scopro che sì, Nokia ha le mani in pasta nel progetto. Non solo, sempre dalle FAQ scopro che Riverbank è stata contattata da Nokia in un primo momento, ma non c’è stato l’accordo per una eventuale collaborazione, e siccome Nokia i mezzi ce l’ha, sta portando avanti il progetto con risorse interne.

A questo punto è chiaro che PySide non è un progetto da Summer of Code: a Nokia servono i bindings Python e si è messa a produrli. Come e quanto il progetto danneggerà PyQt?

Dal sito si apprende che l’API verrà mantenuta 100% compatibile con quella di PyQt (almeno in un primo momento); questo significa che per migrare del codice esistente basterà cambiare le direttive di import, rendendo di fatto gratuita l’operazione, fosse anche per soli scopi di valutazione del prodotto.

Ho già accennato alla licenza e sebbene personalmente trovi buono il modello di PyQt e ragionevoli i costi delle licenze commerciali, devo ammettere che trovo migliore la scelta fatta da Nokia per Qt e di conseguenza per PySide: LGPL. Nella mailing list di PyQt è stato chiesto al lead developer one-man-band di PyQt, Phil Thompson, come intendesse comportarsi a seguito della scelta di Nokia di abbandonare la QPL: una risposta chiara non è mai arrivata è arrivata solo dopo alcune settimane, ma non è difficile immaginare che gli introiti delle licenze commerciali di PyQt siano aria fresca per la Riverbank.

Sip, il tool usato dalla Riverbank per la produzione di PyQt è ad oggi l’unico in grado di generare bindings di codice Qt out of the box. Sebbene praticamente privo di documentazione, una volta presa la mano difficilmente sbaglia il colpo. Su questo fronte la Riverbank sembra un po’ più avanti, infatti l’omologo di sip per PySide, boostpythongenerator, presenta alcune limitazioni dovute a dipendenze da Qt che non lo rendono adatto alla generica produzione di bindings Python. Purtroppo per Riverbank però la situazione evolverà a breve nell’ottica di rendere il tool il più generico possibile, col rischio di farne uno strumento diffuso…

In definitiva, al momento non ho gli strumenti per giudicare la bontà di PySide non avendolo provato; di certo il patrocinio di Nokia fa pensare che lo scopo sia farne lo strumento ufficiale per gli sviluppatori Qt che lavorano in Python. Nel frattempo nella mailing list di PyQt tutto tace…

Migrare Windows da Parallels a VirtualBox si può!

I recenti rilasci di VirtualBox hanno reso il virtualizzatore open source di Sun un prodotto di altissima qualità; installato sui miei Mac OSX Tiger e Leopard ha rivelato buone doti di velocità, un impatto abbastanza contenuto sulla memoria di sistema ed una stabilità pressochè totale. Di qui la decisione di migrare le mie macchine Windows che avevo su Parallels, approfittandone per sistemare un’annosa questione di licenze…

Dato che VirtualBox non supporta il formato con cui Parallels memorizza su disco le macchine virtuali sono dovuto ricorrere ad un tool di terze parti, per la precisione a VMWare Free Converter. Ironia della sorte è stato il terzo competitor in ambito virtualizzazione desktop a rendere possibile la migrazione!

La procedura è abbastanza semplice tuttavia non banale: se non avessi raccattato in rete alcune informazioni probabilmente sarei ancora lì a cercare di capire perchè Windows non si avvia… Ecco i passi da seguire per una migrazione efficace:

1. Avviate la macchina virtuale su Parallels e disinstallate i Parallels Tools, quindi riavviate.
2. Siccome faremo una snapshot dell’esecuzione corrente, chiudete tutti i programmi, come indicazione di massima considerate che meno icone ci sono sul systray meno saranno i problemi potenziali.
3. Scaricate ed installate VMWare free converter.
4. Avviate il free converter e scegliete l’opzione “Convert Machine”, si aprirà un wizard.
5. Dite al wizard che volete migrare una macchina fisica, specificando poi che vi state riferendo al sistema attualmente in uso; mi raccomando di selezionare l’opzione “Ignore page file and hibernation file” onde evitare di sprecare inutilmente spazio disco. Nella combo box che seleziona il tipo di macchina virtuale lasciate l’opzione che trovate, ma se terminata la conversione la macchina non dovesse avviarsi sotto VirtualBox provate a cambiare. Ricordatevi che l’immagine della macchina convertita va salvata su un disco diverso da quello della macchina virtuale: usando le shared folders, specificate come disco di destinazione quello della macchina fisica oppure un drive esterno. Terminate il wizard ed avviate la procedura che durerà diversi minuti.
6. Chiudete Parallels ed avviate VirtualBox; aprite il “Virtual Disk Manager” ed aggiungete un disco virtuale esistente puntando al file prodotto dal convertitore.
7. Create una nuova macchina virtuale specificando come disco quello appena aggiunto.
8. Avviate la macchina virtuale ed incrociate le dita.

Il primo avvio prende diverso tempo, comunque non più di 5-6 minuti, se ne passano di più qualcosa è andato storto. Come troubleshooting potete nell’ordine:

1. Cambiare le opzioni relative al dispositivo IDE nella schermata di configurazione della macchina virtuale in VirtualBox.
2. Provare a riavviare la procedura di conversione cambiando alcune opzioni.

A questo punto la macchina potrebbe avviarsi (w00t!) oppure crashare in fase di boot. Se quest’ultima malaugurata ipotesi dovesse verificarsi, rimettete mano alle opzioni IDE e tentate di individuare la configurazione giusta: purtroppo non c’è una ricetta unica perchè molto dipende dalla configurazione originale della macchina in Parallells, nonchè dalla versione dei virtualizzatori.

Se dovesse verificarsi un errore al boot che coinvolge un file chiamato “prlfs.sys” vuol dire che vi siete scordati di disinstallare i Parallels Tools: niente paura, avviate Windows su VirtualBox in modalità provvisoria con prompt dei comandi ed eliminate il file in oggetto, lo troverete al percorso c:\windows\system32\drivers.

Se qualcuno trovasse utile questa guida sarei grato lasciasse un commento sulla propria ed inetavilmente travagliata esperienza di migrazione!

Ping

64 bytes from masci: icmp_seq=1 ttl=52 time=87.7 ms
64 bytes from masci: icmp_seq=2 ttl=52 time=86.5 ms
64 bytes from masci: icmp_seq=3 ttl=52 time=97.9 ms

Sarà il caldo, le cicale, i temporali delle 18:00 che mi rovinano le serate al playground, lo sbattimento del post-ferie… Fatto sta che non riesco a scrivere mezzo post, qualsiasi argomento mi pare troppo oneroso da affrontare.
Il tutto può probabilmente riassumersi in un laconico “non c’ho voglia di fare una mazza!”.