BUGLIST - Bughunters' Official Thread

[AnonimoVeneziano]

Originariamente inviato da VICIUS

Ti meriti come minimo 5 giorni di sospensione per OT molesto.

Vigile e severo ad ogni ora

EDIT : Azz, sto post di spam ha fatto una nuova pagina e ha "nascosto" il mio post serio Leggere la pagina prima plz

Ciao

[AnonimoVeneziano]

Ok, non avevo capito bene come funziona il sistema di caduta degli oggetti in Diamonds

Ovviamente chiamare una volta doIteration() non è sufficiente per far cadere tutto l'oggetto. Potrebbe essere che il problema risieda nell'algoritmo che decide quando smettere di far cadere un oggetto?

Ciao

[Bonfo]

Pensiero personale....
... con i test messi nelle condizioni attuali è impossible riuscire a beccare qualsiasi bug!!!

Cosa voglio dire: se per scrivere il test che esercita un bug bisogna prima debuggare il test... vorebbe dire, in TDD, scrivere il test del test.

A questo punto 2 opzioni:
- ciao TDD
- loop infinito.

La vera soluzione è la 3: REFACTORING!!!

Ovvero lasciamo li i bug ( che adesso non fanno male a nessuno) e riscirviamo i test in modo che siano al massimo 4/5 righe.

Siccome il potere è limitato invoco i poteri superiori:
http://www.hwupgrade.it/forum/showpo...&postcount=186
e
http://www.hwupgrade.it/forum/showpo...74&postcount=2


P.S.: non che io sia il più bello... sta settimana sono risucito a smazzare poco.

[Baol]

Concordo in pieno con Bonfo.
Per testare i bug è un disastro, sto cercando da ieri di capire cosa fa la metà dei test, per capire come scrivere quelli che devo fare io.
Esemplare il caso di TestGemFalling e TestGemFallingWithGravity, che a quel che ho capito testano esattamente le stesse cose!

Oppure il fatto che per entrambi i bug aperti CI SIA UN TEST che dovrebbe coprirli (il test postato da Anonimo qui sopra è molto simile ad un test già presente). Ma il test passa comunque.

Nonostante tutto ciò una buona notizia: il bug 4 è risolto.
Basta aggiungere la seguente assert:

assertNotNull("BigGem must exist after extension", grid.getDroppableAt(new Cell(12, 3)));

ai seguenti test in TestBigGemInGrid.java:
- testBigGemExtendsUp
- testBigGemExtendsDown
- testBigGemExtendsRight
- testBigGemExtendsOnLeft

E riscrivere il metodo AddColumn di BigGem come segue:

DroppableList droppableList = new DroppableList();
        for(int row = region.getTopRow(); row <= region.getBottomRow(); ++row)
        {
            droppableList.add(grid.getDroppableAt(new Cell(row, column)));
        }
        addGem(droppableList);

(In pratica com'era riscritto prima il metodo aggiungeva a "includedGems" la gemma superiore e la BigGem stessa, invece che l'altra gemma, così poi updateBigGems cancellava le cose sbagliate)

"Perchè non lo fai tu?" mi direte? (o anche "Abbiamo un volontario!"...)
Semplicemente non ho ancora un account, se qualcuno avesse fretta qua c'è tutto, altrimenti farò io appena possibile


EDIT: per il bug 3 sembra proprio non sia la stessa causa dell'altra volta, quindi sono arrivato anche io alle conclusioni di Anonimo, seppure non abbia capito molto dei vari stati (c'è già stata la proposta di uno schema, vero?).

[Bonfo]

Fantastico, ma....

Originariamente inviato da Baol

Basta aggiungere la seguente assert:

assertNotNull("BigGem must exist after extension", grid.getDroppableAt(new Cell(12, 3)));

ai seguenti test in TestBigGemInGrid.java:
- testBigGemExtendsUp
- testBigGemExtendsDown
- testBigGemExtendsRight
- testBigGemExtendsOnLeft

... no buono.

O meglio, un altro lampante segnale he c'è qualcosa che non va... per mettere a posto una riga di codice basta 1 test, non c'è biosgno di 4 che oltretutto stanno testando un altra cosa.

Tutti in coro: "REFACTORING!!"

P.S.: mi sento un po' Balmer: developer, developer, developer

[cionci]

C'è un bug nello script di lancio per Linux.

Nella prima riga ci deve essere #!/bin/bash invece di #!/bin/sh

Inoltre:

$ ./DiamondCrush64
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.openal.AL.<clinit>(AL.java:59)
at it.diamonds.engine.audio.OpenALAudio.<init>(Unknown Source)
at it.diamonds.engine.audio.OpenALAudio.create(Unknown Source)
at it.diamonds.engine.Environment$1.create(Unknown Source)
at it.diamonds.engine.Environment.createAudio(Unknown Source)
at it.diamonds.engine.Environment.createAudio(Unknown Source)
at it.diamonds.engine.Environment.createGameLoop(Unknown Source)
at it.diamonds.Game.<init>(Unknown Source)
at it.diamonds.Game.main(Unknown Source)

su Linux a 64 bit.
Ora provo la versione a 32 bit.

[VICIUS]

Originariamente inviato da cionci

C'è un bug nello script di lancio per Linux.

Nella prima riga ci deve essere #!/bin/bash invece di #!/bin/sh

/bin/sh dovrebbe essere un link alla shell predefinità. Su alcuni sistemi bash non è installato mentre sh esiste sempre altrimenti esplode tutto. Meglio tenere così.

Originariamente inviato da cionci

Inoltre:

$ ./DiamondCrush64
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.openal.AL.<clinit>(AL.java:59)
at it.diamonds.engine.audio.OpenALAudio.<init>(Unknown Source)
at it.diamonds.engine.audio.OpenALAudio.create(Unknown Source)
at it.diamonds.engine.Environment$1.create(Unknown Source)
at it.diamonds.engine.Environment.createAudio(Unknown Source)
at it.diamonds.engine.Environment.createAudio(Unknown Source)
at it.diamonds.engine.Environment.createGameLoop(Unknown Source)
at it.diamonds.Game.<init>(Unknown Source)
at it.diamonds.Game.main(Unknown Source)

su Linux a 64 bit.
Ora provo la versione a 32 bit.

La versione a 64 bit è broken. lib/linux64 va cancellata del tutto perché ora le librerie stanno tutte in lib/linux. Il build.xml modificato per creare una sola versione per linux e lo script di avvio modificato che tanto ci pensa lwjgl a capire quale libreria caircare.

Edit: aggiungo che per la versione a 64bit mancano da compilare le versioni a 64bit di libIL* e lwjgl-devil che purtroppo non erano presenti nel pacchetto dei pre-compilati. Se qualcuno si scarica i sorgenti e ci prova fa un favore a tutti i pinguini.

[cionci]

Originariamente inviato da VICIUS

/bin/sh dovrebbe essere un link alla shell predefinità. Su alcuni sistemi bash non è installato mentre sh esiste sempre altrimenti esplode tutto. Meglio tenere così.

Io se metto bash parte, se lascio sh non parte
Con /bin/sh:
$ ./DiamondCrush64
./DiamondCrush64: 6: function: not found

In ogni caso se è broken vedo di provare l'altra.

[fek]

Originariamente inviato da Baol

Esemplare il caso di TestGemFalling e TestGemFallingWithGravity, che a quel che ho capito testano esattamente le stesse cose!

Puoi semplificare questi due test e eliminare quello che non serve?

Nonostante tutto ciò una buona notizia: il bug 4 è risolto.
Basta aggiungere la seguente assert:

assertNotNull("BigGem must exist after extension", grid.getDroppableAt(new Cell(12, 3)));

ai seguenti test in TestBigGemInGrid.java:
- testBigGemExtendsUp
- testBigGemExtendsDown
- testBigGemExtendsRight
- testBigGemExtendsOnLeft

Ottimo! Semplifica questi quattro test, accorpali dove necessario, e aggiungi un nuovo test che esercita solo il bug e nient'altro.

"Perchè non lo fai tu?" mi direte? (o anche "Abbiamo un volontario!"...)
Semplicemente non ho ancora un account, se qualcuno avesse fretta qua c'è tutto, altrimenti farò io appena possibile

Faccio subito

[fek]

Originariamente inviato da VICIUS

/bin/sh dovrebbe essere un link alla shell predefinità. Su alcuni sistemi bash non è installato mentre sh esiste sempre altrimenti esplode tutto. Meglio tenere così.

Edit: aggiungo che per la versione a 64bit mancano da compilare le versioni a 64bit di libIL* e lwjgl-devil che purtroppo non erano presenti nel pacchetto dei pre-compilati. Se qualcuno si scarica i sorgenti e ci prova fa un favore a tutti i pinguini.

Setup avanti avanti avanti

[VICIUS]

Originariamente inviato da fek

Setup avanti avanti avanti

Se un giorno dovessimo incontrarci ti stacco tutte le ditine e ci gioco a shanghai!

[AnonimoVeneziano]

Vabbè, comunque ho risolto il bug della biggem

Adesso sistemo il test e poi committo.

Il problema è che nella caduta viene applicata una StrongestGravity che ha forza 10 (in pratica a ogni iterazione di animazione il biggem scende di 10 pixels) solo che una casella è lunga 32 pixels e 10 non è un multiplo di 32 ...

Nel codice di "Biggem.canMoveDown()" c'è questa linea di codice :

    public boolean canMoveDown(Grid grid)
    {
        if(getSprite().getPosition().getY() != grid.getRowUpperBound(region.getTopRow()))
        {
            return true;
        }

In pratica ritorna sempre true se la posizione Y dello Sprite non raggiunge mai grid.getRowUpperBound(colonna_di_arrivo_biggem) e visto che StrongestGravity non è multiplo di 32 questo non avviene mai mandando in loop infinito la griglia in cui la biggem cade (si blocca totalmente) e causando quindi il BUG.

La soluzione che propongo è di cambiare la costante di moltiplicazione della StrongestGravity da 20 a 16, così che la forza passi ad 8 e sia sottomultiplo di 32.

Adesso finisco di scrivere il test e se vi va bene la soluzione committo.

Ciao

[AnonimoVeneziano]

Ok, test scritto.

Appena mi dite se la soluzione è OK (o se per qualche ragione la strongest deve rimanere 20 o è necessario metterla più alta di 16 al prossimo multiplo) e appena fek risistema il server committo.

[Bonfo]

Basta copiare la canMoveButNotWithFullGravity() che c'è in AbstractSingleDroppable, il che mi fa pensare che finisca in AbstractDroppable

In ogni caso da qualche parte ho fatto ( da poco) un test che controllava che la bigGem si fermasse sul fondo nonostane la gravità..aspetta che cerco.


EDIT:
Eccolo qua in it.diamonds.tests.droppable.gems.TestGemFallingWithGravity:

    public void testBigGemFallingWithStrongGravityToGridBottom()
    {
        controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 4);
        testBigGemFallingWithGravityToGridBottom();
    }

[Bonfo]

Originariamente inviato da AnonimoVeneziano

Ok, test scritto.

Appena mi dite se la soluzione è OK (o se per qualche ragione la strongest deve rimanere 20 o è necessario metterla più alta di 16 al prossimo multiplo) e appena fek risistema il server committo.

Le cose devono funzionare indipendentemente dai valori, altrimenti il config che ci sta a fare?!? Per me la soluzione di cambiare il valore è sbagliata.

EDIT: infatti cambiando il test da
controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 4);
a
controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 5);
non va più una mazza.

Fixalo, ma non cambiando il valore

Ora vado veramente a letto !!!

[VICIUS]

Originariamente inviato da Bonfo

Le cose devono funzionare indipendentemente dai valori, altrimenti il config che ci sta a fare?!? Per me la soluzione di cambiare il valore è sbagliata.

EDIT: infatti cambiando il test da
controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 4);
a
controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 5);
non va più una mazza.

Fixalo, ma non cambiando il valore

Ora vado veramente a letto !!!

Concordo. Se domani vogliamo cambiare la larghezza delle celle ci troviamo nuovamente con il bug.

[AnonimoVeneziano]

Ok, stavo giusto giusto guardando adesso quella cosa. (Difatti non mi spiegavo come mai per le gemme funzionasse e per le biggem no e indagando ...)

Ciao

[Bonfo]

Il sistema della gravità non è chiarissimo....

... perchè viene sempre applicata 1/2 actualGravity, invece che "intera"?

Secondo me rende le cose meno comprensibili. Siccome è un fattore di scala perchè non lo caviamo e basta e dividiamo per due tutti i valori??

Qui però bisogna chiedere a costumer: Jocchan!!

[AnonimoVeneziano]

Guardando bene ho notato che non c'è nessuna canMoveButNotWithFullGravity() in AbstractSingleDroppable.

Questo significa che sia BigGem che Gem e tutti gli altri usano quella di AbstractDroppable che , probabilmente non funziona bene per i Gemmozzi.

Indago ...

[AnonimoVeneziano]

Originariamente inviato da Bonfo

Il sistema della gravità non è chiarissimo....

... perchè viene sempre applicata 1/2 actualGravity, invece che "intera"?

Secondo me rende le cose meno comprensibili. Siccome è un fattore di scala perchè non lo caviamo e basta e dividiamo per due tutti i valori??

Qui però bisogna chiedere a costumer: Jocchan!!

Ti sei offerto volontario per scovare tutti i "Gravity / 2" che ci sono nel codice e sostituirli?