Huijaako geditin kehittäjät ihmisiä?

Kuulostaa suurelta työltä. Mitenkähän kannattaisi alkaa selvittämään koodin rakennetta ja opetella C:tä siten, että saisi fixattua bugin? Toistaiseksi olen tehnyt C:llä vain konsoliohjelmia, ja tuollaisten grafiikoiden ja hiirikirjastojen käytöstä ei ole kokemusta

ihmettelijä kirjoitti:

Kuulostaa suurelta työltä. Mitenkähän kannattaisi alkaa selvittämään koodin rakennetta ja opetella C:tä siten, että saisi fixattua bugin? Toistaiseksi olen tehnyt C:llä vain konsoliohjelmia, ja tuollaisten grafiikoiden ja hiirikirjastojen käytöstä ei ole kokemusta

Lue lisää

Ymmärtääkseni ongelma on luonteeltaan sellainen, että muu käyttöliittymä ja tekstilaatikkokomponentti pyörivät samassa säikeessä ja tekstilaatikkokomponentissa on joku optimoitu silmukka mikä ei luovuta aikaa muulle ohjelmalle tms. tai se GtkTextView komponentti on tässä tapauksessa vaan viallinen.

Ongelma sitten onkin se, että sitä GtkTextViewiä ei välttämättä voi korjata ilman, että se vaikuttaisi kaikkiin muihin sovelluksiin mitkä käyttää sitä. Pitäis sitten vähintäänkin forkata se erikseen juuri tätä Gedittiä varten tai tehdä uusi komponentti.

ihmettelijä kirjoitti:

Kuulostaa suurelta työltä. Mitenkähän kannattaisi alkaa selvittämään koodin rakennetta ja opetella C:tä siten, että saisi fixattua bugin? Toistaiseksi olen tehnyt C:llä vain konsoliohjelmia, ja tuollaisten grafiikoiden ja hiirikirjastojen käytöstä ei ole kokemusta

Lue lisää

Luulisin, että ison koodin ylläpidossa kannattaisi ottaa yhteyttä kehittäjiin. Riittääkö bugin korjaus vai kannattaako koodia refaktoroida helpommin ylläpidettäväksi. Kielimalleilla ei ehkä pysty korjailemaan luotettavasti vielä bugeja, mutta sillä voinee pyytää analyysiä, mitkä voisivat olla projektin pahimmat pullonkaulat ja mihin suuntaan sitä voisi kehittää?

Anonyymi kirjoitti:

Luulisin, että ison koodin ylläpidossa kannattaisi ottaa yhteyttä kehittäjiin. Riittääkö bugin korjaus vai kannattaako koodia refaktoroida helpommin ylläpidettäväksi. Kielimalleilla ei ehkä pysty korjailemaan luotettavasti vielä bugeja, mutta sillä voinee pyytää analyysiä, mitkä voisivat olla projektin pahimmat pullonkaulat ja mihin suuntaan sitä voisi kehittää?

Lue lisää

Heh heh.. vastasit sitten yli 10 vuotta vanhaan ketjuun - kannattaa ainakin tarkistaa nykyinen versiohallinta ennen kuin alkaa korjailla vanhaa koodia. Kehittäjätkin ehtineet varmasti vaihtua 2-3 kertaa tuossa ajassa.

Näköjään katessakin on joku bugi verrattuna nanoon. Ei avautunut kunnolla kun kokeilin Python-koodin:

file = open("newfile.txt", "w")

text="12"*1000000
file.write(text)
file.close

Ei niitä kauheasti varmaan tarvita. Tuolla on joku ohjelmointiprojekti, jossa voi tällaista tarvita: http://www.ohjelmointiputka.net/posti.php?tunnus=mpera . Mutta ilmeisesti tällaisia varten editorit tulisi tehdä siten, että alussa ei avata koko tiedostoa vaan alkupätkä ja rivejä ei lueta kokonaan vaan joku tietty osa, ja kursorin liikkuessa osan yli luetaan taas uusi pätkä. No, en ole ohjelmoija, en tiedä miten he tekevät asian omissa ohjelmissaan.

Yhtä hyvin voi kokeilla esim. libreOfficella, mitä tapahtuu, kun tiedostossa on puoli miljoonaa 3 merkin mittaista riviä: Tiedoston avaaminen kestää ja editointi ei välttämättä onnistu - tyylin vaihto fontille voi kestää useita minuutteja. Samaan aikaan Emacs avaa em. tiedoston sekunnissa. Samaisen libren taulukkolaskennan import-toiminto muuten voi kaatua tuohon rivimäärään, jos koneessa ei ole tarpeeksi muistia.

Jos geditillä pystyy n. sivun mittaisen tekstin kirjoittamaan niin sehän toimii riittävästi! Pidemmät tekstit voi kirjoittaa jollain muulla n. 2000 tekstinkäsittelyohjelmasta, mitä maailmalta löytyy. On kirjoittajan ongelma, jos hän hukkaa tekstiä tekemällä järjettömiä.