[Mixminion-it] Compilazione Mixminion

[Luigi Messina]

Ciao Lorenzo,
>
> Grande! Avevo visto quest'errore ma non capivo proprio cosa ci fosse di
> male ad assegnare un valore ad una variabile.
> Una curiosita`: il nome della nuova variabile indica come hai risolto il
> problema? ;-)

in effetti non ci avevo pensato, lì per lì è stata la prima modifica
che mi è venuta in mente,
magari sarà freudiano ahaha ;-)
Comunque non ho idea di cosa ci sia nella variabile as o ass, forse
quando capiremo un pò meglio
come funzionano le cose sarà il caso di metterci un nome più esplicativo.

> Subito prima dell'output riportato da te io ho
>
> ERROR: test_clearableQueue (mixminion.test.MiscTests)
> Traceback (most recent call last):
>
>  File "build/lib.linux-i686-2.6/mixminion/test.py", line 787, in
> test_clearableQueue
>
>    q.clear()
>
>  File "build/lib.linux-i686-2.6/mixminion/ThreadUtils.py", line 51, in
> clear
>
>    if self._empty(): return
>
> AttributeError: ClearableQueue instance has no attribute '_empty'
[...]
>
> Potrebbe essere qui la causa? Da quel che ho capito la classe
> ClearableQueue deriva dalla classe (standard?) Queue. Questa non ha il
> metodo _empty(), bensi` empty(). Un typo? E` cambiata la classe Queue?
>

Da quello che ho capito io, nella Queue originale della versione di
python su cui stavano sviluppando,
non esistevano ne la possibilità di cancellare tutta la coda in un
colpo solo ne quella di impostare un timeout,
per cui hanno creato due classi: ClearableQueue e TimeoutQueue per farlo.
Non riesco a capire se siano subclass della classe Queue originale o
meno, perché
quello che avviene è questo:

# Imported here so we can get it in mixminion.server without being shadowed
# by the old Queue.py file.
from Queue import Queue, Empty
MessageQueue = Queue
QueueEmpty = Empty
del Queue
del Empty

ma non so che effetto abbia il comando "del Classe"
tuttavia, nelle versioni attuali di Python, il modulo Queue gestisce
sicuramente il timeout, mentre
non sono sicuro della cancellazione della coda, idealmente si potrebbe
fare a meno delle classi speciali
create da mixminion e usare quelle standard.

Ho anche cercato il metodo _emtpy e in effetti non esiste in
ThreadUtils, ma purtroppo per noi questa volta non credo si tratti di
un typo,
perché rinominandolo in empty il test rimane appeso con questo output:


running run
running build
running build_py
running build_ext
running build_scripts
copying and adjusting build/mixminion -> build/scripts-2.6
copying and adjusting build/mixminiond -> build/scripts-2.6
....

siamo ad un punto morto :P

Luigi