[voikko] Mozvoikon Linux-jakeluversiota päivitetty ( myös yleistä Fedora-asiaa)

[Harri Pitkänen]

On Saturday 24 May 2008, Ville-Pekka Vainio wrote:
> Erityisesti keskustelua aiheutuu nyt siitä, että Fedorassa yhdistettiin
> oikolukusanastoja hunspellin alle äskettäin ja Voikko-pakettien tekeminen
> periaatteessa rikkoo tätä. Vielä taustoista sen verran, että Christopher
> Aillon on tietääkseni upstream-Firefox-kehittäjä, joten Fx-laajennos ehkä
> sikäli erityisesti kiinnostaa. Jos joku haluaa kommentoida, niin saattaa
> olla, että listalle on liityttävä ensin.

En viitsi kommentoida suljetuille listoille. Tuota architecture-sivua voisin 
kyllä täydentää, on tainnut tulla kirjoitettua liian kiltisti Hunspellista :) 
Sanotaan nyt asiat vähän suoremmin, kun ollaan suomenkielisellä listalla. 
Tosiasia on se, että ilman merkittäviä muutoksia Hunspelliin olisi täyttä 
ajan haaskausta edes yrittää toteuttaa sen avulla samaa, mihin nyt olemme 
malagan avulla päässeet. Ja menettäisimme tavutuksen (ja mahdollisuuden 
toteuttaa kieliopin tarkistinta seuraavan kolmen vuoden kuluessa) siinä 
samalla, mikä saattaisi hiukan harmittaa käyttäjiä.

Otetaan nyt esimerkiksi seuraava bugi Hunspellistä:
http://sourceforge.net/tracker/index.php?func=detail&aid=1428496&group_id=143754&atid=756395

Raportoin tuon yli kaksi vuotta sitten. Korjaus luvattiin "parissa 
kuukaudessa". Sen sijaan ainoastaan segfaultti korjattiin (vuoden kuluttua). 
Ja nyt kun kokeilin tuota samaa testitapausta uusimmalla Hunspellilla 
(1.2.2), niin arvatkaapa mitä tapahtuu...

  > abcabcs
  Segmentation fault

Että sillä tavalla. Tietysti aina voi sanoa, että bugit pystyy korjaamaan. 
Mutta minä todella yritin tuon itsekin aikoinaan korjata, mutta en pystynyt. 
Taidot eivät riittäneet. No, pari vuotta vanhempana ja viisaampana voisin 
kokeilla uudelleen, joten katsotaanpa mitä Valgrind sanoo...

==23263== Invalid read of size 1
==23263==    at 0x4E398D0: AffixMgr::compound_check_morph(char const*, int, 
short, short, short, short, hentry**, char, char**, char*) 
(affixmgr.cxx:2128)
==23263==    by 0x4E481B1: SuggestMgr::suggest_morph(char const*) 
(suggestmgr.cxx:1530)
==23263==    by 0x4E4242B: Hunspell::analyze(char***, char const*) 
(hunspell.cxx:1340)
==23263==    by 0x400E95: main (analyze.cxx:62)
==23263==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Huomatkaa rivinumerot! Nyrkkisääntönä mielestäni hyvin suunniteltujen 
lähdekooditiedostojen tulisi olla pääsääntöisesti alle tuhannen rivin 
mittaisia. No tyylinsä kullakin. Katsotaanpa, mitä affixmgr.cxx:2128 pitää 
sisällään. Ensinnäkin, tuo tiedosto on kokonaisuudessaan hulppeat 4115 riviä 
pitkä. Metodi compound_check_morph on "vain" 451 riviä pitkä. Mutta tuon 
koodin kauheutta ei voi täysin arvostaa näkemättä sitä itse, joten laitoin 
sen nyt oikein kokonaisuudessaan nähtäville:
  http://www.puimula.org/htp/hunspell/affixmgr.cxx
tuosta metodista voi ihailla mm. seuraavanlaisia insinööritaidon helmiä:

            oldnumsyllable2 = numsyllable;
            oldwordnum2 = wordnum;

// LANG_hu section: spec. Hungarian rule
            if ((rv) && (langnum == LANG_hu) && (TESTAFF(rv->astr, 'I', 
rv->alen)) && !(TESTAFF(rv->astr, 'J', rv->alen))) {
                numsyllable--;
            }
// END of LANG_hu section
            // increment word number, if the second root has a compoundroot 
flag
            if ((rv) && (compoundroot) &&

Siis kieliriippuvaa koodia sotkettu muutenkin yli 400-rivisen metodin sisään. 
Kyllähän tuolla tavalla toki voi saada aikaan jotain, joka toimii hyvin 
unkarin kielellä, mutta siitä ei voi mitenkään yleistää, että koodi toimisi 
samaan tapaan suomen kielellä, jos jo perusalgoritmit sisältävät 
kielikohtaisia maagisia toimintoja. Tämä ei tosiaankaan ole yksittäistapaus:

  $ cat affixmgr.cxx | grep LANG_hu | wc -l
  26

Ei mikään ihme, että Hunspellia kehittää yksi ihminen. Tuskin tuota koodia 
kovin mielellään kukaan muukaan vakavasti haluaisi kehittää. Hunspellilla ei 
myöskään ole julkista versionhallintajärjestelmää, joten kenenkään on 
käytännössä mahdotonta löytää selitystä sille, miksi jossain kohdassa koodia 
tehdään jotain tiettyä tarkistusta ja mihin se liittyy.

Ja yllä oleva bugi ei ole mikään akateeminen yksityiskohta. Se käytännössä 
estää yhdyssanojen järkevän morfologisen analyysin, jota tarvittaisiin, jos 
haluttaisiin toteuttaa tavutustoiminto Hunspellin päälle.


Toki on totta, että tämä on yleinen ongelma muussakin akateemisesta maailmasta 
tulevassa koodissa. Ei malagallakaan ole julkista 
versionhallintajärjestelmää, silläkin on vain yksi kehittäjä ja koodissa on 
paljon merkkejä siitä, että se on kirjoitettu enemmän tutkimustyökaluksi kuin 
käytettäväksi tuotantojärjestelmissä (mm. rankka globaalien muuttujien 
käyttö, joka juurikin estää koodin säikeistetyn käytön). Mutta malaga toimii, 
ja sen on selvästi koodannut ihminen, joka algoritmien osalta todella tietää 
mitä tekee. Itse LAG-jäsentimestä ei ole tämän viimeisen reilun kahden vuoden 
aikana löytynyt muistini mukaan kuin yksi ainoa bugi, ja sekin muistaakseni 
toukokuussa 2006.

Malaga on myös melko hyvin optimoitua koodia. Se ei siis ole sinällään hidas, 
hitaus johtuu käyttämästämme kieliopista, joka on monimutkainen. Tämä 
monimutkaisuus tulisi väistämättä eteen myös Hunspell-toteutuksessa, ja on 
toisaalta pitkälti korjattavissa malaga-toteutuksessa, jos todella olisi 
tärkeää saada siitä tehokkaampi (käytännössä kukaan ei minulle ole valittanut 
oikoluvun hitaudesta, parempia korjausehdotuksia kyllä voisimme saada, jos 
analyysi olisi tehokkaampaa). Olen tehnyt vertailuni englanninkielisen 
hunspell-sanaston ja Voikon välillä. Tässä vertailussa hunspell oli 
muistaakseni kymmenen kertaa nopeampi, mutta kuten sanottu, nämä eivät ole 
vertailukelpoiset sanastot.

Lisäksi tuolla www-sivulla on myös mainittu, että jos malagasta luovumme, 
siirrymme todennäköisesti johonkin yleisesti käytettyyn ja "oikeiden" 
ammattilaisten käyttämään teknologiaan, kuten äärellisiin automaatteihin 
(joihin muuten Soikkokin perustui). Tällaistakin teknologiaa kun on nykyään 
(toisin kuin pari vuotta sitten) GPL-lisenssillä saatavissa, ja aivan kaikki 
ei välttämättä edes ole patentoitu :) Helsingissähän tämän parissa jo 
vakavasti puuhataan, kuten talvella tällä listalla on ollut puhetta. Myös 
Hunspellin kehittäjä tuntuu tietävän, että nykyinen Hunspellin toteutus olisi 
voitu tehdä täysin eri tekniikalla, jos lisenssiltään sopivia työkaluja olisi 
silloin ollut olemassa (tähän artikkeliin osoittava linkki sivullamme on 
näemmä rikki tällä hetkellä):
  http://mokk.bme.hu/archive/nemeth04hunmorph

No niin, eiköhän tässä ole perusteita. Jos jotain konkreettista haetaan, eli 
mitä hunspellilla ei voi tehdä ja mitä välttämättä suomessa tarvitsisimme, 
niin muistini mukaan ainakin silloin kaksi vuotta sitten ongelma oli, että 
jos vaikkapa adjektiivista johdetaan automaattisesti substantiivi, Hunspell 
ei tarjonnut mitään menetelmää, jolla yhdyssanan muodostuksessa tätä 
johdettua substantiivia olisi voitu käsitellä substantiivina. Melkoinen 
ongelma suomen kielessä, mutta en tosiaankaan varmasti tiedä, onko tuo 
rajoitus edelleen olemassa nykyisessä Hunspellin versiossa.

Harri