Portál AbcLinuxu, 24. října 2025 20:15
Python je jazyk, který si neví rady sám se sebou (mám být objektový, funkcionální, nebo jiný?). Na druhou stranu má jednoduchou syntaxi a pyGtk vytváří přímo vývojáři Gtk. Problematická standardní knihovna (každý modul je jiná ves). Nevhodný pro aplikace náročné na výkon procesoru. Je multiplatformní.Huh?! Osobne nepoznam objektovejsi jazyk ako python.. V uvode k objektom snad kazdej prirucky o pythone je veta "Vsetko je objekt." Nepleties si to nahodou s Perlom?
Podla mna pokial GTK tak pygtk, pripadne pyglade (urcite velmi elegantne a casto pouzivane riesenie). "Problematická standardní knihovna" som bud nepochopil, alebo som si tu problematickost fakt nevsimol. A s tym vykonom je to skor teoria ako prax podla mna.. (samozrejme su miesta, kde je lepsie pouzit povedzme C, ale to je malokedy zalezitost GUI aplikacii)
Cize ja jednoznacne odporucam python, zvlast ak by slo o nejaku GNOME aplikaciu (v tom pripade uz rovno glade, ktory beztak vyzaduju dajsie aplikacie).
C ma podla mna prisernu implementaciu GTK, takze to je naopak jazyk ktory osobne neodporucam (v spojitosti s GTK), aj ked sa urcite najde vela ludi s opacnym nazorom..
6.12.2006 12:32
len(), nebo map() a reduce() je co? Já v Pythonu dělám, takže snad vím, že na tom není s konzistencí dvakrát dobře a souvisí to i s tím, že Guido nechtěl z počátku podporu objektů zavádět, takže se jednalo o čistě procedurální jazyk. A když mi nevěříš, co třeba new stylled class, textové výjimky a hromadu dalších dokladů o tom, že návrh Pythonu není tak bez chybičky, jak se obecně tvrdí.
Problematická standardní knihovna je to, že se každý modul ovládá jinak, mnoho z nich existuje jen díky zpětné kompatibilitě, protože je nahradili daleko lépe udělané nové. Není (anebo o něm nevím) žádné doporučení, jak dělat moduly.
C má mizernou implementaci gtk? Vždyť C je nativní jazyk pro gtk 
a celé je to v C napsáno. Jinak souhlasím, většina práce s gtk je o tom, kterak do C dobastlit podporu pro objekty.
) Takze python nie je bez chyby, ale ak ho pouzivas, urcite suhlasis, ze je to velmi elegantny jazyk
To ze sa kazdy modul ovlada inak je ciastocne pravda.. (na druhej strane je to len vec dokumentacie a som doma IMHO a snad je kazdy pre dany ucel navrhnuty co mozno najoptimalnejsie) Mozno je trosku na skodu celeho jazyka, ze chybaju nejake guidelines ktore by sa dodrziavali. (minimalne nieco v style PHP pear) Suhlasim, ale netvrdim ze mi to doposial prekazalo.
No a ta implementacia.. C je veru native pre GTK, ale proste trpi neobjektovostou (myslim kombinaciu C a GTK, nie C samotne) a trpi treba povedat poriadne. 
Python so svojou nadstavbou je potom uplny objektovy balzam na dusu. (aj ked aj tam sa najdu niektore vynimky) Kazdopadne lepsiu implementaciu GTK som nenasiel. (ale rad sa necham poucit)
Abych to shrnul, C je lepší, protože si v něm musíte (ne můžete, nic z toho, co jsi napsal není součástí standardu C, takže to každý bastlí sám a ve větším projektu dopadneš jako teď v C++ i stringy si každý implementuje sám) napsat všechno od píky.
Docela dobrý argument proč NEPOUŽÍVAT C++ je kouknout se na zdrojáky skutečných dynamických objektových systémů- Lisp, Smalltalk, Python, Perl, Lua.. Všechno je implementováno v C, nikoliv v C++. Kdyby objekty v C++ byly použitelné, proč by jednoduše autoři nenavrstvilit interpret kolem nich, a neušetřili si tak spoustu práce?Argumentace autoritou není korektní argumentací
. Navíc je i to důsledkem standardizovaného vývoje (nejdřív zasedá nějaká komise a potom vývojáři překladačů dlouze nadávají) C++. Ale pokud chceš, mrkni se na zdrojáky Strongtalku, který představuje současnou špičku ohledně technik dynamické kompilace. Oni ti vývojáři asi nebyli úplně blbí a věděli, proč to chtějí dělat v C++ .... proti tomu je takový Python spíše dětská hračka.
Spojovat C++ a asm dohromady bylo jako kdybyste se pokoušel mýt v paneláku schody a někdo vám vždy když se předkloníte vrážel rozžhavenou tyč do zadku.
Tak to nemůžu posoudit, nemám takové životní zkušenosti jako vy… :-)
... Třeba změna třídy za běhu je něco, co jsem viděl (jenom viděl) ve SmalltalkuPche, změna metody za běhu, prkotina. Změnit třídu objektu uvnitř jeho metody? Prkotina. V čem? V PERLu!
Teda, ale udržovat takovej kód bych nechtěl, to se přiznám bez mučení.
„Dnešní CPU jsou zcela viditelně optimalizovány pro konstrukce jazyka C, což byste poznal, pokud byste znal nějaké hodně staré procesory.“To mi povídejte, u nohou mi leží VAX.
„2) a nebo bezpečný dynamický, ale pomalejší kód (pak se dělá hodně za běhu, cesta Smalltalku, Pythonu), pak je ale třeba vědět, že je to daň za tuto vymoženost, a neplakat na špatném hrobě a nezatěžovat cpu blbostma“Já pořád doufám, že s tím pomalejším kódem to není nezbytně nutné, a Self 93, HPS (High Performance Smalltalk - jádro VisualWorks) a Strongtalk mě v tom tak nějak utvrzují. Je ale jasné, že ze všech tří cest je tahle absolutně nejnáročnější na kvalitu implementace a na množství práce a času do ní investované. Proto chápu, že na některé věci si budeme muset ještě počkat. :-/
Ze stejného ranku jsou dřívější Forth procesory a Lisp procesory, ale prostě počítač s takových specializovaným cpu se prostě nemůže vyvíjet.Hmm, akcelerátor Lispu v FPGA ... že bych ještě změnil téma disertačky (a pravděpodobně i ústav?)
„Proč dlouho přemýšlet jestli by náhodou nebylo lepší tady tohle držet v registru místo v paměti, když L1 cache má latenci pouze 1T?“A ještě jednodušší je prostě mít třicet dva celočíselných registrů nebo rovnou registrová okna.
... takže při volání identické virtuální metody záleží na tom z kterého konstruktoru ji voláte.Vy ste ale komik.
$ more cee_flus_flus_sucks.cpp
#include <stdio.h>
struct Sracka {
virtual void Blb() { printf("objekt je typu Sracka\n"); }
Sracka() { Blb(); }
};
struct SrackaKvadrat : Sracka {
virtual void Blb() { printf("objekt je typu SrackaKvadrat\n"); }
SrackaKvadrat() { Blb(); }
};
int main() {
SrackaKvadrat jedna_a_ta_sama_sracka;
return 0;
}
$ g++ cee_flus_flus_sucks.cpp
$ ./a.out
objekt je typu Sracka
objekt je typu SrackaKvadrat
$
Jaký komik? Tak mění C++ objektům svévolně za běhu třídy nebo ne? A mimochodem, ta "vyřešená interoperabilita" a bezproblémová implementace překladače a knihoven- jak se to shoduje s tím že když uvedený příklad zkusím místo g++ přeložit jiným compiler driverem a sice gcc, dostanu toto úžasně užitečné a insajghtfulní chybové hlášení:
$ gcc cee_flus_flus_sucks.cpp /tmp/ccSkOQw4.o:(.rodata._ZTI13SrackaKvadrat[typeinfo for SrackaKvadrat]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /tmp/ccSkOQw4.o:(.rodata._ZTI6Sracka[typeinfo for Sracka]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info' /tmp/ccSkOQw4.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' collect2: ld returned 1 exit status
virtual and for contructor use only?
ano, šlo by to ojekabátiť spomenutým for contructor
Sracka, takže se volá příslušná virtuální metoda a teprve potom vzniká instance třídy SrackaKvadrat, přičemž se volá zase její metoda. Nevím, jak si představuješ, že se v okamžiku, kdy ještě není vytvořena instance třídy SrackaKvadrat, bude volat právě její virtuální metoda ...
Myslím, že jsi právě ukázal, že C++ vůbec nerozumíš. Pořadí volání konstruktorů při vytváření objektů je specifikováno normou jazyka, takže pokud bys znal C++, věděl bys to.
BTW: jak souvisí chyby (při linkování) v jednom konkrétním překladači s C++ jako takovým?
8.12.2006 10:53
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
gcc -x c++ main.cpp -lstdc++ -o zde_nema_zrovna_dobry_den
. Ale teď mi došlo, že pro některé kolegy mi tam chybí možnosti nemám rád C++, nebo .c
) nevzpomínám.
8.12.2006 11:15
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
gcc nemá ten -l stdc++ ve svém -dumpspecs? Jak má build tušit jak se ta pitomá knihovna na které architektuře jako jmenuje?
gcc kompiluje .s, .c, .S, .C bez problémů, a zřejmě i .f nebo .java. Proč kvůli .cpp zavádět nový šmejd?
gcc správně kompiluje C++ - a bez problémů. Pouze má jinou sadu defaultně přilinkovaných knihoven, pokud ho spouštíte jako gcc, a jinou, pokud ho spouštíte jako g++.
.cpp a .cxx su vymysly pre istu nahrazku os, ktora ma case insensitive nazvy suborov a ani nezvladala + v nazve suboru.
). Příponu .C považuji za špatnou, protože pokud se přípona mezi C a C++ liší jen velikostí písmena, je to špatně zvolená věc.
). Příponu .C považuji za špatnou, protože pokud se přípona mezi C a C++ liší jen velikostí písmena, je to špatně zvolená věc.
gcc kompiluje C++ zdrojáky správně, ať mají příponu cc, C, cpp, cxx nebo c++. Pokud používáte gcc pro linkování, pak sada automaticky linkovaných knihoven závisí na tom, zda voláte gcc nebo g++.
stdc++ přidávala, v zimě nikoliv- aspoň by programátor v C++ neztrácel kontakt s realitou. A co rovnou /dev/urandom, to by bylo zábavné!
Linkovat pomocí gcc se samozřejmě může, sám to dělám (jen když chcete linkovat pomocí gcc C++ moduly, musíte přidat ručně -lstdc++). Nemělo by se ovšem tvrdit, že má gcc problémy s kompilováním C++ zdrojáků, protože to prostě není pravda.
Mimochodem, vím nejméně o jednom projektu, který k linkování C++ modulů záměrně používá gcc, protože i když je psaný v C++, standardní C++ knihovnu nepoužívá.
libsupc++, což je minimalistická podmnožina libstdc++, obsahující vše potřebné.
objekt.x = y mohl udělat objekt.předek = x. Ten parent slot (jak se tyhle speciální sloty (po C++kovsku membery) objektu nazývají v Selfu) má výsadní postavení pouze v tom, že když se na objekt volá metoda a nenajde se v samotném objektu, prohledávají se objekty odkazované parent sloty objektu (více parent slotů => „vícenásobná dědičnost“).
Typicky tedy většina objektů obsahuje „sloty s členskými daty“ a jeden parent slot na objekt s metodami společnými pro rozsáhlou skupinu objektů. A ten sám může odkazovat na „nadtřídu“ (resp. druhý prototyp v pořadí). Jinými slovy, svým způsobem máte pravdu – OOP s dynamickou změnou třídy opravdu „příliš nepočítá“, dalo by se říci, že v objektovém systému se to považuje za samozřejmost a není tomu tedy třeba věnovat nějakou zvláštní pozornost.
#become:, v některých implementacích s tím počítají třídy využívající objekty proměnné délky (tj. typicky kolekce).
6.12.2006 19:34
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Napriek tomu este stale osobne nepoznam objektovejsi jazyk Niekedy si na to vyhradim par dni snad.. Kazdopadne GTK chlebik najlepsie natriet maslom z pythona IMHO
6.12.2006 11:00
hajma | skóre: 27
| blog: hajma
| Říčany
)
C++ a Qt je opravdu velmi hezky citelne, dobre udrzovatelne a najdes hromadu programatoru, co to podporuji.
Nic proti Perl/PHP/Ruby apod., ale proste se mi na C++ a Qt libi, ze proste zkompiluju binarku, pribalim k tomu knihovnu a muzu to sirit v podstate na libovolny stroj na Linux, Mac nebo Windows (pochopitelne po kompilaci na prislusne platforme).
6.12.2006 22:04
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
6.12.2006 23:04
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
Moje uvaha je z oblasti skifi. Ale... ted byla do boostu prijata knihovna GIL(Adobe Generic Image Library), kterou navrhl Adobe a postupne v komunite Boostu dostava konkretni tvar, jak ji lidi pouzivaji. Momentalne Adobe pouziva Boost asi ve 30 aplikacich. Tim chci rict, ... jelikoz povazuju Adobe za firmu, co grafice rozumi, pak by vitr mohl vanout z techto koncin. Kdovi, jestli si Adobe timhle neklesti cesticku.
Iniciativa pro GUI framework by urcite byla: "GUI libraries will always have specialized widgets, arbitrary graphics, deep operating system dependencies, different architectures; no GUI framework is good for everyone, so a "Boost::GUI" would be at best a popular option for specific tastes and needs, not a standard."
Po prijmuti noveho std c++09 se zrejme diskuze orientuji na toto tema. Zatim je to tabu, cehoz Qt vyuziva.
7.12.2006 15:26
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Slovo kvalitní je subjektivní. Proč Linux nedává energii, kterou dává do podpory Qt do jiných frameworků? Záměrně nejmenuji.Obrovská podpora směřuje do GTK+ a jeho bindingů. Bohužel.
Pokud komunita protlačuje řešení zdarma a souběžně s tím propaguje jako správné řešení za statitisíce je to nekonzistentní.Nechapu, proc by to nemelo byt nekonzistentni - komunita propaguje OTEVRENE, tedy GPL reseni. VETSINA bezne distribuce Linuxu JE GPL! Nechapu, jak licence Qt podle tebe nemotivuje komercni firmy. V tom si opravdu odporujes - jako komercni firma bych prave byl stastny, ze mam nekoho, kdo mi za moje penize poskytne support a konzistentni "balik". (at uz to je RedHat nebo Trolltech) Dale:
Linux začne být rozšířenější, až pro něj komerční firmy budou běžně psát swJako treba Oracle? IBM? SAP?
a k tomu je potřeba aby Linux preferoval základní grafické knihovny a základní prostředky pro grafické prostředí zdarma.Jako treba Qt? (GPL je zdarma!) GTK? wxWidgets?
Srovnejte to s cenou za grafickou vrstvu pro vývoj Windows.Nevsiml jsem si, ze by Visual Studio a MSDN bylo pro komercni aplikace zdarma - narozdil od Qt, GTK, wxWidgets. Jen pro srandu se podivej na: http://www.sws.cz/default.asp?cls=SPresentTrees&StrType=1&StrSort=J9QAT0DXT
Jako pokus hezké.
Jako treba Qt? (GPL je zdarma!) GTK? wxWidgets?
Už vidím jak někdo na GPL vydělává slušné peníze (opět výjimky potvrzují pravidlo). GPL model jako komerční model pro sw firmy nemůže příliš fungovat a také by nefungoval, pokud by se měl rozšířit. Pokud Vám to uniká, hlavním účelem firem není propagovat GPL, ale vydělávat.
GTK a wxWidgets je řešení vhodné a nebýt toho, mnoho sw ze stran firem by vůbec na Linux nebylo.
Nevsiml jsem si, ze by Visual Studio a MSDN bylo pro komercni aplikace zdarma - narozdil od Qt, GTK, wxWidgets. Jen pro srandu se podivej na: http://www.sws.cz/default.asp?cls=SPresentTrees&StrType=1&StrSort=J9QAT0DXT
Tak si toho konečně račte všimnout. Zjistěte si fakta a pak argumentujte. A všimněte si, že Visual Studio je zdarma pro jakoukoli Vaši licenci!!!! Je jedno, jestli děláte GPL, BSD, public domain, nebo closed source, nebo co si vymyslíte za licenci. Windows je v tomhle napřed. Bohužel. Proti tomuhle Linux nemá co postavit, to je potřeba říct.
Qt je zdarma jen pro GPL, GTK je zase (nevím to jistě) LGPL, snad jediné wxWidgets jsou licenčně svobodné alespoň natolik jako programy dělané s Visual Studio.
Jako pokus hezké." - znas v oblasti IT vetsi firmy? (krome MS).
Psat, ze je "zdarma JEN pro GPL" je psychologicky zavadejici, i kdyz technicky spravne.
Na tom není nic zavádějícího, to je prostě důležitá skutečnost, která omezuje její použitelnost. Např. pokud je nějaký produkt zdarma jen pro použití ve školství, pak není "zdarma tečka", ale je zdarma jen pro školy. Stejně tak Qt není "zdarma tečka" ale zdarma pouze pro použití v GPL projektech (tedy ani zdaleka ne všech open source).
Pro mne jsou to nekřesťanské peníze, vezmu-li v úvahu, že je dvojnásobek ceny C++ Builder Professional a skoro tolik, co stojí C++ Builder Enterprise. Srovnám-li, co nabízejí tyto produkty a co nabízí Qt, pak tu cenu musím považovat za naprosto neadekvátní.
Gtk je LGPL, takže program, který je proti ní dynamicky linkován, může mít licenci, jakou uznám za vhodné. Qt je GPL, takže program, který proti ní linkuji, lhostejno zda staticky nebo dynamicky, musí být GPL.
6.12.2006 12:14
andree | skóre: 39
| blog: andreeeeelog
6.12.2006 16:02
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Chtel jsem jenom trochu zchladit ten zapal meho predrecnika. Protoze ve spojeni s tim moc-procesorem ma podle mych zkusenosti zacatecnik znacne problemy uz pri kompilaci.Co je na použití qmake tak složitého (qmake se postará o vše, i o
moc)?
Proc jsme Qt opustili byl ten problem, kdy jsme meli vektory pointru na objekty a kdyz chtel clovek pak nastavit napr x-souradnici nejakeho objektu, tak to meslo obejit jinak nez s _cast_.Můžete to nějak rozvést? Pod tím si dovedu představit jen vektor QWidgetů, u kterých X souřadnici nastavíte raz dva...
6.12.2006 16:37
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
p->move(novéX, p->y())?
6.12.2006 11:52
freshmouse | skóre: 42
| blog: Bruno Banány
Já se domnívám, že v jiných jazycích napíšeš velmi snadno špatný kód. Ale C: to buď umíš a napíšeš v něm cokoli -- anebo neumíš a nenapíšeš v něm nic. Nic mezi tím...
Mně by se pro výuku docela líbil i ten Python, bohužel jsem nenašel na internetu kvalitní návod, nebo tak něco. Má to hezkou syntaxi a brzo v tom "něco opravdového" napíšeš. Ale platí odstavec výše. (Ovšem byla by chyba srovnávat Python a C, jak někdo řekl výše...)
Po C bude následovat objektový jazyk a asi to bude Java. Třeba se mi v různých věcech nelíbí, ale beru ji jako věc, co v životě použiju. Je to progresivní technologie, řekl bych.
Co se Pythonu týče, hezkou větu o něm řekl Kyosuke: programátoři v Pythonu přepisují pomalé kusy kódu do C.
Já se domnívám, že v jiných jazycích napíšeš velmi snadno špatný kód. Ale C: to buď umíš a napíšeš v něm cokoli -- anebo neumíš a nenapíšeš v něm nic. Nic mezi tím...
Asi jsi jeste moc C zdrojaku programu nevidel co? Pravda je takova, ze v C je to uplne stejne jako vsude jinde: spatny kod se pise velice lehce.pak přijdou pointery a další věci, v těch místech tě C začne srát, ale pokud se nevzdáš, zvykneš si.He he, úplně přesně. Četl jsem nějakou knihu o Céčku. Do kapitoly ukazatelů jsem to bral docela rychle, neboť základní věci jako podmínky a cykly znám a potřeboval jsem znát pouze syntaxi. Dál už jsem začal docela nestíhat a vzdal jsem to. Takže říkáš, že když to nevzdám, tak z toho bude ovoce?
6.12.2006 16:55
freshmouse | skóre: 42
| blog: Bruno Banány
)
... pokud tedy (po perfektně zvládnutém C) se ještě nějaký Python budu (chtít) učit. Když totiž porovnávám výkon aplikací v C / C++ vs. v Pythonu, tak je vítěz jasný, což není způsobeno tím, že by všichni programátoři v Py byli blbci, ale i (hlavně) podstatou zmíněných jazyků... Je otázkou, co člověk programuje.
No, a jinak: jak se to C učím, tak si dělám poznámky, takové taháky, kde si můžu cokoli rychle zopakovat. Jednou je zveřejním.
Chci také pochopit počítač a nějakým způsobem se s ním sžít, poznat ho.Pak nelze jinak, než doporučit assembler
Vždyť tam vlastně nic jiného než ukazatele nejsoupak přijdou pointery a další věci, v těch místech tě C začne srát, ale pokud se nevzdáš, zvykneš si.He he, úplně přesně. Četl jsem nějakou knihu o Céčku. Do kapitoly ukazatelů jsem to bral docela rychle, neboť základní věci jako podmínky a cykly znám a potřeboval jsem znát pouze syntaxi. Dál už jsem začal docela nestíhat a vzdal jsem to. Takže říkáš, že když to nevzdám, tak z toho bude ovoce?
Možná by stálo za uvážení, zda by nebylo lepší nejprve se naužit assembler. Pak již není na ukazatelích nic těžkého.
6.12.2006 16:29
freshmouse | skóre: 42
| blog: Bruno Banány
Hledá se PYTHONISTA (fulltime) !!!
Proč mi do toho nesedí / sedí až moc ta patička?Protože život je pes a dobrých programátorů není nikdy dost..Hledá se PYTHONISTA (fulltime) !!!
Kdepak soudruzi pythonisté dělají chybu?
Python dělá rozhodnutí, které z něho dělají jen skriptovací jazyk, nikoli profi jazyk. Možná, že kdyby autor Pythonu musel udržovat, nejlépe sám velký projekt, jeho postoj by byl vyzrálejší a pochopil by co znamená ochrana investic do kódu.
), tak uvidíme, jestli tam na něj nebudou někteří štěkat.
Python, pygtk, idle + ipython.
6.12.2006 15:13
David Watzke | skóre: 74
| blog: Blog...
| Praha
Perl je super jazyk, ale ne na GUI.
btw, otázka GTK vs Qt ... čo je viac? sloboda programátora (voľba toolkitu) alebo sloboda užívateľa (voľba výzoru)
)
Filozofická odpoveď: licencia
v prípade, že by callbacky boli iba libky, ktoré samotný midlayer dynamicky ťahá (povedzme, že by mal loader aj pre javu, aj pre C/C++, aj pre perl, v núdzi aj pre python ...) odtiaľto sa dostávame k projektu parrot (veď aký je dôvod, že by sa napr C nemohlo interpertovať?)
6.12.2006 17:18
multi | skóre: 38
| blog: JaNejsemOdsut
Konečně pořádný hlas! Ale zásadně FOTRAN 68. Novější verze je pro sraby
GUI taky, samozřejmě. Nejlepší vstupně/výstupní zařízení je ovšem dálnopis!
Slzu jsem již zatlačil...
6.12.2006 19:26
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Jazyky, kde programátora netreba
Nejspíš proto, že aby se člověk mohl programováním živit, stačí právě znát jeden jazyk (a často ani ne moc dobře)... A když se tím uživím (programováním), tak to přeci umím, ne?Á kolega bude také z VŠE
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
6.12.2006 17:38
6.12.2006 18:26