Amikor a program elkezd végtelen ciklusban adatokat gyártani a memóriában, egész hamar be tud telni az a szerény 1 GB RAM, amivel megáldott engem az anyatermészet (Butcher szerint 4 GB-t is sikerült gond nélkül kiakasztania :D). És hát a rectangle finder megtette nekem ezt a szívességet. Akit nem érdekel a blabla, az tekerjen le, akit érdekel, az figyeljen.

Mi is volt a probléma? Volt egy ilyen kódrészlet:rights = [fst centroid, fst centroid + unit..right]Ezt egy úgynevezett list comprehension (ne kérdezzétek, mi ennek a magyar megfelelője, viszont, ha tudjátok, mondjátok). A list comprehension a tömbök elemeinek egy rövid megadási formája. Jelen esetben egész számokat generálnánk, méghozzá a centroid (ami egy kételemű érték) első elemétől (erre utal az fst, mint 'first') a right értékig, unit lépésközzel. Példa:fst centroid = 5
unit = 3
right = 19Ekkor a tömb így nézne ki:[5, 5 + 3, 5 + 3 + 3, ..., legnagyobbElemAmiMégKisebb19nél]vagyis[5, 8, 11, 14, 17]Mivel a következő elem (20) nagyobb lenne, mint a 19, ezért az már nem kerül bele a tömbbe.

Ez eddig mind szép és jó, ám vannak olyan esetek, amikor a right 0. Nézzük meg, mi történne ilyenkor:[5, 5 + 3, 5 + 3 + 3, ..., és ezt egészen addig, amíg el nem éri a 0-t]Tehát itt egy szép kis végtelen ciklust kapunk a nyakunkba. Elkezdi feltölteni a tömböt elemekkel, amíg le nem állítjuk a progit. Mindenesetre könnyű kis fix volt, csak a hiba okát volt nehéz megtalálni. A profiler először csak annyit mondott, hogy a rectangleFinder folyamatosan eszi a memóriát. Mikor részletesebbre állítottam, akkor már láttam, hogy a tömblétrehozás eszik sokat, aztán pár debugprinttel megbizonyosodtam arról, hogy végtelen ciklusba kerülünk. A fix egyszerű volt: ha nulla méretű telekben keresünk, akkor simán adjunk vissza egy 0x0-s téglalapot. (Úgyis újra lesz írva, és a végleges játékban terveim szerint a városgenerátor harmadik negyedik inkarnációja fog dolgozni azért, hogy a játékosok elégedettek legyenek :D)

És akkor kép a városról a szigeten: