View Full Version : Ripresa del progetto, primi passi
Ciao a tutti :)
Dovremmo essere riusciti a sistemare il repository.
Oggi inizio a rifattorizzare un po' di test visto che a mio parere e` una delle cose piu` urgenti ed importanti.
Se qualcuno volesse darmi una mano contattatemi su MSN. Se non avete il mio MSN mandatemi un PM sul forum :)
Il server SVN e' up:
svn:\\fcarucci.homeip.net\diamonds (l'intero repository)
svn:\\fcarucci.homeip.net\diamonds\trunk (il trunk)
Sto sistemando la build machine, quindi, per ora, occhio a chi rifattorizza, si assicuri che i test vadano tutti e ant faccia un build pulito, perche' qui volano le ditine.
adesso sto riuscendo finalmente a fare il checkout, ma non capisco perché è di una lentezza esasperante
Ecchime !!! ;)
Anch'io sono in fase lento checkout. :D
adesso sto riuscendo finalmente a fare il checkout, ma non capisco perché è di una lentezza esasperante
Hmmm se ricordo bene era lento anche 2 annetti fa.. Comunque una volta scaricato tutto i trasferimenti dovrebbero essere piccoli
Ho fatto il primo checkin :D
Dobbiamo trovare un modo per dire a JUnit di ignorare le classi helper per i test (esempio: EnvironmentTestCase). Penso che dovrebbe essere possibile creare un package chiamato it.diamonds.tests.helpers o qualcosa del genere.
Comunque il gioco non parte. Mi da degli errori riguardo il linking delle librerie LWJGL. Ricordo che bisognava settare il library path da qualche parte ma non ricordo dove :P
^TiGeRShArK^
19-01-2008, 13:30
Ecchime !!! ;)
Anch'io sono in fase lento checkout. :D
quoto :fagiano:
^TiGeRShArK^
19-01-2008, 13:31
Ho fatto il primo checkin :D
Dobbiamo trovare un modo per dire a JUnit di ignorare le classi helper per i test (esempio: EnvironmentTestCase). Penso che dovrebbe essere possibile creare un package chiamato it.diamonds.tests.helpers o qualcosa del genere.
Comunque il gioco non parte. Mi da degli errori riguardo il linking delle librerie LWJGL. Ricordo che bisognava settare il library path da qualche parte ma non ricordo dove :P
-Djava.library.path=<dir_dlls>
oppure le aggiungi alla variabile d'ambiente path...
^TiGeRShArK^
19-01-2008, 13:34
cazz..abituato a scaricare a mezzo mega al secondo mi viene da spararmi sulle palle :asd:
-Djava.library.path=<dir_dlls>
oppure le aggiungi alla variabile d'ambiente path...
Grazie, funziona perfettamente :)
Adesso non scarichi piu' a mezzo mega al secondo invece :D
Sto anche copiando, facendo, installando su quella macchina virtuale, quindi per tutto oggi il check out sara' lentino. Resistete.
^TiGeRShArK^
19-01-2008, 13:38
Adesso non scarichi piu' a mezzo mega al secondo invece :D
Sto anche copiando, facendo, installando su quella macchina virtuale, quindi per tutto oggi il check out sara' lentino. Resistete.
ah.. vmware? :p
che SO gli hai caricato?
public void setNoPivot()
{
pivot = null;
updatePulsingState();
}
private void updatePulsingState()
{
if (pivot == null)
{
return;
}
...
}
Interessante :P
public void setNoPivot()
{
pivot = null;
}
ah.. vmware? :p
che SO gli hai caricato?
Uso una beta di Virtual Server, ma non e' granche'. Penso che passero' a vmware, oppure aspetto Win2008. C'e' sopra un Win2003 che fa da build machine, un WinHomeServer, un Vista, ed un XP che mi fa da media encoder.
public void setNoPivot()
{
pivot = null;
updatePulsingState();
}
private void updatePulsingState()
{
if (pivot == null)
{
return;
}
...
}
Interessante :P
public void setNoPivot()
{
pivot = null;
}
Ma usiamo ancora Junit3? che ne dite di passare al 4?!?
Uso una beta di Virtual Server, ma non e' granche'. Penso che passero' a vmware, oppure aspetto Win2008. C'e' sopra un Win2003 che fa da build machine, un WinHomeServer, un Vista, ed un XP che mi fa da media encoder.
Ma perchè non ci metti pure un win98, un win95 e un win3.1 :sofico:
E non aggiungo altro percho so che non sei un amamte dell'OpenSource ;)
^TiGeRShArK^
19-01-2008, 14:04
public void setNoPivot()
{
pivot = null;
updatePulsingState();
}
private void updatePulsingState()
{
if (pivot == null)
{
return;
}
...
}
Interessante :P
public void setNoPivot()
{
pivot = null;
}
che figata :asd:
^TiGeRShArK^
19-01-2008, 14:06
Uso una beta di Virtual Server, ma non e' granche'. Penso che passero' a vmware, oppure aspetto Win2008. C'e' sopra un Win2003 che fa da build machine, un WinHomeServer, un Vista, ed un XP che mi fa da media encoder.
vmware non è male..
ma l'ho provato solo facendoci girare ubuntu e fedora..
non ho mai provato a caricarci SO microsoft, ma ad occhio penso che vada bene..
ah.. e sul PC in cui l'ho provato non avevo nemmeno le estensioni per la virtualizzazione (Vanderpool et similia).
^TiGeRShArK^
19-01-2008, 14:07
Ma usiamo ancora Junit3? che ne dite di passare al 4?!?
X me va anche bene :p
..ma sarà YAGNI? :stordita:
sistemiamo i test prima... NEssuno mi ha contattato su MSN ancora :D
X me va anche bene :p
..ma sarà YAGNI? :stordita:
Probabilmente no, ma impariamo ad usare le annotations ;)
EDIT: ehm... probabilmente sì, è YAGNI, è quello che volevo dire :stordita:
vmware non è male..
ma l'ho provato solo facendoci girare ubuntu e fedora..
non ho mai provato a caricarci SO microsoft, ma ad occhio penso che vada bene..
ah.. e sul PC in cui l'ho provato non avevo nemmeno le estensioni per la virtualizzazione (Vanderpool et similia).
Anche il mio server e' senza estensioni purtroppo, infatti le macchine virtuali non sono dei missili.
Ma al momento mi interessa solo tirare su la build machine il prima possibile. Tutto il resto e' YAGNI. Come JUnit4 :D
per ora sistemiamo i test con quello che abbiamo. Ti assicuro che c'e` da divertirsi per un po'
^TiGeRShArK^
19-01-2008, 14:15
sistemiamo i test prima... NEssuno mi ha contattato su MSN ancora :D
io ho completato il checkout ma sto uscendo :stordita:
ti contatto quando torno se ci sei :fiufiu:
Ho rimosso le Dynamite :)
Ehm... la Dynamite!?! non c'era mica ne FP ! :eek:
P.S.: immaginavo che fek mi avrebbe bocciato Junit4 ;)
Infatti so benissimo che è YAGNI, ma io c'ho provato lo steso :D
Ehm... la Dynamite!?! non c'era mica ne FP ! :eek:
P.S.: immaginavo che fek mi avrebbe bocciato Junit4 ;)
Infatti so benissimo che è YAGNI, ma io c'ho provato lo steso :D
Eh che ti devo dire c'erano nel codice... Nella FP avevamo il logging della action?
Una domanda. ANT non trova il javac.exe ma eclipse compila tranquillamente. Bisogna installare la Java SDK lo stesso?
A parte il checkstyle che si arrabbia, io riesco a compilare con ANT senza problemi, il che mi fa supporre che devi comunque installare la JDK.
EDIT: oppure è un problema di path ;)
Ho fatto update... checkstyle verde ;)
Ehm... si vede che non mi ricordo niente!
Come mai la cella non ha un field TopRow e un field BottomRow?
Non dovrebbe avre un solo campo row e caso mai un campo UpperRow e un campo LowerRow??
Di solito le celle hanno una sola posizione!
me lo sto chiedendo pure io...
OK se ricordo bene volevamo che una cella potesse essere piu` grande cosi` che una BigGem potesse essere contenuta in una cella
Bonfo, mi contatti in msn per favore?
me lo sto chiedendo pure io...
OK se ricordo bene volevamo che una cella potesse essere piu` grande cosi` che una BigGem potesse essere contenuta in una cella
Giusto!
EDIT: Sto uscendo.... conitnuo poi ;)
Ho rifattorizzato Cell rimuovendo la duplicazione di codice che aveva con Rectangle.
http://fcarucci.homeip.net:8080/
Che si dia inizio allo spezzettamento di ditine se rompete la build :)
Inizio io!!
http://www.inblog.it/wp-content/foto/fantozzi.jpg
Ora vedo di fare il checkout pure io e comincio a riprendere un po' di familiarità con il codice :)
Rifattorizzare un po' di test e` il modo migliore! Contattami! :P
Aggiornamento: svn e cruisecontrol up and running come al tempo.
Ora sto provando a configurare il nuovo CC che ha una marea di roba nuova; sembro un bimbo con i giocattoli di natale da provare.
edit:
nuovo indirizzo della buildmachine:
http:\\fcarucci.homeip.net:8080
^TiGeRShArK^
19-01-2008, 19:55
Una domanda. ANT non trova il javac.exe ma eclipse compila tranquillamente. Bisogna installare la Java SDK lo stesso?
eclipse usa il JDT per compilare, il suo compilatore incrementale, non usa javac.
Cmq direi che ti conviene installare la JDK altrimenti devi modificare la build di ant per usare il JDT.. cosa che con codice >= alla versione 5 fa un pò bestemmiare se per caso non usi l'ultima versione del JDT....
è cmq è sempre lavoro in + che potresti evitarti semplicemente installando la JDK :p
^TiGeRShArK^
19-01-2008, 19:57
http://fcarucci.homeip.net:8080/
Che si dia inizio allo spezzettamento di ditine se rompete la build :)
ehmm..
ma se ci facessimo un utente a testa in modo da non dover sempre ricordarci di scrivere il proprio nome durante il commit? :fagiano:
..e così non possiamo barare dando la colpa a jappy quando committiamo e rompiamo la build :asd:
ehmm..
ma se ci facessimo un utente a testa in modo da non dover sempre ricordarci di scrivere il proprio nome durante il commit? :fagiano:
..e così non possiamo barare dando la colpa a jappy quando committiamo e rompiamo la build :asd:
L'avevo gia` proposta e me l'ha bocciata :(
^TiGeRShArK^
19-01-2008, 20:03
L'avevo gia` proposta e me l'ha bocciata :(
perchè? :mbe:
questo non mi pare YAGNI dato che ci permetterebbe di lavorare + rapidamente e di evitare gli errori di distrazione durante il commit :stordita:
perchè? :mbe:
questo non mi pare YAGNI dato che ci permetterebbe di lavorare + rapidamente e di evitare gli errori di distrazione durante il commit :stordita:
Mi contatti su MSN? Ho un taskino per te :D
ehmm..
ma se ci facessimo un utente a testa in modo da non dover sempre ricordarci di scrivere il proprio nome durante il commit? :fagiano:
..e così non possiamo barare dando la colpa a jappy quando committiamo e rompiamo la build :asd:
Va bene dai, pero' l'idea di dare la colpa a Jappy quando si rompe la build mi affascina...
jappilas
19-01-2008, 20:35
Va bene dai, pero' l'idea di dare la colpa a Jappy quando si rompe la build mi affascina...faccio presente che jappy è ancora il mod di sezione e anche con qualche dito di meno può raddrizzare i torti comminando sospensioni a tempo indeterminato (idea che lo affascina) :O :D
mi metto in modalità lurking :D
uppo per avere un utente a testa :|
Va bene dai, scusate come non detto, questo me l'ero perso :D
qual è la mia password? (non mi dite "71104" -.-' )
ullallà com'è diventato veloce adesso il repository :)
ullallà com'è diventato veloce adesso il repository :)
Ci tieni ai ditini? :)
Ci tieni ai ditini? :) non ho capito... :|
non era mica un'ironia, è veloce per davvero :mc:
non ho capito... :|
non era mica un'ironia, è veloce per davvero :mc:
Prafo :D
Ora e' giu' perche' sto reboottando tutto.
Ecco i link piu' o meno definitivi alla build machine:
Dashboard (generale):
http://fcarucci.homeip.net:8080/dashboard
Dashbooard (Diamonds):
http://fcarucci.homeip.net:8080/dashboard/build/detail/diamonds
Vecchia build machine (per i nostalgici):
http://fcarucci.homeip.net:8080/cruisecontrol/buildresults/diamonds
Indirizzo svn:
svn://fcarucci.homeip.net/diamonds
Have fun!
(E rifattorizzate per cortesia)
uppo per avere un utente a testa :|
Anche io voglio il mio utente. La password di ora è brutta :D
Possiamo mettere un nuovo topic in standing con i nuovi dati di connessione etc?
Per utente e password contattatemi in msn.
a me la buildmachine risulta down...
a me la buildmachine risulta down...
La domenica mattina il server mi fa un reboot dopo i vari backup e devo ancora sistemare le procedure di partenza automatica della build machine. Un po' di pazienza, stanotte ho finito alle due :D
edit:
tutto su, enjoy
Questo mi risulta down
http://fcarucci.homeip.net:8080/dashboard
:confused:
Potete dare un occhiata a LayerManager, specialmente ai due tipi di layer e vedere se servono veramente? Io ho cercato bene all'interno del codice e a parte complicare l'interfaccia e i test questa distinzione non serve.
Ho già sistemato tutto qui in locale ma prima di fare un commit che distrugga il gioco vorrei una conferma :D
Altro task da prendere in considerazione sarebbe l'aggiornamento delle lwjgl all'ultima versione. In questo momento funzionano bene su windows ma su linux serve qualche comando da console. Su leopard dove sono ora invece il gioco non ne vuole sapere di partire :(
Poi che vogliamo fare con il log? Continuiamo oppure lo eliminiamo?
Questo mi risulta down
http://fcarucci.homeip.net:8080/dashboard
:confused:
Tutto giu' per manutenzioni varie al server fino a oggi pomeriggio.
Stiamo lavorando (e neppure mangiando) per voi :D
Edit: di nuovo su
Potete dare un occhiata a LayerManager, specialmente ai due tipi di layer e vedere se servono veramente? Io ho cercato bene all'interno del codice e a parte complicare l'interfaccia e i test questa distinzione non serve.
Ho già sistemato tutto qui in locale ma prima di fare un commit che distrugga il gioco vorrei una conferma :D
Altro task da prendere in considerazione sarebbe l'aggiornamento delle lwjgl all'ultima versione. In questo momento funzionano bene su windows ma su linux serve qualche comando da console. Su leopard dove sono ora invece il gioco non ne vuole sapere di partire :(
Poi che vogliamo fare con il log? Continuiamo oppure lo eliminiamo?
Se i due layer non sono usati vanno eliminati.
Aggiorna pure alla nuova versione di lwgl.
Per quanto riguarda il log, per me e' una Storia, quindi va tenuto. Ma e' sotto processo e attenta valutazione.
^TiGeRShArK^
20-01-2008, 13:43
..tra una mezz'oretta dovrei essere operativo...
Se qualche anima pia mi manda user e pass via PVT.. :fiufiu:
..tra una mezz'oretta dovrei essere operativo...
Se qualche anima pia mi manda user e pass via PVT.. :fiufiu:
Dammi tu user, pass e email.
Ora che state rimettendo le mani nel codice vi ricordi qualche regoletta, che non ammette deroga in alcun caso:
- Prima si scrive il test e poi il codice relativo.
- Il Singleton non esiste. Senza Se e senza Ma :D
- Il Singleton non esiste. Non voglio sentire "Si' ma qui semplificherebbe questo o quello". Non esiste.
Ah, il Singleton non esiste, quindi dimenticatevelo per il bene delle ditine.
Per me i log son da togliere ma fran si e` affezionato :P:P
Per me i log son da togliere ma fran si e` affezionato :P:P
A scanso di equivoci, il Singleton non esiste :)
Magari possiamo fare un Doubleton per la griglia ghgh :o
Magari possiamo fare un Doubleton per la griglia ghgh :o
:rotfl: :rotfl:
Ma se è stata eliminata Dynamite perchè NullDynamite è ancora lì?
Stasera mi metto è la elimino ;)
Bella l'idea della Region, però cambierei il costruttore con width & height. In ogni caso mancano un piao di test sul costruttore... anche quelli a seguire stanotte ;)
Stato della buildmachine:
- Up and running: http://fcarucci.homeip.net:8080/cruisecontrol/
- Ho tolto la generazione degli eseguibili dalla continuos integration, cosi' impiega solo 40 secondi per compilare e testare. Alla fine impacchetta tutti i sorgenti in uno zip prelevabile dagli artifatti.
- Ho aggiunto il progetto diamonds-nightly che lancia una build completa e genera gli eseguibili ogni giorno a mezzanotte. Gli eseguibili sono prelevabili dagli artifatti.
- Potete forzare una build con l'apposito tasto.
- Ho disabilitato l'utente pubblico; per il commit dovete mandarmi un PM con login/password e email. Senza email non vi abilito :)
- A chi rompe una build arrivera' una mail che e' spedita anche a me. Inoltre ricevo gli RSS sul cellulare in qualunque parte del mondo sono, quindi posso spezzarvi le ditine ovunque sia.
- Non riesco a far funzionare la Dashboard di CruiseControl purtroppo. Se qualcuno ha esperienza con questo mistero insondabile della fede mi contatti.
- Il Singleton non esiste.
Non era il cucchiaio quello? :D
- Ho aggiunto il progetto diamonds-nightly che lancia una build completa e genera gli eseguibili ogni giorno a mezzanotte. Gli eseguibili sono prelevabili dagli artifatti.
- Potete forzare una build con l'apposito tasto.
Ovvero... non dovrò più frantumarvi i cosiddetti per avere build da testare. Ottimo :oink:
- Ho disabilitato l'utente pubblico; per il commit dovete mandarmi un PM con login/password e email. Senza email non vi abilito :)
Hai PM :)
- A chi rompe una build arrivera' una mail che e' spedita anche a me. Inoltre ricevo gli RSS sul cellulare in qualunque parte del mondo sono, quindi posso spezzarvi le ditine ovunque sia.
Eccellente :)
ma perchè se provo a lanciare ant da eclipse non mi rileva nessun target?:mbe:
e se lo lancio da shell ottengo questo:
[junit] Testcase: testAllTexturesLoadedBeforeStartPlaying(it.diamonds.tests.TestGameLoop): FAILED
[junit] expected:<45> but was:<44>
[junit] junit.framework.AssertionFailedError: expected:<45> but was:<44>
:mbe:
sto da linux:|
- A chi rompe una build arrivera' una mail che e' spedita anche a me. Inoltre ricevo gli RSS sul cellulare in qualunque parte del mondo sono, quindi posso spezzarvi le ditine ovunque sia. ROTFL :rotfl:
Piccolo refactoring in Region.
Il metodo
resizeToContain(Cell cell)
si è trasformato in
resizeToContain(Region region)
Ora mi chiedo quanto serva il concetto di Cell?
ma perchè se provo a lanciare ant da eclipse non mi rileva nessun target?:mbe:
e se lo lancio da shell ottengo questo:
[junit] Testcase: testAllTexturesLoadedBeforeStartPlaying(it.diamonds.tests.TestGameLoop): FAILED
[junit] expected:<45> but was:<44>
[junit] junit.framework.AssertionFailedError: expected:<45> but was:<44>
:mbe:
sto da linux:|
Ringrazia il singleton pattern per questa cosa :\
Piccolo refactoring in Region.
Il metodo
resizeToContain(Cell cell)
si è trasformato in
resizeToContain(Region region)
Ora mi chiedo quanto serva il concetto di Cell?
Domanda interessante... Non saprei al momento ma una cell e` semplicemente una region 1x1 :P
ma perchè se provo a lanciare ant da eclipse non mi rileva nessun target?:mbe:
e se lo lancio da shell ottengo questo:
[junit] Testcase: testAllTexturesLoadedBeforeStartPlaying(it.diamonds.tests.TestGameLoop): FAILED
[junit] expected:<45> but was:<44>
[junit] junit.framework.AssertionFailedError: expected:<45> but was:<44>
:mbe:
sto da linux:|
Anche su osx da lo stesso problema ma non ho ancora capito a cosa sia dovuto. Se poi provi a debuggare il test e guardi in enviroment l'array con le texture alcuni sono dei null quindi carica solo alcune texture.
ciao ;)
Domanda interessante... Non saprei al momento ma una cell e` semplicemente una region 1x1 :P
E non solo, diciamo che le celle sono dei "singleton" ( AIUTO LE DITINE!!! :D ).
Ovvero ha senso che esistino due celle con stessa row e stessa column?!?
Per essere chiaro, ogni griglia ha una sola cella (2, 6) e una sola cella (5, 2). :O
Con questa perla di sagezza mi avvio al letto ;)
Ci sono ancora dei resti di Dynamite:
CheckDynamiteState
Ho provato a metterci mano ma la sequenza degli states non me la ricordo e non vorrei fare macelli!
Piccolo refactoring in Region.
Il metodo
resizeToContain(Cell cell)
si è trasformato in
resizeToContain(Region region)
Ora mi chiedo quanto serva il concetto di Cell?
Se non mi avessi fatto revertare tutto col tuo commit ti facevo vedere io a che serve Cell :D
Colpa mia, dovevo fare il commit prima. Maledetto F2 che mi fa perdere le buone abitudini (sono costretto a fare un commit non meno di ogni due o tre giorni...).
Ci sono ancora dei resti di Dynamite:
CheckDynamiteState
Ho provato a metterci mano ma la sequenza degli states non me la ricordo e non vorrei fare macelli!
Faccio io... Dobbiamo assolutamente scrivere una mappa degli stati. E` indecifrabile secondo me al momento :D
Faccio io... Dobbiamo assolutamente scrivere una mappa degli stati. E` indecifrabile secondo me al momento :D
sono d'accordo:D
ma perchè se provo a lanciare ant da eclipse non mi rileva nessun target?:mbe:
e se lo lancio da shell ottengo questo:
[junit] Testcase: testAllTexturesLoadedBeforeStartPlaying(it.diamonds.tests.TestGameLoop): FAILED
[junit] expected:<45> but was:<44>
[junit] junit.framework.AssertionFailedError: expected:<45> but was:<44>
:mbe:
sto da linux:|
mi auto quoto, dopo i refactoring il test riporta:
[junit] Testcase: testAllTexturesLoadedBeforeStartPlaying(it.diamonds.tests.TestGameLoop): FAILED
[junit] expected:<44> but was:<43>
[junit] junit.framework.AssertionFailedError: expected:<44> but was:<43>
sono andato a vedere in GameLoop, e contando le texture nell'array TEXTURES_TO_PRELOAD ne ho contato effettivamente 43, da dove viene la 44sima che viene caricata evidentemente su windows?:mbe:
Sono tentato di correggere l'errore del test sul numero delle texture e fare il commit per vedere cosa succede sulla build machine di fek. :D
Sono tentato di correggere l'errore del test sul numero delle texture e fare il commit per vedere cosa succede sulla build machine di fek. :D
si si si, vediamo che succede:D:D:D:D
con l'aiuto di Ufo13, ho potuto verificare che in windows vengono caricate 2 main.jpg, in particolare:
1. gfx\common\main.jpg
2. gfx/common/main.jpg
adesso bisogna capire da dove viene la prima :mbe:
Sono tentato di correggere l'errore del test sul numero delle texture e fare il commit per vedere cosa succede sulla build machine di fek. :D
Se mi esplode la build machine io dormo nella stanza vicino, quindi occhio :D
cdimauro
21-01-2008, 07:50
ma perchè se provo a lanciare ant da eclipse non mi rileva nessun target?:mbe:
e se lo lancio da shell ottengo questo:
[junit] Testcase: testAllTexturesLoadedBeforeStartPlaying(it.diamonds.tests.TestGameLoop): FAILED
[junit] expected:<45> but was:<44>
[junit] junit.framework.AssertionFailedError: expected:<45> but was:<44>
:mbe:
sto da linux:|
Ringrazia il singleton pattern per questa cosa :\
Anche su osx da lo stesso problema ma non ho ancora capito a cosa sia dovuto. Se poi provi a debuggare il test e guardi in enviroment l'array con le texture alcuni sono dei null quindi carica solo alcune texture.
ciao ;)
mi auto quoto, dopo i refactoring il test riporta:
[junit] Testcase: testAllTexturesLoadedBeforeStartPlaying(it.diamonds.tests.TestGameLoop): FAILED
[junit] expected:<44> but was:<43>
[junit] junit.framework.AssertionFailedError: expected:<44> but was:<43>
sono andato a vedere in GameLoop, e contando le texture nell'array TEXTURES_TO_PRELOAD ne ho contato effettivamente 43, da dove viene la 44sima che viene caricata evidentemente su windows?:mbe:
con l'aiuto di Ufo13, ho potuto verificare che in windows vengono caricate 2 main.jpg, in particolare:
1. gfx\common\main.jpg
2. gfx/common/main.jpg
adesso bisogna capire da dove viene la prima :mbe:
Lo riconosco: questo è codice mio.
Il problema è dovuto al fatto che il caricamento delle texture fa uso di una cache per le texture.
Il caching viene effettuato sulla base del nome della texture da caricare, per cui è evidente che le due main.jpg sono diverse, poiché il path è oggettivamente diverso ("\" != "/").
Windows non fa differenza fra "\" e "/", ma Linux dovrebbe farne, per cui non mi spiego questo comportamento. Voglio dire: su Linux mi sarei aspettato un'eccezione o qualcosa di simile.
Al momento ci sono due soluzioni per risolvere il problema:
- spezzare le ditine a chi si è divertito a usare "\" al posto di "/";
- AGGIUNGERE UN TEST nel codice di caching delle texture che controlli che nel path non siano presenti "\", pena il sollevamento di un'opportuna eccezione;
- sostituire automaticamente tutti i "\" in "/" dentro il codice di caching.
Avevo detto due però, e ne son venute fuori tre. :D
Io sono per la 2). Anche perché permette di risalire alla causa del problema, ma soprattutto all'autore (e quindi di applicare anche il punto 1) :asd: ).
x Federico: perché dici che la colpa è del singleton pattern? :|
con l'aiuto di Ufo13, ho potuto verificare che in windows vengono caricate 2 main.jpg, in particolare:
1. gfx\common\main.jpg
2. gfx/common/main.jpg
adesso bisogna capire da dove viene la prima :mbe:
Aha quindi avevo indovinato erano i separator diversi... Immagino che da qualche parte il separator con gli / siano stati hardcoded. Un search per la stringa "jpg" nel codice potrebbe aiutare :P
comunque non e` la prima quella "sbagliata" ma la seconda :)
Anche io sono per la 2. Prima test e poi fix.
x Federico: perché dici che la colpa è del singleton pattern? :|
Non so, pensavo che la cache delle texture fosse statica... Magari non e` cosi` ma quella hashmap mi sembra non sia costante e non venga ricreata tra un test e l'altro quindi automaticamente non e` facilmente testabile.
La mia comunque era una battuta :P secondo me il vero problema e` il test che invece di avere un 44 dovrebbe usare il numero di entry presenti nell'array di texture da caricare...
In ogni caso secondo me sarebbe cosa buona e giusta avere un file contenente gli asset da precaricare per il gioco e deserializzarlo. Per il testing potremmo avere un altro file con poche entry altrimenti tutte le volte che aggiungiamo qualcosa i test saltano :).
cdimauro
21-01-2008, 08:20
Aha quindi avevo indovinato erano i separator diversi...
Esatto. :)
Immagino che da qualche parte il separator con gli / siano stati hardcoded.
Ricordo che Danilo eliminò tutti i riferimenti al "Separator" dal codice, quindi dovremmo avere sempre dei path "hardcoded". L'importante è che venga sempre utilizzato lo stesso separatore, per quanto ho scritto prima.
Un search per la stringa "jpg" nel codice potrebbe aiutare :P
Penso di sì, ma sarebbe preferibile arrivarci dopo aver introdotto il test di cui parlavo prima, come suggerisce anche Vicius (di cui, al solito, non ricordo mai il vero nome. :muro: ).
comunque non e` la prima quella "sbagliata" ma la seconda :)
Perché? Mi pare avessimo adottato lo slash per i path, e non il backslash. :|
Perché? Mi pare avessimo adottato lo slash per i path, e non il backslash. :|
Hai ragione pensavo che stessimo ancora usando il separator diverso per piattaforma e quindi su windows / sarebbe quello sbagliato :D
Una volta scritto il test e fixato la build non e` che qualcuno si prende la briga di rendere il testing di questa parte un po' piu` efficace? :P
cdimauro
21-01-2008, 08:29
Non so, pensavo che la cache delle texture fosse statica...
Dovrebbe essere legata all'istanza (unica, questa sì) dell'environment. Purtroppo è passato troppo tempo e non ho il codice sotto mano, per cui non posso andare a controllare. :(
Magari non e` cosi` ma quella hashmap mi sembra non sia costante e non venga ricreata tra un test e l'altro quindi automaticamente non e` facilmente testabile.
Uno dei problemi che ho avuto quando ho eseguito la rifattorizzazione del codice introducendo Environment & co. è che i test non eseguivano un setUp() "standard". Cioé, non veniva creata la variabile Environment e i suoi "subsystem" (video, audio, input, ecc.), ma questi ultimi a volte venivano creati "alla bisogna".
Ricordo, però, di avere estensivamente controllato codice e test, e di aver modificato una montagna di test che funzionavano così.
Ora, però, non ricordo bene.
La mia comunque era una battuta :P secondo me il vero problema e` il test che invece di avere un 44 dovrebbe usare il numero di entry presenti nell'array di texture da caricare...
Quindi dovremmo "pubblicare" quest'array, in modo che sia "raggiungibile" anche dal relativo test. Certo, sarebbe una buona soluzione al problema.
In ogni caso secondo me sarebbe cosa buona e giusta avere un file contenente gli asset da precaricare per il gioco e deserializzarlo. Per il testing potremmo avere un altro file con poche entry altrimenti tutte le volte che aggiungiamo qualcosa i test saltano :).
Però quel test è stato realizzato proprio per controllare che venissero caricate TUTTE le texture. Anzi, mi pare fosse proprio uno dei task svolti.
Comunque Diamonds è in fase di ristrutturazione / redesign/ rifattorizzazione, per cui si può anche eliminare o aggiustare tranquillamente. :)
cdimauro
21-01-2008, 08:34
Hai ragione pensavo che stessimo ancora usando il separator diverso per piattaforma e quindi su windows / sarebbe quello sbagliato :D
No no. In principio (:asd:) IO m'ero passato il tempo a introdurre l'uso della variabile Separator per tutti i path. Poi Danilo (bestemmiando... e mi risulta che continua a farlo :asd:) s'è ri-passato il tempo per eliminarli tutti e lasciare i path "hard coded".
Una volta scritto il test e fixato la build non e` che qualcuno si prende la briga di rendere il testing di questa parte un po' piu` efficace? :P
Vediamo se gli altri sono d'accordo con la soluzione che hai proposto. :)
Io sono per la 2). Anche perché permette di risalire alla causa del problema, ma soprattutto all'autore (e quindi di applicare anche il punto 1) :asd: ).
Mi piace, soprattutto il punto 1). Abbiamo anche un volontario. Tu :)
[...] come suggerisce anche Vicius (di cui, al solito, non ricordo mai il vero nome. :muro: ).
Mirco :)
Il problema penso sia dovuto a come è scritta la loadTextureFromFile nel Mock.
private void loadTextureFromFile(String fileName) throws RuntimeException
{
if(fileName.equals("this_texture_doesnt_exist.png"))
{
throw new RuntimeException(
"this_texture_doesnt_exist.png file not found");
}
else if(fileName.equals("textureTest.png"))
{
throw new RuntimeException(
"Not power of two dimensione for textureTest.png");
}
else
{
width = 64;
height = 64;
loaded = true;
checkForSpecialCases(fileName);
}
}
Prima di tutto lancia una RuntimeException che a differenza delle altre può passare inosservata. Inoltre viene lanciata soltanto quando la funzione viene chiamata per caricare un file mistico di nome this_texture_doesnt_exist.png
Ora non ci resta che aspettare che i due pricipali autori del codice, perché so chi è stato, sistemino tutto :D
Puoi sistemarlo tu per favore?
Puoi sistemarlo tu per favore?
Proverò questa sera se avrò un po' di tempo.
OK se non puoi avverti che altrimenti faccio io :)
^TiGeRShArK^
21-01-2008, 13:34
No no. In principio (:asd:) IO m'ero passato il tempo a introdurre l'uso della variabile Separator per tutti i path. Poi Danilo (bestemmiando... e mi risulta che continua a farlo :asd:) s'è ri-passato il tempo per eliminarli tutti e lasciare i path "hard coded".
confermo :asd:
il SEPARATOR che c'era mi ricorda tanto la costante DOT che qualche genio aveva introdotto nella codebase nel mio vecchio lavoro..
in effetti non si sa mai cambia il punto in qualche versione di java è sempre meglio usare la costante DOT al posto di "." :asd:
OK se non puoi avverti che altrimenti faccio io :)
Un aiutino non guasterebbe. Qui funziona tutto e francamente faccio un po' fatica a debuggare senza messaggi di errore :(
junit.framework.AssertionFailedError: expected:<43> but was:<44>
at it.diamonds.tests.TestGameLoop.testAllTexturesLoadedBeforeStartPlaying(TestGameLoop.java:238)
Vi tengo d'occhio :incazzed:
junit.framework.AssertionFailedError: expected:<43> but was:<44>
at it.diamonds.tests.TestGameLoop.testAllTexturesLoadedBeforeStartPlaying(TestGameLoop.java:238)
Vi tengo d'occhio :incazzed:
Il test è giusto! È la tua build machine che non sa contare :Prrr:
da me il test e` rosso. Ora provo a fixarlo
La build e' rotta da un'ora. Non ci siamo.
La festa e' finita, non si programma piu' alla spera in Dio, si lavora con procedure ben stabilite.
Quindi, se si rompe la build, la soluzione non e' fare decine di commit cercando di sistemarla come e' avvenuto oggi pomeriggio.
Se la build e' rotta per piu' di cinque minuti, la soluzione e' fare il revert immediato alla prima revisione pulita. E poi sistemare il problema in locale.
Dunque, ora, chi ha accesso a svn faccia il revert immediatamente e poi qualcuno sistemi il problema in locale. Voglio vedere la build verde entro cinque minuti.
Fixata. Ho rimosso tutti i posti dove File.separator veniva utilizzato. Suggerisco di rivedere pesantemente il texture manager. :)
Fixata. Ho rimosso tutti i posti dove File.separator veniva utilizzato. Suggerisco di rivedere pesantemente il texture manager. :)
Ma non erano già stati tutti rimossi? :confused:
cdimauro
21-01-2008, 17:47
Io ricordavo così.
E ricordo pure che questi problemi li abbiamo, sì, avuti, ma parecchio tempo fa, ed erano stati risolti del tutto (le ultime che abbiamo avuto erano ben altre rogne, legate al discorso del logging).
Mah. Non riesco proprio a capire. :|
Ma non erano già stati tutti rimossi? :confused:
no, la build era rossa, non era la build machine a sbagliarsi :)
Io ricordavo così.
E ricordo pure che questi problemi li abbiamo, sì, avuti, ma parecchio tempo fa, ed erano stati risolti del tutto (le ultime che abbiamo avuto erano ben altre rogne, legate al discorso del logging).
Mah. Non riesco proprio a capire. :|
Erano stati rimossi quasi ovunque ma in un paio di posti c'erano ancora. Erano in qualche test
no, la build era rossa, non era la build machine a sbagliarsi :)
Mi riferivo dei separator. Pensavo fossero stati eliminati tutti più di due anni fa visto che come ha detto cesare questi problemi verso la fine del progetto non ne avevamo.
Comunque questo spiega come mai grep riusciva a trovare solo un "main.jpg" :muro:
cdimauro
21-01-2008, 17:56
Erano stati rimossi quasi ovunque ma in un paio di posti c'erano ancora. Erano in qualche test
Molto strano, perché un comportamento così "ballerino" avrebbe dovuto flagellarci un giorno sì e l'altro pure, ma onestamente non ricordo di problemi come questi da parecchio tempo, appunto (quando ho introdotto il caching delle texture).
Comunque appena posso rivedo il codice e il fix che hai applicato.
cdimauro
21-01-2008, 17:59
Mi riferivo dei separator. Pensavo fossero stati eliminati tutti più di due anni fa visto che come ha detto cesare questi problemi verso la fine del progetto non ne avevamo.
Esattamente. Ti assicuro che avevamo ben altro a cui pensare... :muro:
Comunque questo spiega come mai grep riusciva a trovare solo un "main.jpg" :muro:
Già: non era lì il problema.
Anche se ricordo che abbiamo avuto un main.png e un main.jpg (qualcuno conferma anche questo o la mia memoria è andata definitivamente a farsi friggere? :| ).
redcloud
21-01-2008, 21:20
Innanzitutto voglio ringraziare tutto quelli che hanno voluto riprendere il progetto ;)
In secundis, fresco di sban, sparo subito 2 cavolate:
1) Ho letto di sfuggita su problemi riguardo ai "/" e "\"... Ma non è meglio lasciare scegliere a JAva usando System.getProperty("file.separator") e "line.separator" ??
2) Non sarebbe suddividere meglio i package? Strutturando gli stessi secondo il modello MVC? Fare una suddivisione base tipo it.diamonds.entity (M), it.diamonds.gui (V) , it.diamonds.control (C)...
E NON ROMPETE LE BUILDS!!! :D
redcloud
21-01-2008, 21:56
Altra domanda... perchè è stato scelto un numero pari di colonne?
^TiGeRShArK^
21-01-2008, 21:58
Ma non erano già stati tutti rimossi? :confused:
..si li avevo rimossi io :confused:
..avevo proprio eliminato la variabile... e compilava quindi non c'erano altre occorrenze...
non mi dite che qualcuno l'ha rimessa? :mad:
^TiGeRShArK^
21-01-2008, 22:00
Innanzitutto voglio ringraziare tutto quelli che hanno voluto riprendere il progetto ;)
In secundis, fresco di sban, sparo subito 2 cavolate:
1) Ho letto di sfuggita su problemi riguardo ai "/" e "\"... Ma non è meglio lasciare scegliere a JAva usando System.getProperty("file.separator") e "line.separator" ??
..per l'amor di dioooo... NOOOOO!!!
si usa "/" che va bene sia per windows che per linux che per mac che per HP-UX, palmari e cellularii! Cazzarola!!! :Prrr:
2) Non sarebbe suddividere meglio i package? Strutturando gli stessi secondo il modello MVC? Fare una suddivisione base tipo it.diamonds.entity (M), it.diamonds.gui (V) , it.diamonds.control (C)...
...perchè? :fagiano:
E NON ROMPETE LE BUILDS!!! :D
questo è sicuro .. altrimenti si rompono anche le ditine :asd:
^TiGeRShArK^
21-01-2008, 22:04
...ma i commenti del commit non andavano fatti in inglese? :fiufiu:
...ma i commenti del commit non andavano fatti in inglese? :fiufiu: è quello che mi sto chiedendo anche io in questi giorni visto che lurkando i commenti che fate li vedo metà in italiano e metà in inglese :D
comunque mi pare che fossero sempre andati bene in italiano, e che invece fossimo passati all'inglese solo su SourceForge. vedo che solo tu e qualcun altro avete commentato in inglese, ma mi sa che vi siete confusi coi commenti del codice :D
quelli si, andavano fatti rigorosamente in inglese come tutto il resto del codice.
^TiGeRShArK^
21-01-2008, 22:13
è quello che mi sto chiedendo anche io in questi giorni visto che lurkando i commenti che fate li vedo metà in italiano e metà in inglese :D
comunque mi pare che fossero sempre andati bene in italiano, e che invece fossimo passati all'inglese solo su SourceForge. vedo che solo tu hai commentato in inglese, ma mi sa che ti confondi coi commenti del codice :D
quelli si, andavano fatti rigorosamente in inglese come tutto il resto del codice.
anche federico commenta in inglese :O
..e anche fek.. a parte qualche commento che gli esce di cuore in italiano :asd:
redcloud
21-01-2008, 22:16
..per l'amor di dioooo... NOOOOO!!!
si usa "/" che va bene sia per windows che per linux che per mac che per HP-UX, palmari e cellularii! Cazzarola!!! :Prrr:
Ehehe forte String DOT = "." lol :D
...perchè? :fagiano:
Beh perchè migliora sicuramente la leggibilità. Così come è ora non si capisce dove finisce la grafica e dove inizia la gestione logica.
Poi i test non andrebbero meglio al di fuori del package principale?
^TiGeRShArK^
21-01-2008, 22:21
Ehehe forte String DOT = "." lol :D
Beh perchè migliora sicuramente la leggibilità. Così come è ora non si capisce dove finisce la grafica e dove inizia la gestione logica.
Poi i test non andrebbero meglio al di fuori del package principale?
i test secondo me andrebbero messi in una directory a parte test/src e riorganizzati in modo da poter escludere facilmente i test helper sia da eclipse che da ant.
..Per quanto riguarda l'MVC.. boh... :confused:
redcloud
21-01-2008, 22:32
i test secondo me andrebbero messi in una directory a parte test/src e riorganizzati in modo da poter escludere facilmente i test helper sia da eclipse che da ant.
Esatto!
..Per quanto riguarda l'MVC.. boh... :confused:
Boh, era solo una proposta.
- Test: assolutamente favorevole a spostarli in una directory test\src e tiger si e' offerto volontario :)
- MVC, hmmm, sospendo il giudizio: al momento voglio veder ben separato il codice di rendering dalla logica del gioco e Fede si e' offerto volontario.
- Commenti e commit tutti in inglese. Se vedete un commento in italiano traducetelo, anzi togliete i commenti a parte i TODO :)
- Togliete tutto il codice del logging che andra' riscritto: jappilas si e' offerto volontario.
- Adoro i volontari.
^TiGeRShArK^
21-01-2008, 22:40
- Test: assolutamente favorevole a spostarli in una directory test\src e tiger si e' offerto volontario :)
- MVC, hmmm, sospendo il giudizio: al momento voglio veder ben separato il codice di rendering dalla logica del gioco e Fede si e' offerto volontario.
- Commenti e commit tutti in inglese. Se vedete un commento in italiano traducetelo, anzi togliete i commenti a parte i TODO :)
- Togliete tutto il codice del logging che andra' riscritto: jappilas si e' offerto volontario.
- Adoro i volontari.
2376 20/01/08 21.42 Fran + rimossa class Dynamite
:O
:asd:
...quando li sposto i test?
succede un casino secondo me se qualcuno committa nel frattempo :cry:
:O
:asd:
...quando li sposto i test?
succede un casino secondo me se qualcuno committa nel frattempo :cry:
Quel commit mi e' scappato :D
locka tutto il repository e spostali pure adesso.
^TiGeRShArK^
21-01-2008, 23:33
..ma tutti io li becco?!?!? :muro:
Working copy not locked; this is probably a bug, please report
svn: Directory 'I:\Workspace\Eclipse\Diamonds\tests\.svn' containing working copy admin area is missing
:muro::muro::muro:
^TiGeRShArK^
21-01-2008, 23:42
..un paio di calci rotanti nel culo ed è andato a posto....:mad:
..cmq ora i tests sono spostati in un altra directory e la build non esplode perchè ho riconfigurato tutto il build.xml.
Domani finisco lo spostamento, se mi dite esattamente quali sono i test da non eseguire e completo la configurazione del build.xml.
Gute Nacht :O
P.S. Ma come cazz si lockava con subclipse????
praticametne ho dovuto fare tutto tra un commit e l'altro di federico :muro:
dove scappi, la build e' rotta
^TiGeRShArK^
21-01-2008, 23:52
dove scappi, la build e' rotta
l'ho sistemata :asd:
.. o almeno credo...
com'è che non sta + rebuildando? :mbe:
^TiGeRShArK^
21-01-2008, 23:56
l'ho sistemata :asd:
.. o almeno credo...
com'è che non sta + rebuildando? :mbe:
come non detto..
ma quali target di ant lancia 'sta build? :muro:
io ho lanciato tutti quelli che escono con ant -p e vanno.. :mbe:
vedo se trovo quello sbagliato...
come non detto..
ma quali target di ant lancia 'sta build? :muro:
io ho lanciato tutti quelli che escono con ant -p e vanno.. :mbe:
vedo se trovo quello sbagliato...
Lancia test-dist-source.
Builda ogni 5 minuti ma puoi forzare una build da remoto via web.
Se non riesci a sistemare entro breve, reverta tutto e riprovi domani.
^TiGeRShArK^
22-01-2008, 00:04
Lancia test-dist-source.
Builda ogni 5 minuti ma puoi forzare una build da remoto via web.
Se non riesci a sistemare entro breve, reverta tutto e riprovi domani.
quello mi va bene in locale.. :mbe:
sembra che fallisca il release ma in locale mi da il verde anche quello :mbe:
EDIT: che hai committato tu invece che hai sballato la build ancora di +? :D
Sistemato io.
Era impazzito svn che pretendeva di fare il merge di build.xml
Mi e' gia' successo.
^TiGeRShArK^
22-01-2008, 00:09
Sistemato io.
Era impazzito svn che pretendeva di fare il merge di build.xml
Mi e' gia' successo.
..a me in locale va tutto..
...e infatti la build ora è VERDE :mbe:
...ma è normale? :fagiano:
..o la build machine lo fa apposta solo per farmi sclerare? :muro:
EDIT: ah.. hai sistemato tutto il build... capito :p
..acnhe se mi sfugge come ha fatto a fare il merge dato che quello di solito lo fa in update e non in commit :mbe:
Per qualche motivo al momento dell'update della build machine ha deciso che doveva fare il merge :|
Ho cancellato build.xml, update, ed e' ripartito tutto.
^TiGeRShArK^
22-01-2008, 08:02
Per qualche motivo al momento dell'update della build machine ha deciso che doveva fare il merge :|
Ho cancellato build.xml, update, ed e' ripartito tutto.
ah..ecco..capito...
In effetti era il minimo dopo aver beccato il bug di svn, dopo non aver trovato come lockare il repository da subclipse e dopo che federico mi faceva un commit al minuto...:asd:
Ci sono molte classi che nel sorgente hanno delle createForTesting() e fanno riferimento a delle classi che ora sono in tests/src. Non sarebbe meglio spostare queste funzioni in altra sede? Come è ora è impossibile creare degli eseguibili con ant dist senza includere tutti i test e junit. :(
Ci sono molte classi che nel sorgente hanno delle createForTesting() e fanno riferimento a delle classi che ora sono in tests/src. Non sarebbe meglio spostare queste funzioni in altra sede? Come è ora è impossibile creare degli eseguibili con ant dist senza includere tutti i test e junit. :(
Preferirei tenere createFortTesting() dove sono ma cercare di scriverle senza riferimenti cio' che e' in tests/src. Pensi sia possibile?
Ma perche' non esiste la compilazione condizionale in java :(
(Perche' e' cosa buona e giusta)
redcloud
22-01-2008, 10:03
Altra domanda... perchè è stato scelto un numero pari di colonne?
Up :help:
ci sono anche io.
In pausa pranzo mi scarico il repository, e poi incomincio a dare un occhiata in giro per il refactoring
Up :help:
Dovevamo metterne uno dispari? Perché? :confused:
Preferirei tenere createFortTesting() dove sono ma cercare di scriverle senza riferimenti cio' che e' in tests/src. Pensi sia possibile?
Ma perche' non esiste la compilazione condizionale in java :(
(Perche' e' cosa buona e giusta)
Purtroppo sono usate praticamente solo per creare i mock e poi usarli nei posti giusti dei vari costruttori. Non mi piace molto come idea ma potremmo ricorrere ad una factory in tests/src che si preoccupi di fare solo queste cose.
Purtroppo sono usate praticamente solo per creare i mock e poi usarli nei posti giusti dei vari costruttori. Non mi piace molto come idea ma potremmo ricorrere ad una factory in tests/src che si preoccupi di fare solo queste cose.
Hmmm capisco. Valuta tu la cosa migliore. L'idea di avere questo coupling fra code base e test non mi piace.
^TiGeRShArK^
22-01-2008, 12:02
Ci sono molte classi che nel sorgente hanno delle createForTesting() e fanno riferimento a delle classi che ora sono in tests/src. Non sarebbe meglio spostare queste funzioni in altra sede? Come è ora è impossibile creare degli eseguibili con ant dist senza includere tutti i test e junit. :(
...perchè? :mbe:
non basta usare exclude name="**/test/**"? (o qualcosa del genere...) nel target jar (o dist.. o quello che è che non ho il codice sottomano ora)
EDIT.. ah capito forse...
ma perchè prima della mia modifica non avevamo lo stesso problema? :mbe:
...perchè? :mbe:
non basta usare exclude name="**/test/**"? (o qualcosa del genere...) nel target jar (o dist.. o quello che è che non ho il codice sottomano ora)
EDIT.. ah capito forse...
ma perchè prima della mia modifica non avevamo lo stesso problema? :mbe:
Ma se escludi la cartella dei test nel jar non finisco i class dei vari Mock e poi l'eseguibile non parte. :(
Ma se escludi la cartella dei test nel jar non finisco i class dei vari Mock e poi l'eseguibile non parte. :(
Si puo' scrivere qualcosa che carichi quei Mock solo quando vengono usati?
cdimauro
22-01-2008, 12:13
La soluzione potrebbe essere quella di ridurre i "componenti base" a interfacce, e di realizzarne poi due implementazioni diverse dove serve, una per il codice di produzione e una per il test.
Esempio: AudioInterface -> AudioEngine (produzione) + MockAudio (test).
In questo modo dovremmo separare del tutto il codice di test da quello di produzione.
La soluzione potrebbe essere quella di ridurre i "componenti base" a interfacce, e di realizzarne poi due implementazioni diverse dove serve, una per il codice di produzione e una per il test.
Esempio: AudioInterface -> AudioEngine (produzione) + MockAudio (test).
In questo modo dovremmo separare del tutto il codice di test da quello di produzione.
Buona soluzione anche questa.
Si puo' scrivere qualcosa che carichi quei Mock solo quando vengono usati?
Alla reflection non avevo pensato. Di sicuro ci sarà qualcosa di simile ad Assemble.Load di c# solo che ho il timore che venga fuori un mostro anche per una cosa così semplice. In ogni caso questa sera mi informo meglio e vedo che rimedio.
La soluzione potrebbe essere quella di ridurre i "componenti base" a interfacce, e di realizzarne poi due implementazioni diverse dove serve, una per il codice di produzione e una per il test.
Esempio: AudioInterface -> AudioEngine (produzione) + MockAudio (test).
In questo modo dovremmo separare del tutto il codice di test da quello di produzione.
Anche usando interfacce se poi lasciamo la createForTesting() nell'oggetto di produzione il problema non si ripresenta come ora? :confused:
cdimauro
22-01-2008, 12:41
Ho sempre odiato i vari CreateForTesting...
Anche usando interfacce se poi lasciamo la createForTesting() nell'oggetto di produzione il problema non si ripresenta come ora? :confused:
No, perché la mia idea è quella di eliminare proprio quei metodi.
In pratica nel codice dei test istanzio soltanto oggetti Mock*, mentre nel codice di produzione soltanto oggetti *Engine.
Non esiste nessuna CreateForTesting. Si usano i costruttori delle rispettive implementazioni quando e dove servono. ;)
Hmmm non so voi ma a me avere 20000 interfacce non piace moltissimo e si finisce nell'antipattern del ravioli code. Quando si parla di classi Mock non abbiamo scelta ma per la creazione degli oggetti esistono soluzioni differenti.
Concordo con Cesare, i createForTesting non dovrebbero essere nelle classi di produzione. Non hanno assolutamente senso, spesso creano l'oggetto con parametri default, tanto vale avere le creazioni nelle varie classi test helper tipo EnvironmentTestCase etc...
redcloud
22-01-2008, 12:47
Dovevamo metterne uno dispari? Perché? :confused:
Perchè vedere i pezzi che scendono dalla colonna in modo decentrato è uno strazio. Mi si disallinea il cervello :D
cdimauro
22-01-2008, 12:49
Hmmm non so voi ma a me avere 20000 interfacce non piace moltissimo e si finisce nell'antipattern del ravioli code. Quando si parla di classi Mock non abbiamo scelta ma per la creazione degli oggetti esistono soluzioni differenti.
Concordo con Cesare, i createForTesting non dovrebbero essere nelle classi di produzione. Non hanno assolutamente senso, spesso creano l'oggetto con parametri default, tanto vale avere le creazioni nelle varie classi test helper tipo EnvironmentTestCase etc...
A me non piace avere mille interfacce. Anzi, generalmente non amo particolarmente il design-by-interface (mi piace usare le interfacce quando "sento" che mi servono veramente).
Sarebbe bello poter usare indifferentemente gli stessi oggetti sia in produzione che in fase di test, ma spesso non si può perché... in fase di test non posso creare un display, ad esempio.
E' chiaro, quindi, che le interfacce a cui mi riferiscono servono soltanto per definire il comportamento di oggetti che necessariamente debbono avere un comportamento diverso in fase di produzione e in fase di test. Da cui, quindi ricavare i vari *Engine e Mock*.
Per quanto mi riguarda, meno interfacce (e relativi Mock) usiamo, e meglio è.
Ho sempre odiato i vari CreateForTesting...
No, perché la mia idea è quella di eliminare proprio quei metodi.
In pratica nel codice dei test istanzio soltanto oggetti Mock*, mentre nel codice di produzione soltanto oggetti *Engine.
Non esiste nessuna CreateForTesting. Si usano i costruttori delle rispettive implementazioni quando e dove servono. ;)
Da quello che ho visto le possiamo cancellare o spostarle anche ora. Dobbiamo solo trovargli un posto sensato dove metterle. :)
cdimauro
22-01-2008, 12:54
Perchè vedere i pezzi che scendono dalla colonna in modo decentrato è uno strazio. Mi si disallinea il cervello :D
Tu non pensi quadridimensionalmente, Marty!
http://data-allocine.blogomaniac.fr/mdata/1/6/7/Z20051005084305673584761/img/doc.jpg
Ma soprattutto non pensi da programmatore, dove è il 2 il numero perfetto. :cool:
cdimauro
22-01-2008, 12:56
Da quello che ho visto le possiamo cancellare o spostarle anche ora. Dobbiamo solo trovargli un posto sensato dove metterle. :)
src/trashcan :asd:
[...] Ma soprattutto non pensi da programmatore, dove è il 2 il numero perfetto. :cool:
È un gnommaro convinto. Se non stiamo attenti ci chiederà di usare un solo tipo di gemme perché altrimenti potrebbero confondersi gli utenti :eek:
cdimauro
22-01-2008, 13:03
Mah Credo che non sia soltanto lui il problema. Circolano voci che parlano di lavorare tutti con Linux, perché alcuni test su Windows falliscono e su Linux no.
Io non mi oppongo assolutamente all'idea, sia chiaro, ma prima voglio vedere Fran lavorare su Linux, e poi ben volentieri seguirò la sua strada...
:asd: :asd: :asd: :asd: :asd: :asd: :asd: :asd:
Per quanto mi riguarda, meno interfacce (e relativi Mock) usiamo, e meglio è.
Per quanto riguarda me invece piu' interfacce meglio e', mi piace molto il design-by-interface :)
Il problema e' non prenderci troppo la mano e creare mostri come ExtensibleObject giusto per un paio di metodi. Come sempre in "medio stat virtus". La tua idea di usare interfacce e poi creare gli oggetti mock per eliminare createForTesting() mi piace. Direi di sperimentarci un po' e vedere come esce. Abbiamo sempre la possibilita' di usare la reflection e caricare al volo i MockObject se non e' troppo complicato.
Mah Credo che non sia soltanto lui il problema. Circolano voci che parlano di lavorare tutti con Linux, perché alcuni test su Windows falliscono e su Linux no.
Prima che cio' accada, e' piu' facile che meta' team di sviluppo si trovi senza ditine, e a quel punto gli sara' difficile lavorare sia sotto Windows sia sotto Linux :D
cdimauro
22-01-2008, 13:07
Per quanto riguarda me invece piu' interfacce meglio e', mi piace molto il design-by-interface :)
Il problema e' non prenderci troppo la mano e creare mostri come ExtensibleObject giusto per un paio di metodi. Come sempre in "medio stat virtus". La tua idea di usare interfacce e poi creare gli oggetti mock per eliminare createForTesting() mi piace. Direi di sperimentarci un po' e vedere come esce. Abbiamo sempre la possibilita' di usare la reflection e caricare al volo i MockObject se non e' troppo complicato.
Sì, lo sapevo che a te piace il design-by-interface. E' che tendenzialmente sono un pazzo suicida... :D
Stasera a casa vedo di rimetter su Eclipse e dare un'occhiata alla code base. ;)
cdimauro
22-01-2008, 13:07
Prima che cio' accada, e' piu' facile che meta' team di sviluppo si trovi senza ditine, e a quel punto gli sara' difficile lavorare sia sotto Windows sia sotto Linux :D
Cedo alla violenza... :asd:
jappilas
22-01-2008, 13:10
Sì, lo sapevo che a te piace il design-by-interface. E' che tendenzialmente sono un pazzo suicida... :Dsiamo in due :O
d' altra parte non poteva essere altrimenti essendo io stato clonato dal tuo dna (come da tempo appurato )... :p
Cedo alla violenza... :asd:
Al primo che propone di passare solo a Linux spezzo le ditine e poi ci gioco a shangai. Fra Eclipse, Tomcat e CruiseControl, ho pagato abbondantemente il mio dazio di Open Source :D
^TiGeRShArK^
22-01-2008, 13:12
Per quanto riguarda me invece piu' interfacce meglio e', mi piace molto il design-by-interface :)
Il problema e' non prenderci troppo la mano e creare mostri come ExtensibleObject giusto per un paio di metodi. Come sempre in "medio stat virtus". La tua idea di usare interfacce e poi creare gli oggetti mock per eliminare createForTesting() mi piace. Direi di sperimentarci un po' e vedere come esce. Abbiamo sempre la possibilita' di usare la reflection e caricare al volo i MockObject se non e' troppo complicato.
usare la reflection per questo è una cavolata :p
usare la reflection per questo è una cavolata :p
Tiger, qualunque cosa che funzioni, semplifichi il codice e risolva un problema per definizione non e' una cavolata. Se risolve il nostro problema in maniera semplice, la reflection va benissimo.
Se per risolvere il problema dobbiamo vendere l'anima di Cesare al diavolo, facciamo anche questo.
Ti voglio piu' pragmatico :)
Altra domanda... perchè è stato scelto un numero pari di colonne?
Perchè le gemme scendono a coppie, ed è più facile per il giocatore incastrarle :)
cdimauro
22-01-2008, 13:18
Tiger, qualunque cosa che funzioni, semplifichi il codice e risolva un problema per definizione non e' una cavolata. Se risolve il nostro problema in maniera semplice, la reflection va benissimo.
Se per risolvere il problema dobbiamo vendere l'anima di Cesare al diavolo, facciamo anche questo.
Ti voglio piu' pragmatico :)
Non so quanto possa valere l'anima di un ateo, ma se dovesse servire alla causa... :p
Comunque io i CreateForTesting li toglierei lo stesso, e col lavoretto di cui sopra IMHO il design del progetto dovrebbe trarne giovamento. :)
P.S. Tanto lo sapete che a me piace più rifattorizzare che scrivere codice, vero? :fiufiu:
Non so quanto possa valere l'anima di un ateo, ma se dovesse servire alla causa... :p
Comunque io i CreateForTesting li toglierei lo stesso, e col lavoretto di cui sopra IMHO il design del progetto dovrebbe trarne giovamento. :)
P.S. Tanto lo sapete che a me piace più rifattorizzare che scrivere codice, vero? :fiufiu:
Abbiamo un volontario!
Un'idea che mi e` venuta ora. Si puo` evitare di creare un'interfaccia ogni volta che si crea una classe mock e compilare la classe mock (chiamata con lo stesso nome) in fase di testing invece di quella normale? Eviteremmo un sacco di complicazioni cosi`...
cdimauro
22-01-2008, 13:21
Abbiamo un volontario!
In effetti mi stavo chiedendo: come mai Fran, alla mia proposta, a sua volta non mi ha proposto volontario? :asd:
OK, per me va bene. :)
cdimauro
22-01-2008, 13:22
Un'idea che mi e` venuta ora. Si puo` evitare di creare un'interfaccia ogni volta che si crea una classe mock e compilare la classe mock (chiamata con lo stesso nome) in fase di testing invece di quella normale? Eviteremmo un sacco di complicazioni cosi`...
In Java non c'è la compilazione condizionale, se non ricordo male.
Forse con la Reflection potremmo uscircene fuori, ma per me è un terreno nuovo e onestamente non ho la benché minima idea di come dovremmo procedere...
Un'idea che mi e` venuta ora. Si puo` evitare di creare un'interfaccia ogni volta che si crea una classe mock e compilare la classe mock (chiamata con lo stesso nome) in fase di testing invece di quella normale? Eviteremmo un sacco di complicazioni cosi`...
KISS, proviamo prima a separare le interfacce come suggerisce Cesare.
redcloud
22-01-2008, 14:05
È un gnommaro convinto. Se non stiamo attenti ci chiederà di usare un solo tipo di gemme perché altrimenti potrebbero confondersi gli utenti :eek:
:mbe: :mbe: :mbe:
Perchè le gemme scendono a coppie, ed è più facile per il giocatore incastrarle :)
Ecco allora perchè non ruotiamo il piripicchio così è centrato?
jappilas
22-01-2008, 14:22
:mbe: :mbe: :mbe: bisogna tenere presente che Diamonds è ispirato a Puzzle Fighter (http://en.wikipedia.org/wiki/Super_Puzzle_Fighter_II_Turbo_HD_Remix) ... e anche in quest' ultimo il numero di colonne è pari e il punto di ingresso (*) della pair è decentrato :)
(*) ma al tempo stesso se non vado errato nell' originale la pair entra progressivamente dall' esterno della Griglia di gioco ( non si materializza direttamente sulle prime due righe - oltre che essere "visivamente" più logico dato l' aspetto del playfield, a mio avviso renderebbe più intuitivo il gameplay perchè faciliterebbe il controllo della gempair nel caso critico di Grid quasi piena - il giocatore dovrebbe poterla sfruttare interamente, almeno fino al caso estremo in cui le uniche celle libere siano le due immediatamente sotto il punto di immissione ( e anche in quel caso, una crush può sempre salvare la situazione...)
imho questo è un dettaglio di design su cui dovremmo intervenire (magari non subito, ma yagni fino a un certo punto)
redcloud
22-01-2008, 14:26
bisogna tenere presente che Diamonds è ispirato a Puzzle Fighter (http://en.wikipedia.org/wiki/Super_Puzzle_Fighter_II_Turbo_HD_Remix) .. :)
Appunto, non facciamo un clone :D
Appunto, non facciamo un clone :D
Iniziamo a fare un clone perche' e' piu' facile. Quando abbiamo un buon clone, possiamo cambiare le cose.
redcloud
22-01-2008, 14:50
Iniziamo a fare un clone perche' e' piu' facile. Quando abbiamo un buon clone, possiamo cambiare le cose.
E' un mignolo spezzato? :cry: :cry: :cry:
Ecco allora perchè non ruotiamo il piripicchio così è centrato?
La coppia è messa in verticale per questioni di intuitività :)
Visto che una gemma è il pivot intorno al quale l'altra ruota, se iniziassero a cadere in orizzontale converrebbe avere il pivot a sinistra o a destra?
Qui la risposta non è immediata, a differenza del motivo per cui il punto d'ingresso è leggermente più a destra e non leggermente più a sinistra (che invece è ben preciso), perchè dipende dal giocatore: buona parte dei giocatori, soprattutto i principianti, usa un solo tasto per ruotare i pezzi, non entrambi... ed ogni giocatore ha un suo verso preferito di rotazione (io posso preferire il senso orario, tu puoi preferire quello antiorario), cosa che dipende da vari fattori che non sto ad elencare. Quindi, ognuna delle due scelte comporterebbe un pò di seccature per una fetta di giocatori, e non è quello che vogliamo.
Tra alto e basso, invece, visto che abbiamo a che fare tutti i giorni con la legge di gravità, c'è meno ambiguità, dunque il problema viene aggirato alla radice ed ogni senso di rotazione è assolutamente equivalente.
Iniziamo a fare un clone perche' e' piu' facile. Quando abbiamo un buon clone, possiamo cambiare le cose.
E questo è il motivo per cui avevamo una modalità "classica" ed un Advanced mode, invece di avere solo il secondo :p
La coppia è messa in verticale per questioni di intuitività :)
Visto che una gemma è il pivot intorno al quale l'altra ruota, se iniziassero a cadere in orizzontale converrebbe avere il pivot a sinistra o a destra?
Qui la risposta non è immediata, a differenza del motivo per cui il punto d'ingresso è leggermente più a destra e non leggermente più a sinistra (che invece è ben preciso), perchè dipende dal giocatore: buona parte dei giocatori, soprattutto i principianti, usa un solo tasto per ruotare i pezzi, non entrambi... ed ogni giocatore ha un suo verso preferito di rotazione (io posso preferire il senso orario, tu puoi preferire quello antiorario), cosa che dipende da vari fattori che non sto ad elencare. Quindi, ognuna delle due scelte comporterebbe un pò di seccature per una fetta di giocatori, e non è quello che vogliamo.
Tra alto e basso, invece, visto che abbiamo a che fare tutti i giorni con la legge di gravità, c'è meno ambiguità, dunque il problema viene aggirato alla radice ed ogni senso di rotazione è assolutamente equivalente.
E questo è il motivo per cui avevamo una modalità "classica" ed un Advanced mode, invece di avere solo il secondo :p
abbiamo solo classica ora che mi risulti :P
KISS, proviamo prima a separare le interfacce come suggerisce Cesare.
Appunto per il principio del KISS e` molto piu` facile non dover creare un'interfaccia ogni volta no?
Appunto per il principio del KISS e` molto piu` facile non dover creare un'interfaccia ogni volta no?
Hmm a pelle creare l'interfaccia mi sembra meno convoluto di quell'idea sui mock. Vediamo che dice il nostro volontario quando ci ha provato.
Abbiamo comunque diverse soluzioni possibili, facciamo due prove e scegliamo la piu' semplice.
Hmm a pelle creare l'interfaccia mi sembra meno convoluto di quell'idea sui mock. Vediamo che dice il nostro volontario quando ci ha provato.
Abbiamo comunque diverse soluzioni possibili, facciamo due prove e scegliamo la piu' semplice.
interfaccie e mock non vanno di pari passo?? Per creare un mock hai bisogno di un interfaccia.
ps. In java ci sono delle librerie che permettono di costruirisi i mock a runtime, specificando come debbando rispondere alcuni metodi, e potendo mettere anche degli assert(JMock e EasyMock). Non so dove e se possano servire, ma vi metto solo a conoscenza della loro esistenza.
ho tolto i createForTesting da Game, DroppableFactory, GemQueue e RandomDroppableFactory. Ho semplicemente tolto lo static e usato il costruttore (gia pubblico).
Committo?(fek mi serve login e pwd per committare).
ps.per togliere l'esigenza dei metodo forTesting, io eliminerei i metodi factory, e poi userei Environament come contenitore dei componenti mockati/stubati in fase di testing. Poi l'unico oggetto da creare forTesting rimane Environment. Questo viene passato a tutti gli oggetti che ne hanno bisogno, richiedono quello che hanno bisogno(ad esempio il display, o il soundEngine).
E' una specie di dependency iniection grossolana, per chi ha presente Spring o Juice.
pps.Mi ero dimenticato.. ho fatto refactoring in treno :rulez:
Se ricordo bene avevamo EasyMock nel progetto ma non e` mai stata utilizzata.
ho tolto i createForTesting da Game, DroppableFactory, GemQueue e RandomDroppableFactory. Ho semplicemente tolto lo static e usato il costruttore (gia pubblico).
Committo?(fek mi serve login e pwd per committare).
Se mi hai spedito login e pass dovrei averti aggiunto. Altrimenti ti devo aggiungere stanotte quando torno a casa (:().
Butta tutto dentro appena puoi.
Se ricordo bene avevamo EasyMock nel progetto ma non e` mai stata utilizzata.
EasyMock e' comodissimo, ma essendo un progettino didattico volevo che facessimo tutti pratica con il concetto di Mock scrivendoli a manina.
ps.per togliere l'esigenza dei metodo forTesting, io eliminerei i metodi factory, e poi userei Environament come contenitore dei componenti mockati/stubati in fase di testing. Poi l'unico oggetto da creare forTesting rimane Environment. Questo viene passato a tutti gli oggetti che ne hanno bisogno, richiedono quello che hanno bisogno(ad esempio il display, o il soundEngine).
E' una specie di dependency iniection grossolana, per chi ha presente Spring o Juice.
un esempio di questa soluzione.
DroppableGenerator->GemQueue
DroppableGenerator->MockDroppableGenerator
Questa è l'attuale soluzione. Il mock si comporta in maniera deterministica restituendo sempre un Diamond, mentre GemQueue al suo interno usa RandomDroppableFactory per funzionare non deterministicamente. Nei test questa versione è poco funzionale, per cui si usa il mock(prima c'era il metodo staitic createForTesting su GemQueue).
Un altra soluzione, poterbbe essere che GemQueue quando si crea, chiede all'env quale RandomDroppableFactory deve usare(bisogna fare un interfaccia, ora non cè). La crea (può crearla l'env, oppure può restituire una factory) e poi la usa.
Nel gioco si crea un env che restituisca un RandomDroppableFactory, mentre nei test si crea un env che restituisca un DeterministicDroppableFactory.
Se un singolo test ha bisogno di una sequenza particolare di gemme, può impostare nell'env e usarlo nel singolo test. Poi prima del successivo test, l'env verrà ricreato nel setUp.
cdimauro
22-01-2008, 20:11
ps.per togliere l'esigenza dei metodo forTesting, io eliminerei i metodi factory, e poi userei Environament come contenitore dei componenti mockati/stubati in fase di testing. Poi l'unico oggetto da creare forTesting rimane Environment. Questo viene passato a tutti gli oggetti che ne hanno bisogno, richiedono quello che hanno bisogno(ad esempio il display, o il soundEngine).
Veramente doveva già funzionare così, se non erro: avevo passato più o meno ovunque (dove serviva ovviamente) l'istanza di Environment.
In questi giorni mi sta sembrando di rivivere le stesse esperienze, e la cosa mi preoccupa.
Troppo strano. Urge che riveda la code base. Finisco un po' di cose, scarico Eclipse e incrocio le dita (non vorrei tornare a bestemmiare perché non mi funziona).
Veramente doveva già funzionare così, se non erro: avevo passato più o meno ovunque (dove serviva ovviamente) l'istanza di Environment.
In questi giorni mi sta sembrando di rivivere le stesse esperienze, e la cosa mi preoccupa.
Troppo strano. Urge che riveda la code base. Finisco un po' di cose, scarico Eclipse e incrocio le dita (non vorrei tornare a bestemmiare perché non mi funziona).
in effetti env viene passata un po dappertutto, ma forse non viene sempre usate per questo scopo.
cmq ho un test che mi puzza. TestGemQueue.testEmptyQueue. Testa che la queue sia vuota quando viene creata. Peccato che qua venga creata la coda con GemQueue.createForTesting che in effetti non la crea ma non la riempie. Però nel codice di "produzione" viene chiamata la GemQueue.create che la riempie!
Ho trovato questo test, perchè stavo provando di togliere da pubblico il metodo fillQueueRandomly...
Faccio un po di prove togliendo questo test(e magari mettendone uno che testi che la GemQueue sia piena quando viene creata "realmente")
cdimauro
22-01-2008, 20:37
Ecco, una cosa che non vorrei vedere (personalmente, eh!): creare oggetti come Gem con metodi "di testing".
Io vorrei lavorare il più possibile con oggetti "concreti", insomma quelli che poi ci ritroviamo in produzione.
La creazione di Mock & derivati la riserverei soltanto nei casi in cui non è proprio possibile utilizzare quelli reali (es: Display, Audio, Keyboard, ecc.).
abbiamo solo classica ora che mi risulti :P
Infatti ho scritto "avevamo" :D
Ecco, una cosa che non vorrei vedere (personalmente, eh!): creare oggetti come Gem con metodi "di testing".
Io vorrei lavorare il più possibile con oggetti "concreti", insomma quelli che poi ci ritroviamo in produzione.
La creazione di Mock & derivati la riserverei soltanto nei casi in cui non è proprio possibile utilizzare quelli reali (es: Display, Audio, Keyboard, ecc.).
la penso anche io cosi. Comunque sono riuscito nell'impresa di eliminare createForTesting da GemQueue e rendere private FillQueueRandomly. Quest'ultima cosa ha avuto come costo, il fatto che alcuni test che settavano una sequenza sul MockRandomGenerator devono ricreare la coda invece di chiamare il FillQueueRandomly. Questo perchè ora la coda viene creata gia piena anche per i test. Mi sembra il comportamento più corretto, essendo più vicino a quello di "produzione"
metto anche questa fra le modifiche da comittare?
cdimauro
22-01-2008, 21:11
Per me puoi committare. Ottimo lavoro. :)
buon lavoro, committa pure... ti ho aggiunto l'account
committato
ps. fek hai la casella pm piena
cdimauro
22-01-2008, 22:52
Finalmente sono riuscito a metter sù Eclipse, a fare il checkout e ad eseguire la build (dopo aver dovuto forzare l'uso dello JDK 1.6.0, visto che i vari aggiornamenti automatici mi hanno portato alla 1.6.0_03, ma soltanto della JRE, ed era questa impostata di default :muro: ).
Poiché, nonostante tutto, sono stato troppo fortunato, provando a lanciare Game.java mi capita questo:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at org.lwjgl.Sys$1.run(Sys.java:67)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:65)
at org.lwjgl.opengl.Display.<clinit>(Display.java:104)
at it.diamonds.engine.video.LWJGLEngine.initialise(LWJGLEngine.java:197)
at it.diamonds.engine.video.LWJGLEngine.<init>(LWJGLEngine.java:42)
at it.diamonds.engine.Environment.createEngine(Environment.java:78)
at it.diamonds.GameLoop.create(GameLoop.java:150)
at it.diamonds.Game.setUp(Game.java:42)
at it.diamonds.Game.<init>(Game.java:28)
at it.diamonds.Game.main(Game.java:50)
Qualcuno può darmi una mano cortesemente? Grazie.
Per adesso vado a nanna che s'è fatto tardi. Eventuali suggerimenti li sperimento domani prima di tornare a lavoro.
P.S. Il mio odio per Java continua ad alimentarsi... :muro: :muro: :muro:
redcloud
22-01-2008, 22:57
Mi avete fatto calare la gemma :D
http://img91.imageshack.us/img91/2398/nuovaimmaginexx0.th.jpg (http://img91.imageshack.us/my.php?image=nuovaimmaginexx0.jpg)
ho eliminato un altro createForTesting che non veniva usato
ho segnato i rimanenti con dei TODO per essere spostati in eventuali metodi helper per i test(Anche se alcuni sono chiamati solo in un punto...mi sa che è piu comdodo metterli direttamente nel setUp dove vengono chiamati).
Sono riuscito anche a eliminare isTesting da Environament :cool:
è bastato togliere l'unico if in cui veniva usato, e i test continuano a passare tutti e il gioco non sembra aver problemi. Viene ancora usato al suo interno, per decidere se creare le classi reali per audio, etc o i mock
Finalmente sono riuscito a metter sù Eclipse, a fare il checkout e ad eseguire la build (dopo aver dovuto forzare l'uso dello JDK 1.6.0, visto che i vari aggiornamenti automatici mi hanno portato alla 1.6.0_03, ma soltanto della JRE, ed era questa impostata di default :muro: ).
Poiché, nonostante tutto, sono stato troppo fortunato, provando a lanciare Game.java mi capita questo:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at org.lwjgl.Sys$1.run(Sys.java:67)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:65)
at org.lwjgl.opengl.Display.<clinit>(Display.java:104)
at it.diamonds.engine.video.LWJGLEngine.initialise(LWJGLEngine.java:197)
at it.diamonds.engine.video.LWJGLEngine.<init>(LWJGLEngine.java:42)
at it.diamonds.engine.Environment.createEngine(Environment.java:78)
at it.diamonds.GameLoop.create(GameLoop.java:150)
at it.diamonds.Game.setUp(Game.java:42)
at it.diamonds.Game.<init>(Game.java:28)
at it.diamonds.Game.main(Game.java:50)
Qualcuno può darmi una mano cortesemente? Grazie.
Per adesso vado a nanna che s'è fatto tardi. Eventuali suggerimenti li sperimento domani prima di tornare a lavoro.
P.S. Il mio odio per Java continua ad alimentarsi... :muro: :muro: :muro:
in vm arguments
-Djava.library.path=${workspace_loc:Diamonds/lib/win32}
linka la cartella linux se sei su linux
cdimauro
23-01-2008, 07:39
Funziona! Grazie!!!
E complimenti per il lavoro. :)
Mirko mi mandi la tua email in PM per favore?
(E commit note in inglese per favore :p)
Antares88
23-01-2008, 11:40
Cari ragazzi, vi comunico che ho riconfigurato il server dns del dominio diamondcrush.net e sto rimettendo online il sito ;)
jappilas
23-01-2008, 11:41
@ thebol: grande :)
Cari ragazzi, vi comunico che ho riconfigurato il server dns del dominio diamondcrush.net e sto rimettendo online il sito Caro ragazzo ( :D ) grazie :) Mirko mi mandi la tua email in PM per favore?
(E commit note in inglese per favore :p)se non erro già l' anno scorso avevamo detto di scrivere le commit notes in inglese.. :p
e mi pare anche i todo ... l' anno scorso avevo proposto un task di traduzione che poi non è stato svolto, pensi sia il caso di rimetterlo in lizza? :O
Mirko mi mandi la tua email in PM per favore?
Urca c'è un nuovo membro del team che si chiama quasi come me? :asd:
se non erro già l' anno scorso avevamo detto di scrivere le commit notes in inglese.. :p
Il problema è che mi ricordo sempre dopo aver premuto il tasto commit :muro:
Mi avete fatto calare la gemma :D
http://img91.imageshack.us/img91/2398/nuovaimmaginexx0.th.jpg (http://img91.imageshack.us/my.php?image=nuovaimmaginexx0.jpg)
Non ci eravamo liberati definitivamente anche di questi bug delle biggem? :mad:
Non ci eravamo liberati definitivamente anche di questi bug delle biggem? :mad:
qua farebbe comodo l'ormai famoso log "playabile"
Urca c'è un nuovo membro del team che si chiama quasi come me? :asd:
:D
Ho ricevuto le vostre email, stasera vi aggiungo alla build machine.
E' possibile che alcuni bug che avete fissato dopo la FP siano di nuovo li'. Chi si vuole occupare di questo fix?
Come avete notato al momento siamo un po' informali, perche' prima di riformalizzare il processo voglio arrivare ad una code base in buono stato, riorganizzare la batteria di test e sistemare la build machine a regime.
Ho aggiornato le lib all'ultima versione disponibile. Testate sia su xp che leopard funziona tutto perfettamente. Se c'è qualche utente linux in giro mi farebbe molto comodo sapere se anche per lui non ci sono problemi.
Ho aggiornato le lib all'ultima versione disponibile. Testate sia su xp che leopard funziona tutto perfettamente. Se c'è qualche utente linux in giro mi farebbe molto comodo sapere se anche per lui non ci sono problemi.
Bene! Adesso posso comprarmi il MacBook Air :D
(Mi mancano solo i soldi)
La percentuale di build rotte e' del 50% circa negl'ultimi giorni. Non mi interessa il perche', il percome, il perdove, il prossimo che rompe la build gli spezzo l'avambraccio.
Strength through fear
banryu79
23-01-2008, 15:40
Non mi interessa il perche', il percome, il perdove, il prossimo che rompe la build gli spezzo l'avambraccio.
Strength through fear
[JOKE MODE ON]
Fek, ecco il tuo nuovo avatar, come mi avevi chiesto:
http://www.foroekklesia.com/customavatars/avatar12071_1.gif
redcloud
23-01-2008, 15:40
Ho aggiornato le lib all'ultima versione disponibile. Testate sia su xp che leopard funziona tutto perfettamente. Se c'è qualche utente linux in giro mi farebbe molto comodo sapere se anche per lui non ci sono problemi.
Se c'è qualche utente GNOME.... :D
redcloud
23-01-2008, 15:59
Ok su Debian/Sid ;)
Non ci eravamo liberati definitivamente anche di questi bug delle biggem? :mad:
Se non ricordo male questo bug c'era anche dopo la FP...
^TiGeRShArK^
23-01-2008, 21:30
Tiger, qualunque cosa che funzioni, semplifichi il codice e risolva un problema per definizione non e' una cavolata. Se risolve il nostro problema in maniera semplice, la reflection va benissimo.
Se per risolvere il problema dobbiamo vendere l'anima di Cesare al diavolo, facciamo anche questo.
Ti voglio piu' pragmatico :)
ehmm..
intendevo "è una cavolata" nel senso "è semplicissimo" :stordita:
Infatti io di solito uso la reflection un pò dappertutto quando serve :asd:
^TiGeRShArK^
23-01-2008, 21:37
Se non ricordo male questo bug c'era anche dopo la FP...
si.. ma mi pare che dopo un pò l'avevamo risolto se non sbaglio...
solo che non mi ricordo nè chi ne quando :fagiano:
ehmm..
intendevo "è una cavolata" nel senso "è semplicissimo" :stordita:
Infatti io di solito uso la reflection un pò dappertutto quando serve :asd:
Ah oki :)
Antares88
23-01-2008, 22:50
Dopo varie lotte sono riuscito a configurare anche lo spazio web associato al dominio e a caricarci sopra i files.
Il sito è di nuovo up ! http://www.diamondcrush.net
Chiaramente è da rivedere e da aggiornare. Volendo posso occuparmene io dato che non vedo Jocchan e Xande nei paraggi, anche se sicuramente avrò bisogno di consultarli per capire come sono state predisposte certe cose.
Prima di tutto direi di vedere se funziona tutto, e poi fare una lista di modifiche.
Io nei paraggi ci sono :)
AnonimoVeneziano
24-01-2008, 14:10
Ciao, volevo testare anch'io il programma, ma in fase di partenza mi da questo :D :
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.lwjgl.DefaultSysImplementation.getJNIVersion()I
at org.lwjgl.DefaultSysImplementation.getJNIVersion(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:103)
at org.lwjgl.opengl.Display.<clinit>(Display.java:111)
at it.diamonds.engine.video.LWJGLEngine.initialise(LWJGLEngine.java:197)
at it.diamonds.engine.video.LWJGLEngine.<init>(LWJGLEngine.java:42)
at it.diamonds.engine.Environment.createEngine(Environment.java:57)
at it.diamonds.GameLoop.create(GameLoop.java:152)
at it.diamonds.Game.setUp(Game.java:42)
at it.diamonds.Game.<init>(Game.java:28)
at it.diamonds.Game.main(Game.java:50)
Il tutto succede su linux64. Ho aggiunto in VM arguments il path alle librerie linux64
Ciao
Antares88
24-01-2008, 14:10
Io nei paraggi ci sono :)
fantastico, allora ci sentiamo presto su msn, anche magari per questioni di grafica ! ;)
Ciao, volevo testare anch'io il programma, ma in fase di partenza mi da questo :D :
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.lwjgl.DefaultSysImplementation.getJNIVersion()I
at org.lwjgl.DefaultSysImplementation.getJNIVersion(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:103)
at org.lwjgl.opengl.Display.<clinit>(Display.java:111)
at it.diamonds.engine.video.LWJGLEngine.initialise(LWJGLEngine.java:197)
at it.diamonds.engine.video.LWJGLEngine.<init>(LWJGLEngine.java:42)
at it.diamonds.engine.Environment.createEngine(Environment.java:57)
at it.diamonds.GameLoop.create(GameLoop.java:152)
at it.diamonds.Game.setUp(Game.java:42)
at it.diamonds.Game.<init>(Game.java:28)
at it.diamonds.Game.main(Game.java:50)
Il tutto succede su linux64. Ho aggiunto in VM arguments il path alle librerie linux64
Ciao
In linux64 ci sono ancora le vecchie librerie. Prova ad usare lib/linux e vedere se parte.
AnonimoVeneziano
24-01-2008, 14:19
In linux64 ci sono ancora le vecchie librerie. Prova ad usare lib/linux e vedere se parte.
Con linux va un po' più avanti. Si apre la finestra grafica, appare un messagio che mi dice che non riesce ad inizializzare il sistema audio e poi mi da un eccezione che fa crashare il tutto .
Ecco l'errore completo:
Display Adapter: null
List of available display modes:
400 x 300 x 24 @121Hz
640 x 480 x 24 @60Hz
640 x 480 x 24 @120Hz
800 x 512 x 24 @120Hz
1024 x 768 x 24 @60Hz
512 x 384 x 24 @120Hz
800 x 600 x 24 @60Hz
800 x 600 x 24 @120Hz
1440 x 900 x 24 @60Hz
320 x 240 x 24 @120Hz
640 x 512 x 24 @120Hz
Best mode: 800 x 600 x 24 @120Hz
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/keroro/workspace/Diamonds/lib/linux/liblwjgl-devil.so: /home/keroro/workspace/Diamonds/lib/linux/liblwjgl-devil.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at org.lwjgl.devil.ILNative$1.run(ILNative.java:69)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.devil.ILNative.loadLibrary(ILNative.java:62)
at org.lwjgl.devil.ILNative.<clinit>(ILNative.java:77)
at org.lwjgl.devil.IL.create(IL.java:590)
at it.diamonds.engine.video.LWJGLImage.loadImageFromFile(LWJGLImage.java:92)
at it.diamonds.engine.video.LWJGLImage.<init>(LWJGLImage.java:77)
at it.diamonds.engine.video.LWJGLImage.create(LWJGLImage.java:84)
at it.diamonds.engine.video.LWJGLEngine.createImage(LWJGLEngine.java:77)
at it.diamonds.engine.AbstractEngine.createImage(AbstractEngine.java:51)
at it.diamonds.GameLoop.loadTextures(GameLoop.java:425)
at it.diamonds.GameLoop.<init>(GameLoop.java:115)
at it.diamonds.GameLoop.create(GameLoop.java:171)
at it.diamonds.Game.setUp(Game.java:42)
at it.diamonds.Game.<init>(Game.java:28)
at it.diamonds.Game.main(Game.java:50)
Probabilmente cerca di linkare all'architettatura AMD64 visto che da "architecture word mismatch".
Provo ad aggiornare manualmente le lwjgl nella cartella e vediamo cosa mi dice ...
Ciao
AnonimoVeneziano
24-01-2008, 14:25
Niente da fare, dopo magari faccio un test sotto windows
Penso di aver capito dove sta il problema. In questo momento abbiamo solo lwjgl a 64bit. Tutte le altre librerie di contorno che stanno in lwjgl-optional sono rimaste a 32.
Se vuoi fare un'altra prova scarica i sorgenti e prova a ricompilare le librerie sul tuo sistema.
AnonimoVeneziano
24-01-2008, 14:47
Ok, ce l'ho fatta, mi ero dimenticato di impostare la JRE a 32 bits :D
Carino, però crasha se non trova libero il device audio .
Ciao
AnonimoVeneziano
24-01-2008, 15:23
Ok,sembro essere riuscito a sistemare il problema del suono facendo qualche modifichina al codice.
Come posto la soluzione? :D Spero di non aver spaccato nulla visto che non conosco ancora bene sto codice ... :stordita:
EDIT:
PS = L'ho fatto solo perchè così posso giocarci ascoltando i Carcass :D Non che la musichetta ufficiale non sia carina, intendiamoci , ma è troppo ... disco :asd:
Ok,sembro essere riuscito a sistemare il problema del suono facendo qualche modifichina al codice.
Come posto la soluzione? :D Spero di non aver spaccato nulla visto che non conosco ancora bene sto codice ... :stordita:
EDIT:
PS = L'ho fatto solo perchè così posso giocarci ascoltando i Carcass :D Non che la musichetta ufficiale non sia carina, intendiamoci , ma è troppo ... disco :asd:
Non hai dmix abilitato? Anche con il device occupato dovrebbe riuscire lo stesso ad aprirsi un canale audio tutto per lui.
Per passarci le modifiche batsa fare tasto desto sul progetto. Team -> Create patch.. Poi alleghi il file creato qui sul forum o al massimo me la passi su irc o msn :)
AnonimoVeneziano
24-01-2008, 15:49
Non hai dmix abilitato? Anche con il device occupato dovrebbe riuscire lo stesso ad aprirsi un canale audio tutto per lui.
Per passarci le modifiche batsa fare tasto desto sul progetto. Team -> Create patch.. Poi alleghi il file creato qui sul forum o al massimo me la passi su irc o msn :)
Credo che il muxing sia abilitato. Riesco ad usare amarok, mplayer e kaffeine contemporaneamente, forse OpenAL da qualche problema col muxing HW dell'intel ... mah!
Comunque mo provo a fare come mi hai detto ...
AnonimoVeneziano
24-01-2008, 15:52
Eccola.
Ripeto, controllala, perchè oggi è la prima volta che vedo sto codice :D
Ciao
EDIT: Ho provato a seguire le istruzioni del Readme, copiando openalrc.example in ~/.openalrc , col risultato che adesso il muxing funziona, ma l'audio scaglia parecchio. Meglio senza audio praticamente! (anche se Diamond Crush è l'unica applicazione audio abilitata)
EDIT2: Non avevo visto che diceva di copiare anche asoundrc.example. Il problema è che copiando anche questo la situazione è tornata a quella originale : Il muxing non funziona (ma l'audio non scaglia) . Il messaggio di errore a console però è cambiato leggermente :
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave
open /dev/[sound/]dsp: Device or resource busy
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave
open /dev/[sound/]dsp: Device or resource busy
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave
open /dev/[sound/]dsp: Device or resource busy
Sto giro sembra usare ALSA
Credo che il muxing sia abilitato. Riesco ad usare amarok, mplayer e kaffeine contemporaneamente, forse OpenAL da qualche problema col muxing HW dell'intel ... mah!
Comunque mo provo a fare come mi hai detto ...
Sarà openal che sul tuo sistema apre oss di default, cosa che non va a braccetto con dmix su alcune schede. Puoi imparare il lisp per provare a scrivere il file di conf di openal oppure cercare versioni modificate della libreria che usino solo alsa. Per quanto mi riguarda ho deciso di non perdere più tempo dietro al port di linux. Se funziona bene, altrimenti amen.
Eccola.
Ripeto, controllala, perchè oggi è la prima volta che vedo sto codice :D
Ciao
Come soluzione sembra buona anche se mancano i test! Questa sera vedo se applicarla.
AnonimoVeneziano
24-01-2008, 16:37
Sarà openal che sul tuo sistema apre oss di default, cosa che non va a braccetto con dmix su alcune schede. Puoi imparare il lisp per provare a scrivere il file di conf di openal oppure cercare versioni modificate della libreria che usino solo alsa. Per quanto mi riguarda ho deciso di non perdere più tempo dietro al port di linux. Se funziona bene, altrimenti amen.
Mah, ho provato a impostare la sampling-rate nel file di config di OpenAL (pensando fosse quello) , ma cambiandola una volta il gioco è partito senza audio e l'altra è crashato X direttamente :asd: (che c'entra X con l'audio poi).
Boh, comunque lo preferisco senza audio quando sto ascoltando la musica, quindi ...
Come soluzione sembra buona anche se mancano i test! Questa sera vedo se applicarla.
Azz, i tests ...:doh:
E come si fa il test di questa cosa? Bisogna fare in modo che l'inizializzazione dell'audio fallisca di proposito ...
Niente da fare, dopo magari faccio un test sotto windows
Se vuoi fare un'altra prova scarica i sorgenti e prova a ricompilare le librerie sul tuo sistema.
Sarà openal che sul tuo sistema apre oss di default, cosa che non va a braccetto con dmix su alcune schede.
Setup... avanti... avanti... avanti... done :D
calcio di rigore a porta vuota
Setup... avanti... avanti... avanti... done :D
calcio di rigore a porta vuota
Troll :Prrr:
Azz, i tests ...:doh:
E come si fa il test di questa cosa? Bisogna fare in modo che l'inizializzazione dell'audio fallisca di proposito ...
Ok torno serio.
Per testare qualcosa come l'audio, si costruisce un oggetto Mock che "fa finta" di essere l'audio. Visto che e' il tuo oggetto, lo puoi far fallire di proposito e puoi testare la logica che gestisce il fallimento dell'oggetto audio.
Ora, il problema e' che hai scritto prima la soluzione al bug e poi vuoi scrivere i test. Noi usiamo un altro processo per gestire i bug:
Una volta individuato il bug:
1) Scrivere prima un test che eserciti il bug, quindi che fallisca quando il bug e' presente.
2) Scrivere test-driven il codice che risolve il bug.
3) Abilitare il test che esercitava il bug e assicurarsi non fallisca.
Tradotto. La tua soluzione va bene, ma non puoi metterla nella code base: devi prima seguire questi tre punti.
(Grazie comunque ;))
E se invece di modificare Environment e GameLoop creiamo due classi FakeAudio e FakeSound che vengono istanziate solo in caso di problemi?
E se invece di modificare Environment e GameLoop creiamo due classi FakeAudio e FakeSound che vengono istanziate solo in caso di problemi?
Si', chiamale NullAudio e NullSound.
Si', chiamale NullAudio e NullSound.
Eccolo! Lo sapevo che dovevo starmene zitto! :muro:
Almeno domani avrò qualcosa da fare durante le pause :)
AnonimoVeneziano
24-01-2008, 18:11
Ok torno serio.
Per testare qualcosa come l'audio, si costruisce un oggetto Mock che "fa finta" di essere l'audio. Visto che e' il tuo oggetto, lo puoi far fallire di proposito e puoi testare la logica che gestisce il fallimento dell'oggetto audio.
Ora, il problema e' che hai scritto prima la soluzione al bug e poi vuoi scrivere i test. Noi usiamo un altro processo per gestire i bug:
Una volta individuato il bug:
1) Scrivere prima un test che eserciti il bug, quindi che fallisca quando il bug e' presente.
2) Scrivere test-driven il codice che risolve il bug.
3) Abilitare il test che esercitava il bug e assicurarsi non fallisca.
Tradotto. La tua soluzione va bene, ma non puoi metterla nella code base: devi prima seguire questi tre punti.
(Grazie comunque ;))
Ho capito :asd: Non mi stupisce comunque che il progetto si sia fermato ad un certo punto , è un lavoraccio scrivere tutto test-driven :p
C'è una cosa che però non ho capito bene. Il fallimento dell'oggetto è comportato dalla chiamata di "AL.create()" che lancia un eccezione.
Non credo di aver capito come farlo fallire di proposito, visto che il fallimento dipende da una classe non mia (AL appunto). Bisognerebbe aggiungere metodi appositi per il test che falliscano di proposito?
Ciao
Ho capito :asd: Non mi stupisce comunque che il progetto si sia fermato ad un certo punto , è un lavoraccio scrivere tutto test-driven :p
C'è una cosa che però non ho capito bene. Il fallimento dell'oggetto è comportato dalla chiamata di "AL.create()" che lancia un eccezione.
Non credo di aver capito come farlo fallire di proposito, visto che il fallimento dipende da una classe non mia (AL appunto). Bisognerebbe aggiungere metodi appositi per il test che falliscano di proposito?
Ciao
Se i test vengono scritti bene e si mantengono un minimo nel tempo non e` assolutamente un lavoraccio :)
I problemi sorgono quando i test vengono scritti male perche` non si hanno le capacita` (o la voglia) di testare il codice decentemente. In questo caso i test diventano difficili da interpretare e cambiare quando le specifiche lo richiedono.
Ho capito :asd: Non mi stupisce comunque che il progetto si sia fermato ad un certo punto , è un lavoraccio scrivere tutto test-driven :p
Il progetto si e' fermato quando hanno smesso di scrivere test-driven e la code base e' stata abbandonata a se' stessa e non testata :)
Si scrive il codice molto piu' velocemente test-driven, piuttosto che normalmente, anche per il solo motivo che non lanci mai il debugger. Intendo proprio mai. Io non so come sia fatto il debugger di Eclipse.
C'è una cosa che però non ho capito bene. Il fallimento dell'oggetto è comportato dalla chiamata di "AL.create()" che lancia un eccezione.
Non credo di aver capito come farlo fallire di proposito, visto che il fallimento dipende da una classe non mia (AL appunto). Bisognerebbe aggiungere metodi appositi per il test che falliscano di proposito?
Ciao
Devi wrappare la chiamata a AL.create() in un oggetto Audio (credo che ci sia gia'), poi creare un'interfaccia AudioInterface ed un oggetto MockAudio che invece di chiamare AL.create() fallisca di proposito, magari lanciando un'eccezione. La logica di gestione del fallimento verra' invocata nel test lavorando sull'oggetto MockAudio e gestira' l'audio attraverso l'interfaccia.
Appena arrivo a casa, se vuoi, ci guardo e stasera possiamo scrivere questo codice in pair programming :)
(Cosi' creo un altro mostro...)
scusate ma in gameLoop c'è gia sto codice
try
{
environment.createAudio();
}
catch(RuntimeException exception)
{
Sys.alert("Warning", MSG_NO_AUDIO);
environment.createAudioForTesting();
}
non dovrebbe sorpassre il problema?
scusate ma in gameLoop c'è gia sto codice
try
{
environment.createAudio();
}
catch(RuntimeException exception)
{
Sys.alert("Warning", MSG_NO_AUDIO);
environment.createAudioForTesting();
}
non dovrebbe sorpassre il problema?
createAudioFortesting non esiste più. Per ora ho commentato quella riga ed è per quello che ad ano crasha il gioco per via di una nullpointerexception.
createAudioFortesting non esiste più. Per ora ho commentato quella riga ed è per quello che ad ano crasha il gioco per via di una nullpointerexception.
Ok, io e Anonimo, se vuole, stasera in pair programming introduciamo un NullAudio che gestisca la situazione.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.