10.6 Kako prijaviti GPC bug
(Prijava bugova)
Ako se susretnete s bugom u GPC-u, molimo provjerite da li je to jedan
od već poznatih bugova (see Known Bugs). Ako nije, molimo prijavite ga na GNU Pascal mailing listu (see Mailing List). Na taj način, oni uvijek stižu održavateljima. Molimo primijetite
slijedeće točke.
Ako je problem u samom prevodiocu, ne u procesu instalacije ili
nečem poput toga, molimo priložite test program koji reproducira
problem, i uočite donje natuknice. Možete također slati test
programe za mogućnosti koje rade u GPC-u kako bi osigurali da
se neće pokvariti u budućim izdanjima.
- Test program treba biti što je moguće kraći, ali
u svakom slučaju, molimo pošaljite kompletan
program i učinite sigurnim da isti još uvijek reproducira
problem prije nego što nam ga pošaljete. Prečesto, korisnici su
nam slali kod koji je sadržavao očite sintaksne pogreške daleko
prije aktualnog problema, ili samo fragmente koda o kojima smo
mogli samo izdaleka nagađati. To je neproduktivno za nas, a i
vama ne pomaže da riješite svoj problem.
Preferirani oblik test programa je forma koju automatizirani
GPC Test Suite razumije. Molimo, ako je ikako moguće, šaljite
svoje test programe u ovoj formi što bi trebalo biti lako za učiniti,
kako mi ne bi morali gubiti vrijeme da ih prilagodimo toj formi,
te da se možemo koncentrirati na rješenje problema.
- Datoteka koja sadrži glavni program mora imati ime koje
završava sa .pas i mora sadržavati riječ program
(case-insensitive, tj. veliko i odgovarajuće malo slovo se smatraju
istim) te ; u istom retku da uopće bude prepoznata od test
skripte. Ostale datoteke koje završavaju sa .pas (npr. moduli
i jedinice ili podatke koje program treba) ne smiju to sadržavati.
- Kako Test Suite mora raditi vrlo ... hmph ... čudnim
operacijskim sustavima, također imena se datoteka moraju razlikovati
u prvih osam (8) znakova (case-insensitive) i ne bi smjela sadržavati
ništa osim slova, znamenki, crtice, podvlake (engl. underscore)
i jedne točke. Dalje, sve pomoćne datoteke (jedinice (unit), moduli,
include i podatkovne datoteke) ne smije imati imena duža od “8+3”
znakova; isto se odnosi i na imena sučelja jedinica/modula (jer će GPC
kreirati .gpi imena datoteka bazirana na njihovim imenima).
Često je dobra ideja koristiti vlastito ime, nadimak ili inicijale
iza čega slijedi broj kao ime datoteke.
- Ako vaš test program zahtijeva nake jedinice (units) ili module,
nemojte im davati (odnosno njihovim 'interface' sučeljima u slučaju
modula) uobičajena imena puput Test, Foo ili
MyUnit, osim ako imate vrlo posebne razloge za to, budući
da bi se mogli pojaviti suptilni problemi ako nekoliko testnih programa
koristi isto ime. Umjesto toga, preporučen pristup je da se imenima
jedinica/modula/interface-a nadoda prefiks (predmetak) – ime glavnog
testnog programa ili njegova skraćenica (to je neophodno zbog restrikcija
na imenima datoteka). Nadalje, molimo izbjegavajte korištenje jedinica
i modula uopće, ako bug nije specifičan za njih; kako bi se test održavao
što je moguće jednostavnijim.
- Test program, kada se izvršava, treba proizvesti liniju izlaza
koja se sastoji od niza OK (praćenog znakom za novi red,
newline) ako je sve prošlo kao što je očekivano, ili bilo što
drugo (npr. failed, potencijalno praćeno razlogom pada
na testu) ako je nešto pošlo krivo. U tom posljednjem slučaju
mogli biste poželjeti ispisati dodatnu informaciju kao što su
vrijednosti važnih varijabli ili indikaciju u kom je dijelu
došlo do pogreške u programu ako se to moglo desiti na nekoliko
mogućih mjesta.
- Međutim, ako je program namijenjen da provjeri da li GPC prepoznaje
(namjernu) grešku u programu, stavite niz WRONG negdje u
test programu, najbolje u komentaru u retku koji sadrži namjernu
pogrešku. WRONG testovi će biti pokrenuti s opcijom -w
da se potisnu sva upozorenja, tako da će samo prave pogreške biti
detektirane.
Primijeti: Dok je moguće kombinirati nekoliko OK
testova u jednom test programu (ako učinite sigurnim da ispisuje
OK samo ako svi testovi uspješno prođu), ne možete staviti
nekoliko WRONG testova u isti program. Razlog tome je što
prevodilac neće uspjeti prevođenje (i test će se smatrati uspješnim)
već i kad se pojavi samo jedna od očekivanih grešaka. Dakle,
za WRONG testove, postavite samo jednu provjeru u testni
program. Također, nastojite održavati takav test program što je
moguće jednostavnijim, zbog izbjegavanja mogućnosti da ne bi pao
zbog drugih problema (i zbog toga bi test pogrešno bio smatran
uspješnim).
- Ako bi test trebao samo provocirati GPC upozorenje, koristite
WARN umjesto WRONG. Ovo će pokrenuti test bez -w,
ali sa -Werror. Međutim, ovakvi testovi će se također činiti
uspješnim i ako proizvode grešku kod prevođenja, ne samo kod upozorenja.
Stoga, kod provjeravanja za upozorenja, često je dobra ideja priložiti
komplemetarni test (za kojeg se očekuje da uspije)
i sa -w u FLAG ili direktivi prevodioca {$W-}
da bi se osiguralo da je riječ zaista samo o upozorenju, a ne o
pogrešci.
- Za test koji reproducira postojeći problem (za koji se ne očekuje da će
se brzo riješiti), molimo stavite komentar na vrh datoteke koji opisuje
problem u par riječi, i započnite ga sa BUG. Ovo se ne traži od
test skripti, to je samo da se učini lakšim onima koji će pokušati
riješiti problem kako bi se isprve i odmah vidjelo što test želi
pokazati. Testovi za nove (planirane) značajke ne bi smjeli reći
BUG.
Slijedeće specijalne mogućnosti testne aplikacije mogu biti korisne za
konstruiranje ponešto neuobičajenih testova:
- Ako je očekivani ispis programa nešto osim OK, stavite to u
datoteku <basename>.out (gdje je <basename> ime testnog
programa bez .pas nastavka).
- Ako program očekuje neki ulaz, stavite ga u datoteku
<basename>.in. Biti će automatski preusmjerena na standardni
ulaz programa.
- Ako test treba neke specijalne opcije proslijeđene GPC naredbenoj
liniji, stavite ih u komentar sa prefiksom FLAG, npr.
{ FLAG --extended-pascal -Werror }
- Ime izvorne datoteke test programa bit će proslijeđeno kao prvi
argument naredbene linije do test programa koji se izvršava.
- Ako test treba biti pokrenut na specijalan način, možete popratiti
program sa skriptom <basename>.run koja će pokrenuti stvarni
test nakon što je testni program preveden. Ova skripta će biti
pokrenuta od sh (bez obzira na prvu liniju). Da bi bila
prenosiva, trebala bi koristiti samo standardne alate i značajke
prisutne u svim sh kompatibilnim ljuskama (npr. ash,
bash, ali ne neophodno i csh). Ime izvorne datoteke
test programa će biti proslijeđeno kao prvi argument komandnoj
liniji za izvršenje skripte u tom slučaju. Prevedena
datoteka se uvijek naziva ./a.out na većini sistema, ali,
npr. ./a.exe na Cygwin platformi. Environment varijabla
A_OUT sadrži ime (npr. a.out ili a.exe, tako da
uvijek možete pozvati program sa ./"$A_OUT").
- Ako test treba biti preveden na specijalan način (npr. da se odluči
da li preskočiti test), smjestite naredbe u skriptu (najbolje
nazvanu <basename>.cmp), i staviti ime datoteke sa skriptom
u komentar ispred čega dolazi COMPILE-CMD: u source test
programa. Skripta za prevođenje će biti pokrenuta umjesto
prevodioca i bilo koje druge akcije poduzete za taj test program,
tako da vam to daje maksimalnu fleksibilnost u čemu god što trebate
napraviti. Skripta će biti pokrenuta od sh (bez obzira na njenu
prvu liniju). Da bi bila prenosiva, najbolje da koristi samo standardne
alatke i značajke sh kompatibilnih ljusaka (vidi gore).
Prvi argument naredbene linije proslijeđen skripti za
prevođenje bit će prevodilac kojeg treba koristiti, uključivo sve
opcije. Drugi argument bit će ime izvorne datoteke sa test programom.
Za neke tipične testove postoje standardne skripte za prevođenje,
npr. asmtest.cmp koje će preskočiti test osim ako se pokrene
na platformi podržanoj za nekoliko testova koji će sadržavati `asm'
naredbe. Naravno, općenito je bolje izbjegavati situaciju da se mora
koristiti takve skripte kad je god moguće.
- U nekim biste slučajevima mogli poželjeti napisati "poslučajene" testove.
Ovo se u normalnim uvjetima ne preporuča, jer čini probleme težim za
reproducirati, ali ponekad može biti korisno (npr. kad želimo pokriti
velik raspon parametara). U takvim slučajevima može se koristiti slijedeća
strategija:
...
uses GPC;
var
RandomSeed: Integer;
begin
RandomSeed := Random (MaxInt);
SeedRandom (RandomSeed);
... { vaši normalni testovi ovdje }
{ kad se ispisuje poruka o grešci: }
if ... then
begin
WriteLn ('failed (', RandomSeed, ') ',
... { možebitne dodatne informacije } );
Halt
end
end.
Ovo je pomalo neprirodno jer se pseudo-slučajni broj koristi za
(ponovno) postavi 'sjeme' (inicijalno stanje) pseudo-slučajnog
generatora, ali trenutno nema načina da se dobavi interno stanje
istog (i zapravo niti nije predstavljeno jednim brojem, već stanjem
jednog polja).
Dajući vrijednost RandomSeed u poruci o grešci, bit će lako
reproducirati problem stavljajući ovu vrijednost umesto Random (MaxInt).
Samo budite sigurni da ste ispisali ovu vrijednost u svakoj
poruci o bugu koju test program može proizvesti.