Nvidia e KDE4: pace fatta beta2

Avevo gia' parlato dei problemi delle problematiche esperienze degli utenti KDE4 sfortunati possessori di schede NVidia.
Torno sull'argomento dopo qualche mese per valutare i progressi fatti e le aspettative future, inoltre vorrei raccontarvi come, a modo mio, ho risolto il problema.


Stato attuale dei driver NVidia
Al momento in cui scrivo i driver ufficiali NVidia sono giunti alla versione 177.82 e quelli bera alla versione 180.06.
Le prestazioni sono indubbiamente migliorate e i nuove driver beta non hanno bisogno degli "hack" di cui parlavo nel mio precedente articolo, ma a mio modo di vedere le prestazioni sono ancora deludenti. Speriamo che il futuro ci riservi la possibilita' di spremere al meglio le nostre costose e potenti schede grafiche.

Come ho risolto
Viste le prestazioni scadenti che ho riscontrato e visto che KDE4 e' un prodigio di usabilita', bellezza e funzionalita', ho ben pensato di non usare i driver proprietari, di non usare quelli open source "nv" (proprio non mi piace la limitazione nel nuomero di coloriu) ma di usare quelli open source vesa.
Usando questi driver la mia esperienza di utilizzatore di KDE4 e' finalmente soddisfacente.

Non tutti gli effetti grafici, infatti, funzionano al meglio, ma quelli che interessano a me si'.
Tra quelli ch e mi sono piu' cari ci sono "Dim inactive" (che oscura le finestre non utilizzate), "Dialog parent" (che fa lo stesso con le finestre di dialogo), "Present windows" (se andate in alto a sinistra vi espone le finestre usate nel Destop corrente), "Desktop Grid" (premendo CTRL+F8 vi mostra tutti i Desktop con le loro finestre in una griglia).
Questi effetti con i driver vesa funzionano benissimo. Purtroppo non altrettanto bene funziona l'effetto per le ombre, che ho dovuto disabilitare perche' le finestre non si ridisegnano bene in seguito al loro spostamento. Si puo' vivere lo stesso, lo so...

Un consiglio
Come sapete i driver utilizzati si scelgono configurando il file /etc/X11/xorg.conf. Ebbene se cambiate spesso i driver e non volete sempre intraprendere la procedura di riconfigurazione che vi porta ad avere un file xorg.conf funzionante potete fare come me. Attualmente ho tre versioni di xorg.conf una per i driver proprietari nvidia e le altre due per quelli free nv e vesa.
La mia fantasia mi ha consigliato di chiamarli rispettivamente xorg.conf.nvidia, xorg.conf.nv e xorg.conf.vesa.
Quando voglio cambiare driver mi basta semplice sovrascrivere con uno di questi /etc/X11/xorg.conf e riavviare la sessione grafica.

Cosa mi aspetto per il futuro
Non sono un esperto di driver grafici, ma veramente non riesco a capire il motivo dell'incapacita' di una azienda come NVidia di risolvere questo grave problema.
Le avvisaglie dei loro problemi a fornire supporto agli utenti del mondo linux e' ben nota agli utenti di compiz che per lungo tempo hanno avuto a che fare con il famigerato black window bug.
Purtroppo ho voluto accordare fiducia a questa azienda (in tutti questi anni avro' fatto vendere a NVidia almeno un centinaio di schede video, acquistandole per me, facendole acquistare al lavoro e consigliandole ad amici).
Non mi e' mai dispiaciuto inquinare il mio kernel linux con i loro driver proprietari, e mi piacerebbe davvero continuare a farlo. Purtroppo se il supporto rimane questo evitero' d'ora in poi di acquistare, far acquistare o consigliare tale marca di schede video.

Spero vivamente di rimangiarmi queste parole in seguito all'uscita di driver funzionanti al meglio.

safe-rm: proteggetevi dalle distrazioni

La potenza di una shell e' enorme, ed eventuali errori si pagano cari

A volte puo' capitare di eliminare un file od una directory involontariamente a causa di stanchezza, distrazione. Il piu' delle volte il colpevole e' il comando rm, un comando di basso livello, molto ligio al dovere e forse viene utilizzato talmente tanto da sottovalutarne la pericolosita'.

Anche io sono uno di quelli che ha perso dei dati a causa di uno script che invocava un rm azzardatamente. Per fortuna avevo un backup recente e ho recuperato in fretta quanto ho perso. Ma quell'esperienza mi ha messo sul chi va la'!


Una soluzione a queste tragedie, tipiche del Venerdi' pomeriggio e che vi possono rovinare il weekend, e' safe-rm, un programma molto semplice che si comporta in maniera identica ad rm, ma permette di specificare una serie di file o directory in una lista (a livello globale e per utente).

safe-rm e' uno script perl di meno di 200 leggibilissime righe che potete scaricare da qui

Un consiglio per utilizzare al meglio urpmi

Mai capitato che urpmi si bloccasse durante il download di un pacchetto?
Con l'arrivo di Mandriva 2009 urpmi scarica di default i pacchetti utilizzando aria2c, una specie di download manager in grado di scaricare i frammenti di un pacchetto da piu' server in modo da ottimizzare la velocita' del download.

Purtroppo non sempre tutto fila liscio...


Capita a volte che il download fallisca, spesso quando avete gia' scaricato mega di dati. Una semplice soluzione e' di utilizzare programmi alternativi per il download, ad esempio wget e curl.

Come?

urpmi --wget nomepacchetto
urpmi --curl nomepacchetto

urpmi --auto-select --wget
urpmi --auto-select --curl

urpmi --auto-update --wget
urpmi --auto-update --curl


Qualora vi trovaste particolarmente bene con una di queste soluzioni vi consiglio di definire un alias nel file .bashrc di root, inserendo una riga simile a questa:

alias urpmi="urpmi --wget"
alias urpmi="urpmi --curl"


Buon aggiornameto/installazione!

Ripristinare lo stato delle variabili locali in Python

Esempio istruttivo che mostra come cancellare variabili in un programma Python
Quanto leggerete qui di seguito vi mostrera' alcune tecniche che raramente userete in codice di produzione, ma nonostante tutto sono di indubbio interesse le enormi potenzialita' che il linguaggio di programmazione mette a disposizione dei suoi utenti.


Utilizzeremo in questo esempio, una shell Python interattiva, ma il codice funzionera' altrettanto bene se lanciato dall'interprete.
Il nostro scopo e' definire un numero indefinito di nuove variabili e poi cancellarle. E' possibile ottenere un dizionario delle variabili locali usando la funzione builtin locals.
Subito dopo aver avviato la shell fotografiamo lo stato delle variabili locali, salvando le chiavi di suddetto dizionario in una variabile di nome oldlocals.

>>> oldlocals=locals().keys()

Definiamo ora alcune variabili nuove.

>>> a,b,c,d = 1,2,3,4

Il contenuto di locals sara' diversi ora:

>>> newlocals=locals().keys()
>>> oldlocals
['__builtins__', '__file__', '__name__', 'readline', 'rlcompleter', '__doc__']
>>> newlocals
['a', 'oldlocals', 'b', 'd', '__builtins__', '__file__', 'c', '__name__', 'readline', 'rlcompleter', '__doc__']

Per cancellare le variabili definite dopo la nostra "foto" possiamo usare le funzioni insiemistiche del tipo set.

>>> newly_defined=set(newlocals).difference(oldlocals).difference(set(('oldlocals',)))
>>> newly_defined
set(['a', 'c', 'b', 'd'])
>>> a,b,c,d
(1, 2, 3, 4)

Ora andiamo a cancellare le variabili che siamo andati a definire.

>>> for var in newly_defined: del(locals()[var])
...
>>> a,b,c,d
Traceback (most recent call last):
 File "", line 1, in 
NameError: name 'a' is not defined
>>>

Perfetto, ora le variabili a,b,c e d sono libere!

Il discorso si potrebbe approfondire con risvolti molto interessanti: ad esempio potrete eliminare solo le variabili di un determinato tipo o le istanze di una certa classe.
Lascio a voi tutto il divertimento.

Python nose: scrivere test senza fatica per il nostro codice

Presto o tardi chi scrive codice deve fare i conti con imprevisti!
Uno dei modi per evitare sorprese e' quello di testare il codice scrivendo dei test che ne confermino la validita' di funzionamento.

Chi scrive codice in Python potra' giovarsi dalle comodita' offerte da Python Nose per scrivere test senza grossa fatica. La particolarita' di Python Nose e' che riesce a scovare le funzioni e le classi di test nel codice basandosi sul loro nome e senza bisogno di importare moduli esterni.

Per esempio...

Supposto che abbiate installato nose, andiamo a cimentarci con una funzione molto semplice ma che puo' riservare sorprese!
Guardate qua:

def fattoriale(n):
    """Funzione ricorsiva per il calcolo del fattoriale di un mnumero
    """
    if n == 0:
        return 1
    else:
        return fattoriale(n-1)*n

Che ne pensate? A prima vista sembra scritta bene, ma in realta' riserva qualche sorpresa.
Prima di tutto siamo sicuri funzioni?

Per esserne certi salviamo questa funzione in un file con estensione ".py" e aggiungiamo ad essa una prima funzione di validazione che controlli che i risultati siano corretti.
Affinche' nose si accorga della funzione di test, il suo nome dovra' contenere il prefisso "test" (geniale! :)). Il concetto e' che il test avra' successo la funzione ritornera' dei valori coerenti con quelli che sono calcolabili per altra via. Ad esempio i fattoriali dei numeri 0,1,2,3,4,5 corrispondono ai valori 1,1,2,6,24 e 120.
E' ovvio che se troviamo risultati diversi da questi significa che qualcosa nella funzione non torna.

La funzione che fa il test assomigliera' a questa:

def test_fattoriale():
    """Funzione invocata per testare la correttezza nel calcolo
    """
    checks = (1,1,2,6,25,120)
    for i, check in enumerate(checks):
        f = fattoriale(i)
        assert f == check,\
        "Il fattoriale di %s e' %s" % (f, check)

Come vedete definiamo nella variabile checks i valori "corretti" e li confrontiamo con quelli che andremo a calcolare con la nostra fantastica funzione!

Il vostro file, fatto questo, assomigliera' a questo:

#!/usr/bin/env python
def fattoriale(n):
    """Funzione ricorsiva per il calcolo del fattoriale di un mnumero
    """
    if n == 0:
        return 1
    else:
        return fattoriale(n-1)*n

def test_fattoriale():
    """Funzione invocata per testare la correttezza nel calcolo
    """
    checks = (1,1,2,6,25,120)
    for i, check in enumerate(checks):
        f = fattoriale(i)
        assert f == check,\
        "Il fattoriale di %s e' %s" % (f, check)

E' arrivato il momento della verita'!!!
Per lanciare il test date il comando nosetest seguito dal nome del file, ad es.:
nosetests prova.py

A questo punto dovreste scoprire che il test e' miseramente fallito!
Il motivo di questo non sta nella funzione bensi' nel test, che e' scritto male... Infatti come ci dice l'output si aspettava che il fattoriale di 4 fosse 25 (non 24 come si puo' ottenere moltiplicando i numeri interi da uno a quattro e come giustamente sostiene la funzione scritta).

Correggiamo la tupla di controllo, sostituendo 25 con 24 e rilanciamo il test. Questa volta tutto dovrebbe filare liscio.

Aggiungiamo test meno banali
Come avete visto la funziona supera brillantemente il test. Pero' fallira' quest'altro test:

def test_tipo():
    """Controlla che la funzione fattoriale ritorni un numero di tipo long
    """
    for i in (0,1,2,10,200):
        assert type(fattoriale(i)) == long ,\
        "Il fattoriale di %s non e' di tipo long!" % i

Questo potrebbe rappresentare un problema in certi casi!
Per far passare alla funzione il test occorre modificarla in questo modo:

#!/usr/bin/env python
def fattoriale(n):
    """Funzione ricorsiva per il calcolo del fattoriale di un mnumero
    """
    if n == 0:
        return 1L
    else:
        return fattoriale(n-1)*n

Come vedete nel caso n sia 0 ritorna 1L, (prima ritornava semplicemente 1) ovvero un intero di tipo long. Questo forzera' il tipo del risultato ritornato dalle altre iterazioni, facendoci passare il test!

Fattoriale di un numero molto alto
La nostra funzione non e' ancora a prova di bomba. Facciamola scoppiare!

def test_boom():
    """Controlliamo che la funzione reagisca bene quando si trova a che fare
    con numeri grandi
    """
    fattoriale(1e10)

Per fare in modo che la funzione gestisca questo test occorrera' gestire l'eccezione che viene sollevata nel caso in cui il numero di cui si vuole calcolare il fattoriale sia troppo alto.