Qt:n asennus Ubuntussa

[mattiaalto]

Minulla on kaksi läppäriä käytössäni, eka mummolassa ilman nettiä, molemmissa Ubuntu 8.10, englannin kielisiä.

Ohjelmointi pitäis saada taas pitkästä aikaa alulle, eka kertaa Linuxissa.

Ekaan asensin Qt:n IDE:n imuroituani asennustiedoston qt.nokia.com sivuilta toisella koneella.
Asennuksen jälkeen tuli ilmoitus siitä että PATH:n pitäs laittaa qt:n polku.
Missä tiedostossa Ubuntussa määritetään PATH ja kuinka sitä pääsee muuttamaan?
Löytyykö kääntäjät yms vakio Ubuntusta, vai pitääkö ne asentaa erikseen?

Toiseen asensin, ilmeisesti vanhempaa perua olevan Qt 4 Designerin, 4 Asistantin ja 4 Linguistin Ubuntun omalla Add/Remove Applications toiminnolla.
IDE:ä, koodieditoria jne. ei ole ollenkaan... Vanha Trolltechin aikuinen linkki qt:n sivuille.... Miksi?

[Tomin]

Tuo uudempi systeemi on niin uusi ettei sitä varmaankaan sen takia löydy 8.10:stä. Se kun on jo vuoden vanha ja tuo Nokia Qt:n (tai siis Trolltechin) ostos ja systeemit eivät ole ihan niin vanhoja (ilmeisesti).

Enpä tiedä missä PATH määritellään, mutta itse ainakin lisäsin rivin (yhteen oman hakemiston, johon olen joitakin scriptejä laittanut) ~/.bashrc-tiedostoon "export PATH=$PATH:/minne/sitten/haluatkaan" (ilman lainausmerkkejä vaikka loppuun).

Toivottavasti joku osaa kertoa mistä paketeista nuo kääntäjät löytyy ja tietysti mitäs kieliä meinasit käyttää (C++ ehkä?)?

[nm]

Löytyykö kääntäjät yms vakio Ubuntusta, vai pitääkö ne asentaa erikseen?

build-essential -metapaketilla saat perusroinat (gcc/g++ ja libc-headerit).

Koodia: [Valitse]

sudo apt-get install build-essential

[mattiaalto]

Niin, itse asiassa asensin eka koneseen Qt:n sivuilta imuroidun paketin:

Qt SDK: Complete Development Environment

Qt SDK includes the tools you need to build cross-platform applications with Qt in a single install.
    * Qt libraries
    * Qt Creator IDE
    * Qt development tools

Luulisi kumminkin että Ubuntu päivittää ohjelmalähteitä vaikka itse käyttistä ei päivitetää uuteen versioon.
Joskus viime talvenahan se oli kun Nokia osti Trolltechin ja homma sai uutta voimaa ja vauhtia.

Ohjelmointikielenä C/C++, sehän on Qt:n natiivi kieli. Python ei tässä vaiheessa kiinnosta.
Oisin tyytyväinen kun Windowsista Linuxiin siirtyminen menisi kohtalaisen kivuttomasti.
Mitään ohjelmia en ole kääntänyt komentoriviltä sitten 80-luvun.

No, pitää nyt ainakin ne kääntäjä kamat asentaa komentoriviltä, kiitos vastanneille.

[nm]

Luulisi kumminkin että Ubuntu päivittää ohjelmalähteitä vaikka itse käyttistä ei päivitetää uuteen versioon.
Joskus viime talvenahan se oli kun Nokia osti Trolltechin ja homma sai uutta voimaa ja vauhtia.

Vanhan jakeluversion ohjelmalähteisiin tulee vain bugi- ja tietoturvakorjauksia.

No, pitää nyt ainakin ne kääntäjä kamat asentaa komentoriviltä, kiitos vastanneille.

Voi ne toki asentaa myös graafisella pakettienhallinnalla. Saman paketin sieltäkin voi asennella.

[Tomin]

Luulisi kumminkin että Ubuntu päivittää ohjelmalähteitä vaikka itse käyttistä ei päivitetää uuteen versioon.
Joskus viime talvenahan se oli kun Nokia osti Trolltechin ja homma sai uutta voimaa ja vauhtia.

Uudempia ohjelmia varten pitää päivittää Ubuntu. Kuten nm kirjoitti niin niihin vanhoihin versioihin ei tosiaan tule kuin bugi ja tietoturvakorjauksia eli ei uusia ominaisuuksia.

[buffalognu]

Kokeilin itse tuota pythonia Qt:n kanssa - tavattoman hidasta syntyi verrattuna vastaavaan c++-ohjelmaan. Ero kymmeniä kertoja esim jossain taulukkolaskentapohjassa. Python varmasti sopii johonkin hallinnolliseen ohjelmointiin.
Mielestäni 3D-työpöytä on omiaan tällaiseen hommaan: Terminaali yhdelle sivulle , editorit toiselle assistantin kanssa ja muut releet kolmannelle.
Kääntäminen on sitten ensimmäisen maken jälkeen pelkkää nuoliylös ja enter.

 Terveisin

[snifi]

Kokeilin itse tuota pythonia Qt:n kanssa - tavattoman hidasta syntyi verrattuna vastaavaan c++-ohjelmaan. Ero kymmeniä kertoja esim jossain taulukkolaskentapohjassa.

Voisitko antaa esimerkkiohjelmasi kokeiltaviksi?

[buffalognu]

Kokeilin itse tuota pythonia Qt:n kanssa - tavattoman hidasta syntyi verrattuna vastaavaan c++-ohjelmaan. Ero kymmeniä kertoja esim jossain taulukkolaskentapohjassa.

Voisitko antaa esimerkkiohjelmasi kokeiltaviksi?

Ikävä kyllä sitä ei ole enää olemassa, mutta se oli muokattu noista Qt:n taulukkolaskenta demopohjista ja taulukon koko jotain 1000 riviä 50 saraketta.
Nyt tulee mieleen että sulla on hanskassa jokin kikka kuus - Kerro ihmeessä.

[snifi]

Ikävä kyllä sitä ei ole enää olemassa, mutta se oli muokattu noista Qt:n taulukkolaskenta demopohjista ja taulukon koko jotain 1000 riviä 50 saraketta.

Ensimmäinen ajatus mikä minulla tulee, niin on siinä, että alustat tai piirrätät solut jotenkin eksoottisella tavalla. Pythonin Qt-kirjastot käyttävät periaatteessa käännettyjä C++-komponentteja, joten niihin liittyvissä rutiineissa ei pitäisi olla kovin suuria suorituskykyeroja. Qt:n taulukoihin liittyy se Qt:lle tyypillinen tapa käsitellä asioita malli-näkymä-delegaatit -hierarkioiden kautta, ja jos tähän lisää jotakin hierarkiaan kuulumatonta, niin silloin tietenkin joudutaan käännettyjen komponenttien vaikutusalueelta Pythonin dynaamisten muuttujien käsittelyyn. Se on yleensä hidasta. En kuitenkaan tiedä, riittääkö oma Qt:n arkkitehtuurin tuntemukseni vielä auttamaan tässä asiassa, mutta yleensä ottaen en ainakaan itse ole kokenut PyQt:tä juurikaan hitaammaksi vastaaviin C++:lla toteutettuihin käyttöliittymiin verrattuna. (Itse en tosin ohjelmoi C++:lla, joten siksi tarvittaisiin joku toinen tekemään sama ohjelma vertailtavaksi.)

[mrl586]

Python on tulkattava ohjelmointikieli. Tulkattavalla ohjelmointikielellä toteutetut ohjelmat ovat yleensä hitaampia kuin käännettävällä ohjelmointikielellä tehdyt ohjelmat.

[snifi]

Python on tulkattava ohjelmointikieli. Tulkattavalla ohjelmointikielellä toteutetut ohjelmat ovat yleensä hitaampia kuin käännettävällä ohjelmointikielellä tehdyt ohjelmat.

Tyypillinen Python Qt-sovellus sisältää sekä tulkattavia että käännettyjä osia. Jos otetaan esimerkkinä sadan rivin taulukkolaskentaohjelma, jossa on kymmenen funktiokutsua, niin se mitä tapahtuu, kun kirjoitat konsoliin "python taulut.py", on jotakuinkin seuraavaa:

-- Ohjelman funktiokutsurakenne käännetään.
-- Kutsuttaessa funktioita ohjelmasta, funktioiden suoritus tulkataan.
-- Kutsuttaessa graafisia Qt-komponentteja, kutsutaan C++:lla käännettyjä osioita.
-- Käsiteltäessä Qt:n tietorakenteita, kutsutaan C++:lla käännettyjä osioita.
-- Kutsuttaessa muita valmiita kirjastorutiineita, kutsutaan yleensä C:llä käännettyjä osioita.

Jos taas ajattelet tyypillistä C-kielistä ohjelmaa, niin myös siinä on usein tulkattavia piirteitä:

-- Komentoriviparametrit tulkataan.
-- Asetustiedostot tulkataan, tekstisyötteet tulkataan.
-- Käyttöliittymän käyttäjälle muokattavissa olevat osat tulkataan.

[buffalognu]

Python on tulkattava ohjelmointikieli. Tulkattavalla ohjelmointikielellä toteutetut ohjelmat ovat yleensä hitaampia kuin käännettävällä ohjelmointikielellä tehdyt ohjelmat.

Näin minäkin sen tulkitsin ( tosin hitaasti ). Ei mulla mitään pythonia ja basicia vastaan ole, ne kun on helposti opittavissa. Mutta kun C:lle sitten vielä löytyi parempi dokumentaatio ja homma toimi reilusti nopeammin, niin valinnan teko ei ollut vaikeaa.
Se miten tämän taulukon tein , ja teen edelleenkin on kaksi sisäkkäistä for-looppia.
Pythonilla on tehty hienoja sovelluksia ja käytän niitä mielelläni (esim pyrenamer) . Paljon on kuitenkin sellaista prosessori-intensiivistä kamaa jota ei kannata tulkilla edes yrittää. Pari vuotta sitten tein MS-exceliin sovelluksen jossa hyödynnettiin rankasti lineaarista korrelaatiota. Aluksi tein sen koodaamalla basicilla looppi-loopilta, kunnes huomasin että valmis funktio oli olemassa excelin omissa funktioissa.  Vaihdoin noihin excelin omiin funktioihin ja nopeusero oli jotain 100+ kertainen. Tulkki on tulkki ja jos sillä haluaa tehdä nopeeta, niin on tarvis tutkia toteutustapaa syvällisesti.

Terveisin


Että silleen

[snifi]

Paljon on kuitenkin sellaista prosessori-intensiivistä kamaa jota ei kannata tulkilla edes yrittää.

Silloin käännetään komponentti C:llä ja kutsutaan sitä Pythonista. Suurin osa Pythonin rutiineista on käännettyjä C-rutiineja, Pythonin peruskirjasto lähes kokonaan. Samoin Qt:n komponentit ovat C++:lla käännettyjä komponentteja joihin luodaan rajapinta Pythonilla. Niiden suorittamisessa ei käytännössä ole nopeuseroa. Toistaiseksi Python on suunniteltu nopeaa ohjelmakehitystä silmälläpitäen, ja algoritmien kääntämiseen käytetään siksi olemassaolevia työkaluja, eli C- ja C++ -kääntäjiä. Kokonaisen kääntäjäympäristön siirtäminen Pythoniin on aikaa vievä toimenpide, mutta eiköhän sekin lähivuosina tulla näkemään. Silloin C ja C++ -kääntäjät jäävät kokonaan tarpeettomiksi.

[nm]

Toistaiseksi Python on suunniteltu nopeaa ohjelmakehitystä silmälläpitäen, ja algoritmien kääntämiseen käytetään siksi olemassaolevia työkaluja, eli C- ja C++ -kääntäjiä. Kokonaisen kääntäjäympäristön siirtäminen Pythoniin on aikaa vievä toimenpide, mutta eiköhän sekin lähivuosina tulla näkemään. Silloin C ja C++ -kääntäjät jäävät kokonaan tarpeettomiksi.

Kääntäminen etukäteen tai JIT-tulkilla toki auttaa huomattavasti, mutta ei korvaa C/C++:aa ja symbolista konekieltä kaikkein suorituskykykriittisimmän koodin kirjoittamisessa, kuten kuvan- ja signaalinkäsittelyssä. Näissä algoritmeissa pitää usein välttää oliorakenteet ja automaattinen muistinhallinta kokonaan, jottei ylimääräinen muistin käpistely hidasta laskentaa.

[snifi]

Kääntäminen etukäteen tai JIT-tulkilla toki auttaa huomattavasti, mutta ei korvaa C/C++:aa ja symbolista konekieltä kaikkein suorituskykykriittisimmän koodin kirjoittamisessa, kuten kuvan- ja signaalinkäsittelyssä. Näissä algoritmeissa pitää usein välttää oliorakenteet ja automaattinen muistinhallinta kokonaan, jottei ylimääräinen muistin käpistely hidasta laskentaa.

Pythonin Qt-komponenttikirjasto on toteutettu C++:lla. Se on käännetty ja siihen on luotu rajapinta Pythonille. Pythonin Qt-kutsut ovat siten käännettyjen rutiinien kutsuja. Käyttöliittymäkomponenttien tarkoitus on juuri antaa ohjelmoijalle riittävät työkalut käyttöliittymän hallintaan ilman, että tarvitsee nähdä huolta suorituskriittisten rutiinien ohjelmoimisessa. Kuvankäsittelyyn ja multimedian käsittelyyn on taas omat kirjastonsa, jotka aivan samaan tapaan on koodattu C:llä tai C++:lla, ja niihin on sitten luotu rajapinta Pythonille. Myös kaikki Pythonin peruskirjastojen rutiinit ja tietorakenteet on käytännössä toteutettu C-kirjastojen avulla.

Mitään periaatteellista syytä sille, miksi Python ei voisi kokonaan korvata C:tä ja C++:aa ei ole olemassa. Syyt ovat käytännölliset. C/C++ -kääntäjät ovat vuosien mittaan optimoitu tehtäviensä suorittamiseen. Niitä ei käytännön syistä kannata luoda uudestaan, sillä helpompi tapa on kutsua näitä käännettyjä kirjastoja rajapintojen avulla Pythonista. Pythonin parissa on toki kehitystyötä, joka tähtää syntaksipuiden ja syntyneen konekielen hallintaan ja optimointiin suoraan Pythonista, mutta ainakin toistaiseksi saman asian toteuttaminen C-kirjastona on ohjelmoijan kannalta tuottoisampi tapa.

[nm]

Pythonin Qt-komponenttikirjasto on toteutettu C++:lla. Se on käännetty ja siihen on luotu rajapinta Pythonille. Pythonin Qt-kutsut ovat siten käännettyjen rutiinien kutsuja. Käyttöliittymäkomponenttien tarkoitus on juuri antaa ohjelmoijalle riittävät työkalut käyttöliittymän hallintaan ilman, että tarvitsee nähdä huolta suorituskriittisten rutiinien ohjelmoimisessa. Kuvankäsittelyyn ja multimedian käsittelyyn on taas omat kirjastonsa, jotka aivan samaan tapaan on koodattu C:llä tai C++:lla, ja niihin on sitten luotu rajapinta Pythonille. Myös kaikki Pythonin peruskirjastojen rutiinit ja tietorakenteet on käytännössä toteutettu C-kirjastojen avulla.

Tiedän, enkä ottanut mitään kantaa kirjastojen käyttöön vaan ainoastaan viittaamaani väitteeseen.

Mitään periaatteellista syytä sille, miksi Python ei voisi kokonaan korvata C:tä ja C++:aa ei ole olemassa.

Jos Pythoniin lisätään tuki matalan tason ohjelmoinnille, kieltä ja sen keskeisiä periaatteita pitäisi muuttaa hyvin radikaalisti. Kuten totesit, tämä ei olisi kovin järkevää käytännöllisistä syistä, mutta ei myöskään kielen kehityksen kannalta. Toisaalta esimerkiksi Googlen Go on koneistonsa osalta hieman kevyempi ja se sijoittuu johonkin Pythonin ja C:n välimaastoon, mutta siinäkään ei ole mahdollisuutta suorittaa matalan tason operaatioita manuaalisesti.

Omasta näkökulmastani ennustan, että C/C++ tulee säilyttämään asemansa suorituskykykriittisen tai laitteistoläheisen koodin tuottamisessa vielä hyvin pitkään, eikä mitään varteenotettavia vaihtoehtoja edes ole tällä hetkellä näköpiirissä.