Lazarus 0.9.2.8 (diskuse)

[Amarok]

Tomu rikam dobra zprava o nove verzi
Ten projekt je nahodou dost dobry, kdysi jsem delal par veci v Delphi a v linuxu neco takoveho chybelo jako open source. Jenze v te dobe mel Lazarus dost velke mezery, to bylo ale tak pred 5 lety. Object Pascal / FreePascal je hodne pekny jazyk, mohu doporucit. Nevi nekdo, jak je to s debuggerem? Driv to byl taky problem, protoze gnu debugger si s Pascalem moc nerozumnel.

[PetrHL]

Do IDE je integrované gdb. V konfiguraci si k němu nastavíte cestu a to je vše. Ladění je integrováno do IDE. V editoru dáte breakpoint, spustíte app (F9) a provádění se zastaví na zadaném místě. Pak můžete krokovat (F7 nebo F8). IDE obsahuje i watch list atd. Mají to udělané velice dobře.

[Amarok]

Tak to je pokrok, prave jak jsem to kdysi testoval, tak integrovany debugger byl teprve v planu. Skoda, ted uz se totiz k nemu vracet nebudu, rad ale vzpominam...

[AHAHA]

Nechci rozpoutat flame, ale rikat o Pascalu, ze je to pekny jazyk, no nevim. Pred mesicem jsem musel zapasit s BP7.0, kdyz jsem tehdejsi kamaradce (a nynejsi pritelkyni) pomahal se zapoctakem a bylo to fakt utrpeni.

Syntaxe muze byt veci vkusu, to jo. Ale to, ze Pascal (aspon ten z BP7) neumi dynamickou alokaci pameti a uplne cokoli dynamickeho se musi resit pres spojaky, ktere je pak potreba definovat pro kazdy datovy typ cele znovu (a nebo umirat pri silenem pretypovanim), tak to mu neodpustim.

Spis nez ale na Pascal se zlobim na ceske skolstvi (spatnych/zastaralych jazyku je ostatne hodne) - lez, ze Pascal je jazyk vhodny pro ucebni ucely atp. To mozna plati ve srovnani s Ceckem, ale to je tak vsechno. No a ze Pascal je stale uvodnim ucebnim jazykem na MFF, to uz je neodpustitelne.

Sorry za vykrik do tmy, ktery se moc FreePascalu netyka (ktery nejspis bude asi pokrocilejsi nez BP7), ale potreboval jsem si ulevit. Stale doufam, ze Borland Pascal vymre, ale zatim se ke mne stale vraci ...

[Radek Miček]

Ale to, ze Pascal (aspon ten z BP7) neumi dynamickou alokaci pameti a uplne cokoli dynamickeho se musi resit pres spojaky

On nemá procedury New a Dispose?

[Ladicek]

Ale jasně že má, autor v tom zřejmě nemá moc jasno, protože už ta jediná věta odporuje sama sobě. A já už doufal, že by se téhle diskusi mohli antiPascalisti vyhnout…

[Radek Miček]

už ta jediná věta odporuje sama sobě

Když by bylo třeba, šlo by realizovat spojový seznam v poli (dostatečně velkém), takže by se pak nemusela používat dynamická alokace paměti 

[AHAHA]

Mozna sem se blbe vyjadril. New a dispose BP ma a tedy dynamicky alokovat pamet umi.

Co ale neumi je dynamicka alokace pole - jeho delka musi byt znama pri kompilaci. No a nekonstantne velke pole se pak musi resit jinak (napr. pres ty spojaky).

[Radek Miček]

Co ale neumi je dynamicka alokace pole

Ale to také umí. Třeba takto:

type
  TCisArr = array[1..HorniMez] of integer;
  PCisArr = ^TCisArr;
var
  pole : PCisArr;

A pak na vhodném místě zaalokovat pamět pro prvky, které jsou skutečně třeba:

GetMem(pole, zadanyPocetPrvkuPole * sizeof(integer)); 

[AHAHA]

Nemam ted BP po ruce, takze to nezkusim ... pamatuju si ale, ze mi kdosi poradil presne tuhle funkci - v BP jsem ji pak zkusil v helpu (ktery je jinak docela obsahly), ale zminka o ni nebyla ... tak jsem si rekl, ze to bude asi zalezitost Delphi.

Jeste pred tim jsem tu dynamickou alokaci pole zkousel vygooglovat, ale jedine, co jsem nasel bylo neco ve smyslu "deklarujte pole s velikosti nula, vypněte range checking a klidne do nej zapisujte ...".

[Tomáš Bžatek]

Co by clovek cekal od 17 let stareho produktu...

Zaklad ObjectPascalu uz tam samozrejme byl a sla s tim delat spousta krasnych veci, ale az prvni Delphi v roce 1995 prineslo znatelne zlepseni moznosti jazyka.

[AHAHA]

Mne je to jasne, jen me sere to, ze ceske skolstvi furt na BP lpi ...

[Radek Miček]

Já v helpu mám jak GetMem tak FreeMem.

[Amarok]

To jsou presne duvody, proc plno lidi nema v oblibe Pascal. Nemuzete prece srovnavat 20 let stary BP 7 s ObjectPascalem/FreePascalem. Mezi tim jsou dimenze. Vse co popisujete uz umeji oba popisovane jazyky snad 10 let (nebo aspon ObjectPascal, jelikoz FreePascal skoro vse jen postupne kopiruje a s vyvojem byval tehdy pozadu).

Ze se dodnes pouziva BP7 na skolach, tomu se fakt divim, zaspali dobu. Ne ze by to nefungovalo, ale kdyz student vyjde ze skoly, tak s tim jazykem dal uz nic nesvede a musi se ucit zase neco jineho.

[default]

Nechci rozpoutat flame, ale rikat o Pascalu, ze je to pekny jazyk, no nevim. Pred mesicem jsem musel zapasit s BP7.0, kdyz jsem tehdejsi kamaradce (a nynejsi pritelkyni) pomahal se zapoctakem a bylo to fakt utrpeni.

Uděláš nejlíp, když se budeš namísto Borland Pascalu věnovat přítelkyni.

Spis nez ale na Pascal se zlobim na ceske skolstvi (spatnych/zastaralych jazyku je ostatne hodne) - lez, ze Pascal je jazyk vhodny pro ucebni ucely atp. To mozna plati ve srovnani s Ceckem, ale to je tak vsechno. No a ze Pascal je stale uvodnim ucebnim jazykem na MFF, to uz je neodpustitelne.

A já si zase myslím, že Pascal (třeba zrovna ten Borland Pascal) je skvělý pro výuku. Podle mě je mnohem lepší než Delphi. Tuším, že to byla verze 6, kde hoši začali motat typy a pointery. Škoda. Nebo třeba klíčové slovo packed. No já nevím. Zletej Borland Pascal.

Stale doufam, ze Borland Pascal vymre, ale zatim se ke mne stale vraci ...

Vidíš. A mě třeba osobně mrzí, že umřel. Turbo Vision bylo nádherné prostředí. Dodnes neexistuje tak pěkná a elegantní alternativa. Osobně mi Pascal přijde mnohem více čitelnější než C/C++ a jejich deriváty. Ještě tak ta Java, ale i ta je trochu kryptická. Možná tak PL/SQL, které vychází z Ady… Je to holt smutný…

[AHAHA]

A já si zase myslím, že Pascal (třeba zrovna ten Borland Pascal) je skvělý pro výuku. Podle mě je mnohem lepší než Delphi. Tuším, že to byla verze 6, kde hoši začali motat typy a pointery. Škoda. Nebo třeba klíčové slovo packed. No já nevím. Zletej Borland Pascal.

No jestli je lepsi nebo horsi nez Delphi, to nevim. Ale na vyuku rozhodne dobry neni ... na to je IMHO nejlepsi nejaky objektovy skriptovaci jazyk - neco jako Python nebo PHP. Zacinat dnes s proceduralnim jazykem je IMHO velka chyba. Srovnejte si, jak na objekty reaguji lidi se znalosti Pascalu nebo C a lidi, co nikdy neprogramovali. Pro ty prvni je OOP casto nepochopitelne, pro ty druhe prirozene (aspon takova je ma osobni zkusenost). Jinak, Object Pascal toho umi celkem dost, ale je to na nej doslova naroubovano silou (treba ta dynamicka alokace pole - nejprve se deklaruje pole s konstantni delkou, pak se na nej vytvori pointer a pak se prikazem rekne, ze pole ma mit jinou velikost).

Turbo Vision bylo nádherné prostředí. Dodnes neexistuje tak pěkná a elegantní alternativa.

O tom se nepru a mam na to stejny nazor (pouzival jsem dost BC++ 3.1). Miloval jsem propracovany a okamzite pristupny help - tohle jsem videl jen tak u Visual Studia (pro C++), ale tam mi help prisel mnohem neprehlednejsi (taky mel ale mnohem sirsi zaber).

Osobně mi Pascal přijde mnohem více čitelnější než C/C++ a jejich deriváty.

To je vec vkusu a zvyku. Cteni Cecka mi nikdy nedelalo problemy (pokud je kod programovan rozumne, v Cecku se jinak da programovat absolutne necitelne).

[Ladicek]

Object Pascal toho umi celkem dost, ale je to na nej doslova naroubovano silou (treba ta dynamicka alokace pole - nejprve se deklaruje pole s konstantni delkou, pak se na nej vytvori pointer a pak se prikazem rekne, ze pole ma mit jinou velikost)

V Borland Pascalu jo, v Object Pascalu (Delphi) ne. Object Pascal má dynamická pole, tím si jsem celkem jistý, protože jsem je používal Viz například, co tak na mne vypadlo z Googlu, tady.

K té výuce: podle mě je Pascal taky výborný jazyk pro výuku. Celkem bych byl ochotný věřit, že Python by byl lepší, ale pořádně ho neznám, tak nemůžu hodnotit. Jestli mají pascalisti nebo céčkaři problém s objekty nedokážu posoudit, nic takového jsem nezaznamenal. A nějak si nejsem jistý, jestli je vhodné začínat výuku programování zrovna na OOP. Tedy úvod do programování pro neprogramátory by klidně mohl být v tom Pythonu, ti si s ním zřejmě vystačí, ale budoucím programátorům bych na začátek narval hezky SICP. Myslím to vážně.

[AHAHA]

No, AFAICR ma TP/BP od nejake verze nejakou podporu Object Pascalu. Jinak se bavim spis o vyuce neprogramatoru - vetsina programatoru se IMHO programovat naucila sama ... >> K té výuce: podle mě je Pascal taky výborný jazyk pro výuku. Par veci, ktere mi v Pascalu vadily:
- dualita PChar versus String
- nutnost forward referencovat funkce a procedury
- nutnost deklarace promennych v hlavicce funkce/procedury
- rozeznavani rozdilu mezi ^. a .
Tohle jsou veci, ktere jsou pro vyuku naprosto nepodstatne ... Mimoto bych nejradsi volil skriptovaci jazyk, aby se odstranil proces kompilace a volil bych dynamicky typovany jazyk. Takze treba ten Python je myslim docela dobra volba. Obecne cilem vyuky programovani neprogramtoru je nauceni algoritmizace a nepotrebuji znat rozdil mezi primym pristupem k datove strukture nebo pres ukazatel.
>> A nějak si nejsem jistý, jestli je vhodné začínat výuku programování zrovna na OOP.
Netvrdim, ze se ma zacinat s dedicnosti atp., ale jednoducha prace s objekty je IMHO intuitivnejsi nez proceduralni pristup.

[Amarok]

- dualita PChar versus String

Domnivam se, ze PChar vznikl jen pro programatory v C, aby se jim zjednodusilo prepisovani kodu do Pascalu. Sam jsem PChar ani jednou nepouzil, nebyl duvod, a to jsem toho programoval docela dost.

- nutnost deklarace promennych v hlavicce funkce/procedury

To je nahodou skvela vec. Deklarace promennych na ruznych mistech je akorat zdroj castych chyb. Ja dodnes (v jinych jazycich) vetsinu promennych deklaruju na zacatku, i kdyz je pouzivam az daleko pozdeji, to by si mel navyknout kazdy, kdo ma rad "uklizeny" kod.

Jinak OOP vs. procedury, jsem spis ze zacatku pro proceduralni programovani, a OOP az pozdeji. Kazdy to vidi jinak a kazdemu to leze do hlavy jinak, to je jako diskuze KDE vs. GNOME.

[AHAHA]

Domnivam se, ze PChar vznikl jen pro programatory v C, aby se jim zjednodusilo prepisovani kodu do Pascalu. Sam jsem PChar ani jednou nepouzil, nebyl duvod, a to jsem toho programoval docela dost.

Zda se mi, ze nektere funkce existovaly pouze ve variante pro PChar a pro String vubec nebyly. Pak jsem to musel nejak divne konvertovat a bylo to na zbliti.

To je nahodou skvela vec.

Muj nazor to tedy neni. IMHO by mela byt promenna deklarovana nekde pred prvnim pouzitim - je to znacne prehlednejsi (clovek vidi zaroven datovy typ, pripadny komentar a pouziti promenne). Jinak, jakym zpusobem to muze byt zdrojem chyb?

Jinak OOP vs. procedury, jsem spis ze zacatku pro proceduralni programovani, a OOP az pozdeji. Kazdy to vidi jinak a kazdemu to leze do hlavy jinak, to je jako diskuze KDE vs. GNOME.

Mne pripada, ze je pro prehlednost i budoucnost lepsi pouzivat:

pes.zastekej(kolikrat);

Misto:

zastekej(pes, kolikrat); (a nebo jsem to deklaroval takto?) zastekej(kolikrat, pes);

[Amarok]

Jinak, jakym zpusobem to muze byt zdrojem chyb?

Jednoduse z duvodu neprehlednosti u dlouheho kodu, promenne jsou pak ruzne rozhazene pres nekolik stranek, hrozi zamena promennych apod. Kdyz se uz na zacatku udela souhrnna deklarace, tak je v tom jasno. Samozrejme pokud se nejaka promenna pouziva jen napr. ve smycce for apod., tak souhlasim, ze je to spis otravne ji deklarovat nekde uplne jinde a naopak to zneprehlednuje centralni deklarace zbytecne dlouhym kodem.

Mimochodem s nastupem OOP se centralni deklarace castecne prosadila i u jinych jazyku, metody se prece deklaruji uplne na zacatku, coz je tak trochu podobne.

[AHAHA]

Jednoduse z duvodu neprehlednosti u dlouheho kodu, promenne jsou pak ruzne rozhazene pres nekolik stranek, hrozi zamena promennych apod. Kdyz se uz na zacatku udela souhrnna deklarace, tak je v tom jasno. Samozrejme pokud se nejaka promenna pouziva jen napr. ve smycce for apod., tak souhlasim, ze je to spis otravne ji deklarovat nekde uplne jinde a naopak to zneprehlednuje centralni deklarace zbytecne dlouhym kodem.

Tak to na vec mame uplne jiny nazor. Podle me je znacne neprehlednejsi nutnost deklarace na zacatku. V pripade, ze je deklarace na zacatku a clovek s promennou pracuje o par stranek nize, pak 1) nevidi datovy typ promenne (u staticky typovanych jazyku) 2) nevidi pripadny komentar osvetlujici ucel promenne 3) nemuze si byt jisty, zda v predchozich strankach promenna byla nebo nebyla pouzita.

Podle me jedine riziko je to, ze na zacatku funkce si clovek deklaruje promennou, ulozi do ni nejaky vysledek, v dalsim bloku kodu ji redeklaruje a prepise tak jeji hodnotu, ktera se pak muze hodit. Nicmene v praxi se s timto problemem nesetkavam a proto myslim vyhody jednoznacne prevazuji (minimalne pro me).

Mimochodem s nastupem OOP se centralni deklarace castecne prosadila i u jinych jazyku, metody se prece deklaruji uplne na zacatku, coz je tak trochu podobne.

Tohle souvisi s forward referencingem a ma to uplne stejny vyznam - zrychleni kompilace. Proto se vyskytuje treba v C++, ale v Jave, C# nebo PHP uz ne. A to nepocitam objektove jazyky, ve kterych pojem tridy vubec neexistuje (JavaScript napr.).

[AHAHA]

Jeste dodam, ze onen hlavickovy soubor se docela hodi pro udelani si obrazku o interface. Nicmene stejna vec se da snadno udelat dynamicky a kazde moderni IDE to umi ...

[Amarok]

Spletl jsem nazev, myslel jsem atributy, ne metody. Tudiz se neco jako centralni deklarace pouziva snad v kazdem jazyku s OOP. V procedurach je to jasne asi vec nazoru, lepsi je ale stejne nepsat moc dlouhy kod a radsi vse rozdelovat na vice procedur apod., takze prehlednost promennych pak asi velky problem vetsinou nebude.

[Jardík]

IMHO by mela byt promenna deklarovana nekde pred prvnim pouzitim

Ne! Představte si kód:

void bla()
{
  if (blablabla)
  {
    char pole[2048];
    int  pole2[4096];
    //blablabla
  }
  else
  {
    char pole[1024];
    long long pole2[6000];
    // blablabla
  }
}

V případě pascalu byste to deklaroval ve "var" všechno, musel byste to pojmenovat jinak a žralo by to zbytečně cca 2x tolik paměti, nebo byste musel alokovat dynamicky a mít tam režii navíc.

[Amarok]

Tak s takovouto konstrukci jsem se jeste nesetkal, to je podle me dost spatny styl programovani (jeste k tomu v jednom pripade "int" a ve druhem "long", to bych vubec nemichal, to je pak opravdovy zdroj moznych chyb). Kdyz predem neznam potrebnou velikost pole, tak bych to resil dynamicky.

[Jardík]

Ten long tam je schválně, aby někdo neřekl, že stačí zadefinovat to větší pole. Já long s intem rozhodně nemíchám a jsem na to dokonce dost alergický a toho, kdo to zaměňuje, bych nejradši praštil krumpáčem po hlavě. Stejně tak, jako když někdo přetypováva pointer na int/long/long long - prasárny největšího kalibru.

A mnou uvedený zápis rozhodně není o špatném stylu, takhle se to normálně dělá a na rozdíl od dynamické alokace se nemusíte starat o uvolnění, postará se o to kompilátor. A tady velikost pole znám, vím, že v prvním případě to bude tolik.

[Jardík]

Navíc tam je long long, tj. dle C99 >= 64b

[AHAHA]

Vis, co to jsou mikrooptimalizace? Usetrenych 50KB nikoho nezajima, prehlednost kodu ano. Konkretne tohle je krasny kandidat na rozdeleni na dve funkce.

Jinak trochu si v uvodu protirecis.

[Jardík]

Volání funkce je moc velký overhead (na x86 např. odečítání a přičítání k *SP, volání call a ret) Sice to může třeba kompilátor inlinovat, ale takové GCC je hloupé a dělá kraviny jako že mi nebude inlinovat 500 řádkovou funkci, když mu to poručím slovíčkem inline a ještě si dovolí hodit warning "call is unlikely and code size would grow" - to ale vím, ale přesto to chci ...

[AHAHA]

To, ze volani funkce ma overhead ma smysl resit, kdyz programujes treba kernelovy scheduler. Jinak je to sumafuk.

Fakt si myslis, ze se vyplati vubec premyslet o nejakem overheadu funkce, ktera je pri behu programu spustena treba jen jednou?

[Jardík]

No ono když ta funkce je pak volána z cyklu (třeba bilion krát), tak to opravdu nějaký ten důsledek má. Nebo např. v GTK jsou kolikrát exportovány/volány jednořádkové funkce místo použití inline (v C99 je) či makra - a když se to volá při resize okna na každý widget ...

[AHAHA]

Jo, samozrejme. GTK je knihovna na jejiz rychlosti relativne zalezi a pokud se funkce skutecne vola z cyklu, ktery bezi bilionkrat, pak ano, ma to cenu resit. Rozhodne to ale nema cenu resit v obecne diskusi o programovacich jazycich.

[aR]

Což o to, Lazarus je v pohodě, ale ten kompilátor by ještě chtělo naučit komprimovat výsledky. (Kámoš dělá pod woknama a jednoduchý formulář zabírá cca 5 MB exe soubor, oproti Delphi pár desítek KB). Na linuxu taky žádná sláva.

[Amarok]

Na kompilovane programy z freepascalu se pred lety pouzival jeden kompresor, nevzpomenu si ted na nazev. Byl dostupny dokonce i pro wokna, vytvarelo to self-extracting soubory a bezelo to dost rychle.

[Amarok]

Uz to mam, projekt stale zije: UPX, the Ultimate Packer for eXecutables.

[PetrHL]

Ano, máte pravdu. Soubory z Lazarusu jsou větší. Pomáhá odstranit debug informace příkazem

strip nazevsouboru

Velikost se sníží dost postatně. Můj program má po kompilaci nějakých 30MB a po strip to sleze na 8MB.

[Jardík]

Jenže jednookení program má v lazarusu několik mega, po stripnutí má stále něco přes mega. Jednookení program v delphi má 200k a po stripnutí taky A UPX zdržuje při startu.

[Jardík]

BTW tohle má lazarus mezi novinkami: "Refactoring of LCL reduced minimum size of executables by about 15%". Momentálně mám nějakou tak 2 týdny starou verzi ze SVN, tak zkusím tuhle stabilní.

[PetrHL]

No, u mě to moc nefunguje.

Starší verze po stripu: 7.3MB

Nová verze po stripu: 7.4MB

[Andrej Herceg]

Práve som vyskúšal vytvoriť jednoduchý program v Lazarus. Výsledný exe súbor má okolo 1.7MB a funguje so štandardnými knižnicami. Keď som naposledy skúšal Delphi, výsledný exe súbor bol menší (ak sa teda nepovedalo linkeru, aby do exe súboru vložil nejaké knižnice), ale k tomu, aby sa to spustilo, to potrebovalo dosť veľké knižnice.

[Amarok]

Myslis Kylix nebo Delphi? Ja jsem ve Woknech v Delphi zadne knihovny pro spousteni exe programu nepotreboval, proste jsem program zkompiloval, mel treba 300kb a jelo to i na jinem PC.

[AHAHA]

Docela zajimavy je fakt, ze UPX ve skutecnosti muze start zrychlit, dekomprimace je (pri nezatizenem procesoru) casto rychlejsi nez cteni z disku. Nemam k tomu zadne podklady, ale tak to kdysi vysvetlovali autori LILO, proc jsou graficke pozadi komprimovane ...

[saly]

No sláva! Nenasazení GTK2 docela dlouho bránilo v použitelnosti ... Jinak je to 0.9.28, zkuste to prosím opravit

[Tomáš Bžatek]

No ja nevim, ale Lazarus zkompilovany pro GTK2 mam uz nekolik let a bez problemu (az na par drobnosti). Jen to ted asi nastavili jako default.

[saly]

Naposled, co jsem sledoval stav implementace GTK2, tak to nebylo kompletní ... Když to teď mají jako default, tak to znamená něco jako "je to kompletní a otestovaný", což je důležitý ...

[jojo]

ale niue glade a lebo qtdesigner, proste nieco taketo

[jojo]

ale nie glade alebo qtdesigner, proste nieco taketo

[mirec]

V čom je Qt designer horší? Vždy keď som robil niečo v delphi mal som chuť nakopať toho, kto vymyslel takéto GUI.

[Andrej Herceg]

Celé to je vec zvyku. Podľa mňa je Qt Designer rovnako neprehľadný ako Delphi.

[mirec]

No v designeri viem aspoň urobiť layout. V delphi aby som urobil povedzme 3 buttony vedľa seba tak aby sa korektne resizovali tak sa môžem rovno pokrájať.

[martin knocik]

No super. Na mojej VŠ sa učíme programovať práve v Lazaruse.