[CICLO 4] Storia 2

[cionci]

A me non passano...

[cionci]

Ora mi passano... Non capisco cosa succedeva...io facevo l'update e mi contninuava a ripristinare quella di Jocchan...

[71104]

Originariamente inviato da VICIUS

Visto che hai scritto il test lo assegno a te

doh battuto per 11 minuti
be', allora mi prenoto per il Pair Programming del 4.2.2; chi è l'altro pollo?

[cionci]

Ho fatto il commit, date un'occhiata...

[cionci]

Il commento al commit l'avevo messo, ma la build machine non lo fa vedere perchè ho fatto un altro commit con la correzione di uno warning e fa vedere solo quello... E' possibile far apparire i commetti di tutti i commit intercorsi fra la build precedente e quella attuale ?

[fek]

Originariamente inviato da cionci

Il commento al commit l'avevo messo, ma la build machine non lo fa vedere perchè ho fatto un altro commit con la correzione di uno warning e fa vedere solo quello... E' possibile far apparire i commetti di tutti i commit intercorsi fra la build precedente e quella attuale ?

Dovrebbero apparire tutti i commenti sui singoli file affetti da ogni commit.

[cionci]

Vero, nel log file

[VICIUS]

Originariamente inviato da cionci

Ho fatto il commit, date un'occhiata...

Perfetto.

ciao

[Jocchan]

Oops errore mio, dannate potenze di due

[^TiGeRShArK^]

ehm..
è possibile abilitare il server svn per permettere la modifica dei log?
ad esempio pure a me era capitato di aver dimenticato di inserire un commento, ma quando sono andato ad editarlo mi diceva ke il serve non era abilitato..
credo ke sarebbe un'opzione piuttosto utile vista le memoria e la sbadataggine dei componenti del gruppo

[VICIUS]

Originariamente inviato da ^TiGeRShArK^

ehm..
è possibile abilitare il server svn per permettere la modifica dei log?
ad esempio pure a me era capitato di aver dimenticato di inserire un commento, ma quando sono andato ad editarlo mi diceva ke il serve non era abilitato..
credo ke sarebbe un'opzione piuttosto utile vista le memoria e la sbadataggine dei componenti del gruppo

era nelle cose da fare. dopo la creazione di un account diverso per ogni utente e un bel pre-commit hook per impedire messaggi vuoti. prima o poi risolviamo.

ciao

[cionci]

Originariamente inviato da 71104

be', allora mi prenoto per il Pair Programming del 4.2.2; chi è l'altro pollo?

Se vuoi lo facciamo insieme...anche se, visto che ho già fatto un task, mi sembra più giusto che lo facciano altri... Comunque io al limite domani dopo cena dovrei essere disponibile...

[71104]

Originariamente inviato da cionci

Se vuoi lo facciamo insieme...anche se, visto che ho già fatto un task, mi sembra più giusto che lo facciano altri... Comunque io al limite domani dopo cena dovrei essere disponibile...

veramente ieri mi ha contattato ciddimauro in MSN dicendomi che lo voleva fare anche lui, però ieri sera non abbiamo potuto perché io e lui abbiamo orari incompatibili: io torno la sera dall'università e quindi lavoro sempre di sera, lui invece è disponibile a lavorare *prima* di tornare a casa la sera perché a casa non ha il pc (rotto mi pare di aver capito); ieri lui mi ha trovato in MSN qualche minuto prima di tornare a casa, ma era meglio evitare di fare il task in fretta e furia in pochi minuti, allora lui ha detto che mi contattava oggi e forse lo facevamo stasera (credo che abbia intenzione di usare un pc provvisorio).

[cionci]

Nessun problema...se non ci riusciste ed i tempi stringono...io sono qui

[fek]

Ragazzi, i task sono perfettamente chiari prima di cominciare? Nessun dubbio?

71104, discuti la test list con Cesare prima di iniziare e postatela qui sul forum. Io oggi pomeriggio e domani sono via.

[71104]

fek, abbiamo pensato a questa test list per il task 4.2.2:

- test per coda vuota
- test per coda non vuota
- test per ordine corretto degli elementi della coda (se ne potrebbero fare due)
- test per la correttezza del tipo di evento (pressione o rilascio)
- test per i timestamp

più altri eventuali test da aggiungere durante lo sviluppo o dopo se ce ne fosse bisono.

[71104]

dunque, mumble mumble, ho analizzato la situazione e le prossime cose da fare sono rimuovere l'uso del bitset in Input e usare la queue in reactToInput (quest'ultima cosa però non è esplicitamente richiesta dal task 4.2.2); è anche possibile che al termine del refactoring le classi AbstractKeyboard e derivate non esistano più secondo me.
intanto per rimuovere il bitset bisogna sicuramente modificare il codice in modo che usi un tipo intero anziché KeyCode per codificare gli eventi della tastiera; per l'esattezza il tipo Keyboard presente nelle librerie che usiamo restituisce i codici della tastiera sotto forma di int, quindi non vedo perché non usare quello: si elimina un sacco di codice inutile (alla fine non capisco neanche come mai si sia deciso di usare i valori della enum al posto di semplici interi).
dopo aver eliminato KeyCode potremo effettuare inserzioni nella coda in base al valore restituito dalla Keyboard; se non rimuovessimo KeyCode non potremmo effettuare l'inserzione perché dato l'int restituito dalla tastiera non sapremmo far corrispondere il valore della enum da inserire; la KEYCODEMAP non ci può aiutare perché funziona precisamente alcontrario: associa interi a valori enum, quindi ci permette di ritrovare l'intero partendo dal valore, a noi serve il contrario.
a questo punto secondo me la classe KeyboardImplementation diverrebbe talmente semplice da poter essere eliminata, ma questo si vedrà dopo.
il passo successivo sarebbe invece quello di modificare reactToInput in modo tale che non usi più le varie funzioni per testare la pressione dei tasti (mi accorgo ora che ce ne sta una per ogni tasto; e se avessimo deciso di usare nel gioco anche i tasti delle lettere e dei numeri che avreste fatto?? ) ma usi extractKey.
fatto questo bisogna vedere cosa verrà fuori in fatto di giocabilità e quale sarà la sensazione finale dell'utente per quanto riguarda la gestione dell'input; in caso bisognerà lavorare nuovamente sul fatto del "delay" dei tasti.
ditemi le vostre opinioni e organizziamoci su come procedere per questo refactoring che mi sembra abbastanza complesso.

[71104]

faccio una breve lista di TODOs, che mi sembra utile:
- interazione tra Keyboard e coda di Input: KeyboardImpl deve usare generateKey (che magari andrebbe pure rinominata )
- aggiornamento di reactToInput per l'uso di extractKey
- eliminazione del BitSet

ognuno di questi 3 punti non richiede test, richiede solo che si verifichi che i test attualmente presenti funzionino ancora.

[cionci]

Spiego quello che farei... Una cosa di cui non avete tenuto conto è che viene generato un evento di tasto premuto per ogni volta che viene fatto l'update dello stato della tastiera (non per ogni volta che il tasto viene premuto)...

Io avrei fatto un vettore di KeyEvent...ad ogni KeyEvent del vettore è associato un tasto (indicizzato tramite il valore delle costanti di Keyboard)...

Vanno modificati i valori dei KeyEvent di ogni tasto ogni volta che si chiama UpdateKeyboardState...

Il timeStamp associato ad ogni KeyEvent deve essere modificato solo se lo stato è diverso dal precedente...

In questo modo vengono gestiti automaticamente sia la pressione che il rilascio di un tasto...

E mi direte voi...e la coda dov'è ?

Basta realizzare una funzione getLastKeyPressed a cui si passa un timeStamp ed in base a quello si recupera l'ultimo evento generato (scorrendo il vettore di KeyEvent)...

Non c'è bisogno di alcuna estrazione o gestione della coda...

Per la gestione della pressione continua dei tasti (ad esempio per accelerare la gemma verso il basso) basta aggiungere is*KeyReleased e semplicemente si ritorna lo stato del tasto...

In questo modo si sarebbero anche potute scrivere le funzioni di tasto premuto attualmente usate dal codice...

[cionci]

Originariamente inviato da cionci

Basta realizzare una funzione getLastKeyPressed a cui si passa un timeStamp ed in base a quello si recupera l'ultimo evento generato (scorrendo il vettore di KeyEvent)...

Spiego meglio questo punto...Volendo sarebbe possibile realizzare una funzione getNextKeyPressed che ritorna il tasto premuto imemdiatamente successivo al timeStamp che gli si passa...
reactToInput potrebbe ciclare fino a quando getNextKeyPressed può ritornare un valore valido... In questo modo non si perde alcun tasto premuto...