Lazarus 1.6.0

Byla vydána verze 1.6.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus. Nejnovější verze Lazarusu je postavena na Free Pascal Compileru 3.0.0. Podrobnosti v poznámkách k vydání.

20.2.2016 14:15 | Ladislav Hagara | Nová verze

Komentáře

[Jardík]

Škoda, že ještě není dodělaný ten customdrawn LCL interface. Ty wrappery kolem GTK a Qt, to je hrozný.

[Petr Tomášek]

Asi se budu opakovat, ale nechápu, proč každý prd potřebuje své vlastní vývojové prostředí...

[Blaazen]

Nejspíš proto, že to vývojáři chtějí a sami používají. Nebo úplně přesně nerozumím. V 90. letech byly populární Delphi a pár lidí chtělo něco podobného na Linuxu. Kylix od Borlandu přišel teprve později a taky brzy skončil. Lazarus má za sebou 15 let vývoje a funguje dobře, je celkem lightweight, ale hlavně z jednoho projektu můžeš dělat nativní aplikaci pro Qt, Gtk, Win32 nebo Carbon pro (MacOS); podobně fungují wxWidgets. To mají všechno zahodit a udělat jen nějakej blbej plugin do Eclipse?

[pavlix]

ale hlavně z jednoho projektu můžeš dělat nativní aplikaci pro Qt, Gtk, Win32 nebo Carbon pro (MacOS)

Jak to souvisí s tím, že máš v systému další samostatný textový editor a pár věcí okolo na další programovací jazyk?

To mají všechno zahodit a udělat jen nějakej blbej plugin do Eclipse?

Tak pokud jim Eclipse připadá super, tak proč ne. Pokud jim připadá lepší mít vlastní, pak zase nevidím důvod se za každou cenu omezovat na FreePascal. Ale třeba je někde na webu dobré zdůvodnění, proč je můj dojem špatný.

podobně fungují wxWidgets.

To je taky IDE? Na webu píšou, že je to GUI library, tedy toolkit.

[Blaazen]

Jak to souvisí s tím, že máš v systému další samostatný textový editor a pár věcí okolo na další programovací jazyk?

V systému máš to, co si tam nainstaluješ. Někomu stačí nano, někdo si nainstaluje Lazarus a pak nepotřebuje Emacs, Sublimetext nebo Eclipse.

Tak pokud jim Eclipse připadá super, tak proč ne. Pokud jim připadá lepší mít vlastní, pak zase nevidím důvod se za každou cenu omezovat na FreePascal. Ale třeba je někde na webu dobré zdůvodnění, proč je můj dojem špatný.

Evidentně jim Eclipse tak super nepřipadá, když pracují na vlastním IDE/RAD a vydali novou verzi.
A podpora jiných jazyků? Lazarus není jen textový editor + nějaká kontrola syntaxe a automatické doplňování klíčových slov. Je tam editor formulářů, který je s tím provázaný. Vizuální komponenty jsou v udělané v určitém objektovém modelu a používá se RTTI, nevím k čemu by byla třeba podpora C nebo Javy, to by zaintegrovat nešlo.

[Tomáš Bžatek]

Lazarus je jednak widget toolkit (analogie s wxWidgets) a taky IDE predevsim s vlastnim GUI designerem. Ano, mohl bys to prebouchat jako pluginy do Eclipse nebo Netbeans, ale bylo by to prilis mnoho prace a narazel bys na ruzne omezeni pluginove architektury zminenych IDE, abys dosahl funkcionality alespon blizici se Lazarusu nebo Delphi.

[xkucf03]

To mají všechno zahodit a udělat jen nějakej blbej plugin do Eclipse?

Když už, tak spíš do Netbeans

Ale chápu, že vlastní IDE už dlouho, že se jim ho nechce zahazovat.

[Josef Kufner]

Zrovna pod tímhle projektem to není úplně vhodná poznámka, neboť Delphi tu bylo daleko dříve než většina současných vývojových prostředí a také se to dosti liší od všeho ostatního.

[Radek Hladik]

Odpovím jednoduše. Lazarus se snaží napodobit Delphi tím, že prováže IDE s vlastním programovacím jazykem a sadou komponent tak, že se bude programovat snáze a rychleji - proto se tomu říká RAD (Rapid Application Development).

Nevím přesně jak Lazarus, ale Delphi dotáhly propojení na takovou úroveň, že například ladění aplikací je neskutečně pohodlné. Pracoval jsem s Eclipse+Java, ale komfort ladění se nedal ani srovnat. Například změna vykonávaného řádku jednoduchým přetažením myši je věc, která je neskutečně návyková. Nebo uprostřed vykonávání kódu potkáte pole bytů, které byste si rádi uložili do souboru: stači otevřit obyčejný Evaluate/Modify dialog a rovnou psát: TBytesStream.Create(bytes).savetofile..... a ono se to vykoná v kontextu právě aktuálního stavu programu... Chápu, že to všechno nejsou nějaké super zázraky, ale je to všechno pohodlně zabalené a vžydcky po ruce...

[xkucf03]

stači otevřit obyčejný Evaluate/Modify dialog a rovnou psát: TBytesStream.Create(bytes).savetofile..... a ono se to vykoná v kontextu právě aktuálního stavu programu...

V Netbeans tohle máš, včetně napovídání. Eclipse to tuším umí taky.

[jb]

V čem univerzálním bys tedy psal aplikaci pro Delphi/Lazarus, aby byl vývoj stejně rychlý? Předpokládejme, že máš rozsáhlý projekt (mnoho okýnek, mnoho knihoven), který je neekonomické přepisovat do dnes rozumnějšího jazyka.

[štěty]

Ne, hlavně ne pascal - nejhorší jazyk co kdy existoval!

[Jardík]

Pascal je dobrý jazyk. Akorát FPC není moc dobré na optimalizace. Často generuje naprosto zbytečné instrukce jako

lea rax,[rbp+0x20]
mov rbx, rax
; pracuj s rbx a už nešahej na rax

Vygeneruje vám zbytečnou mov instrukci, přestože s hodnou v rax už vůbec nepracuje. Taky má pomalé výjimky, používá k tomu setjmp() a longjmp(). V changelogu 3.0 se sice píše, že už používá "nativní výjimky", ale to asi pouze v případě windows, v linuxu tam pořád generuje setjmp().

[Radovan]

Naopak, jeden z nejlepších. Špatný je akorát v očích těch, kteří se ho pokoušeli nacpat do věcí kam se nehodí

[jb]

Pascal je sice trochu ukecaný, ale pracovalo se v něm parádně. V Delphi mě vždy udivovala rychlost kompilace. Na jednojádrovém Pentiu MMX 233MHz se to stále kompilovalo rychleji, než na dnešním stroji C++.

FPC a Lazarus je z mého pohledu taková srandička. Pietně to asi stále vyvíjí, ale profesionálně to použít nejde. Zkoušel jsem na to migrovat nějaké své staré projekty z Delphi 7. Kód by potřeboval nemalé úsilí na předělání, aby šel vůbec zkompilovat. Zkoušel jsem i jednoduchý prográmek úplně od nuly a taky jsem se kvůli něčemu vzteknul. Zkoušet novou verzi už nemám sílu, protože už nemám aktivní projekty v Delphi.

[Hans1024]

Vsechno se kompiluje rychleji nez C++

[kralyk z abclinuxu]

Krom Rustu :-/

[Jardík]

No rust je stejně nepoužitelnej pro každý trochu seriózní projekt, kde jde o bezpečnost uživatelových dat ... protože si jen tak náhodně může hodit abort() při selhání alokace.

[kralyk z abclinuxu]

V novějších verzích se dá OOM handler nastavit a dají se naštěstí už taky použít vlastní alokátory.

[Jardík]

Jestli to ale neprovede stack unwind a nespustí destruktory (nebo jak tomu říkaj, ten Drop trait?), tak to může být stále problém, že nebude dost paměti na záchranu dat. Ale určitě lepší než přímý abort().

Z tvého komentáře soudím, že se o rust zajímáš, není nějaký použitelný GUI toolkit, který není jen nějaký wrapper na gtk/qt?

[xkucf03]

GUI toolkit, který není jen nějaký wrapper

Proč proboha zavádět další? Aby mohla každá aplikace vypadat jinak? (od toho jsou přece styly/témata/look-and-feel…)

[Jardík]

Jak další? Protože nedostačují. GTK aplikace náhodně hází abort() při OOM, takže je nepoužitelná pro každou seriózní aplikaci. Qt zase při OOM leakuje, protože není exception-safe, nebo vám vesele zanechá zamčené mutexy, které už nikdy neodemkne. Dlouho se sháním po toolkitu, který je napsaný pořádně pro daný programovací jazyk. Tj, když je v C++, očekávám, že je exception safe, nebo výjimky sám o sobě vyhodit nemůže (např. používá new(std::nothrow)). Je-li napsán v C, očekávám, že kontroluje návratové hodnoty z malloc() a když selže, tak mi probublá třeba ENOMEM chybu až k místu volání, s tím, že já se pak můžu zařídit podle aplikace (záchrana dat, či abort, pokud záchrana není pro danou aplikaci třeba, ale hlavně, nechat to na mně a né samovolně volat abort()).

[xkucf03]

A co rozdělit aplikaci na dvě části (procesy)? A když dojde k sestřelení GUI, to důležité zůstane běžet na pozadí a můžeš se k tomu připojit z jiného UI nebo to v klidu samo doběhne, uloží soubory, uvolní zdroje…

[Jardík]

To nemusí být špatné řešení. Přijde mi to ale jako 'hack' kvůli něčemu, co mohlo být na nižší úrovni vyřešeno lépe.

[pavlix]

Co je špatného na abort? Když mi chcípne baterka v laptopu nebo vypadnou pojistky u desktopu, tak se taky žádné destruktory nevolají.

[Jardík]

Na abort() je špatně hodně věcí. Pokud vám jde alespoň trochu o data, tak si nemůžete dovolit použít jazyk, či knihovnu, kde je nenastavitelně volán abort(), když selže alokace. Přitom vzpamatovat se z takové věci nemusí být nemožné, třeba zavřu všechny soubory, co se nezměnily a tím dostanu třeba haldy paměti, která mi bude stačit na záložní uložení neuložených dat, a nebo můžu fungovat dát s méně soubory. A srovnávat to s pojistkami je mimo, tam je zase řešení jiné (záložní zdroj třeba).

[pavlix]

Na abort() je špatně hodně věcí.

Třeba?

Pokud vám jde alespoň trochu o data, tak si nemůžete dovolit použít jazyk, či knihovnu, kde je nenastavitelně volán abort(), když selže alokace.

To už jsi psal. Chápu, že v některých případech může mít smysl selhávající alokaci ošetřit, ale příklad s náhlým překotným ukládáním dat mě tak úplně nepřesvědčil.

Přitom vzpamatovat se z takové věci nemusí být nemožné, třeba zavřu všechny soubory, co se nezměnily a tím dostanu třeba haldy paměti, která mi bude stačit na záložní uložení neuložených dat, a nebo můžu fungovat dát s méně soubory.

Podle mě je hlavní problém mít vůbec neuložená data, bez kterých se neumím obejít. Volání abort() tak jenom ukáže už existující problém.

A srovnávat to s pojistkami je mimo, tam je zase řešení jiné (záložní zdroj třeba).

Není to mimo. A nesrovnával jsem to pouze s pojistkami. Je jedno, jestli je to baterka v laptopu, pojistky, vykopnutý kabel z UPS nebo pád systému. Software, který udržuje důležitá data a nestará se o jejich konzistenci a včasné uložení, není dobrý software.

Očekával jsem proti abort() trochu silnější argumenty.

[Jardík]

Ale proč abort()? Třeba otevírám nový, velký, soubor a prostě nemám dostatek paměti. Proč by mi měl program kvůli takový věci spadnout, když prostě můžu soubor neotevřít? Nebo proč by mi měl spadnout 10 sekund na to, protože už nebudu mít paměť na zobrazení tlačítka? Můžu nepotřebné soubory zavřít, čímž dostanu více paměti, a inforomovat uživatele, co se stalo. A když se nepodaří ani to, prostě urobím zálohy a končím.

O uložení se třeba podle typu stará uživatel aplikace (příklad editor obrázků), ale proč bych mu neudělal zálohu, když je to v mé moci, a místo toho bych ho měl připravit i třeba o půl minuty práce a musím spadnout?

[pavlix]

Ale proč abort()? Třeba otevírám nový, velký, soubor a prostě nemám dostatek paměti. Proč by mi měl program kvůli takový věci spadnout, když prostě můžu soubor neotevřít? Nebo proč by mi měl spadnout 10 sekund na to, protože už nebudu mít paměť na zobrazení tlačítka? Můžu nepotřebné soubory zavřít, čímž dostanu více paměti, a inforomovat uživatele, co se stalo. A když se nepodaří ani to, prostě urobím zálohy a končím.

Proč ne, to je validní use case. Ale zase na druhou stranu na Linuxu nejčastěji dopadneš tak, že všechny alokace projdou, ale systém v jednu chvíli tvoji appku nemilosrdně sestřelí.

O uložení se třeba podle typu stará uživatel aplikace (příklad editor obrázků), ale proč bych mu neudělal zálohu, když je to v mé moci, a místo toho bych ho měl připravit i třeba o půl minuty práce a musím spadnout?

A proč mu neděláš zálohu průběžně, nejlépe ve formě nějakého logu jako to dělá vim, abys ho ochránil i proti mnohem častějším problémům?

[little.owl]

Pouziti abort() pro osetreni OOM situace snad nejbeznejsi zpusob osetreni na Linuxu, a to vcetne beznych command line toolu a pokud k tomuto dojde, jedna se o terminalni stav a je lepsi aplikaci ukoncit. V Linuxu abort() zpusobi SIGABRT a nic vam nebrani ukladani exitujicich dat osetrit. K gtk - GLib tusim nabizi vedle funkce g_malloc(), ktera vola abort() v pripade selhani, take g_try_malloc(), ktera to nevola.

Přitom vzpamatovat se z takové věci nemusí být nemožné, třeba zavřu všechny soubory, co se nezměnily a tím dostanu třeba haldy paměti, která mi bude stačit na záložní uložení neuložených dat, a nebo můžu fungovat dát s méně soubory.

Na Linuxu velmi nepravdepodobne.

[Jardík]

Na Linuxu velmi nepravdepodobne.

Pokud jde o overcommit, tak ten jde vypnout.

[kralyk z abclinuxu]

Jde, ale tvůj program by stejně měl předpokládat, že je zapnutej, protože naprostá většina uživatelů ho nechá zapnutej...

[kralyk z abclinuxu]

Jestli to ale neprovede stack unwind a nespustí destruktory (nebo jak tomu říkaj, ten Drop trait?), tak to může být stále problém, že nebude dost paměti na záchranu dat. Ale určitě lepší než přímý abort().

Pochybuju, že to dělá stack unwind, popravdě, ono člověku v tom handleru stejně moc nezbude nic jinýho než abortnout. Jenže ono je to celkově problematické, jsou vůbec programy, které se v OOM situaci chovají korektně?

Pokud člověk OOM očekává - např. alokuje místo pro nějaká potenciálně obrovská data (rastrová grafika,...) - může v Rustu použít std::heap::allocate, zkontrolovat, jestli alokace proběhla, a pokud ano, udělat z toho bežnej boxovanej pointer nebo něco takového.

Z tvého komentáře soudím, že se o rust zajímáš, není nějaký použitelný GUI toolkit, který není jen nějaký wrapper na gtk/qt?

Slyšel jsem o Conrodu, ale zkušenost s tím nemám.

Příležitostně přispívám do Gtk-rs, čili binding pro GTK, IMHO to je dobrá cesta.

[Jardík]

Pokud člověk OOM očekává - např. alokuje místo pro nějaká potenciálně obrovská data (rastrová grafika,...) - může v Rustu použít std::heap::allocate, zkontrolovat, jestli alokace proběhla, a pokud ano, udělat z toho bežnej boxovanej pointer nebo něco takového.

Problém ale je, že se taková alokace může podařit jen-tak-tak a pak selže jiná alokace někde jinde a dostanu abort(). Z toho důvodu použití alokátoru není záchrana před pádem.

Příležitostně přispívám do Gtk-rs, čili binding pro GTK, IMHO to je dobrá cesta.

Třeba teď jsem koukal na ten Gtk-rs a vidím v příkladu

let window = gtk::Window::new(gtk::WindowType::Toplevel).unwrap();

Proč to vůbec takto dělat, aby to vracelo Option<> nebo Result<>, když samotné gtk_window_new "nemůže" selhat. Tím "nemůže" myslím právě to, že se vytváří GObject a to "nemůže" selhat. A to proto, že pokud k selhání dojde, je to ze strany glib automatický abort(). Tudíž takový wrapper přidává programátorovi naprosto zbytečnou práci (unwrap()), a falešný pocit, že může ošetřit selhání.

[kralyk z abclinuxu]

Problém ale je, že se taková alokace může podařit jen-tak-tak a pak selže jiná alokace někde jinde a dostanu abort(). Z toho důvodu použití alokátoru není záchrana před pádem.

No, anebo neselže nic, ale v nějaký chvíli ti proces zabije OOM killer a stejně s tím nic neuděláš.

Stejně mi ale není jasný, jak bys to chtěl zpracovávat, i kdybys mohl. Třeba dejme tomu, že ti aplikace v C++ odchytí bad_alloc. Co s tím budeš dělat? Nejspíš na to budeš mít handler někde dost vysoko (tzn. dost blízko main()) a tam ti stejně celkem nezbude nic jinýho, než aplikaci ukončit, protože kontext, ve kterém chyba nastala, je stejně už dávno ztracen. A data bys mohl zachránit jedině tak, že by se zapisovaly v destruktorech, ale to mi přijde jako dost prasárna - destruktor by neměl provádět I/O operace.

Jedině, že bys měl ošetření bad_alloc na každým kroku, což by asi tak zdesetinásobilo velikost kódu, to mi nepřijde prakticky reálně možné.

Navíc ve chvíli, kdy systému dojde pamět, tak je systém stejně celkově naprosto nepoužitelný, protože prakticky všechno stojí zablokováno na I/O swapu a všechno je šíleně pomalý a uživatel ti stejně nejspíš mašinu vyresetuje než stihneš něco smysluplného udělat. Snažit se v té chvíli o nějaké I/O na záchranu dat je IMHO naprosto marné.

Takže klidně používej Gtk nebo Qt a OOM neřeš, nemá to cenu Důležitý data si vyzálohuj dopředu, jak píše pavlix...

Proč to vůbec takto dělat, aby to vracelo Option<> nebo Result<>, když samotné gtk_window_new "nemůže" selhat.

Snažil jsem se to najít ve zdrojácích, ale tam už to není. Zřejmě v nové verzi ten Option/Result odstranili. Příklady používají stabilní verzi z crates.io, takže tam to asi ještě neprobublalo...

[mirec]

Třeba dejme tomu, že ti aplikace v C++ odchytí bad_alloc. Co s tím budeš dělat?

Preto sa občas alokuje časť pamäte (od pár kB po pár MB), ktorá sa pri výskyte chyby pri alokácii uvoľní aby sa program mohol bezpečne ukončiť s uložením dát, alebo aby mohol niečo zatvoriť a podobne.

[kralyk z abclinuxu]

Preto sa občas alokuje časť pamäte (od pár kB po pár MB), ktorá sa pri výskyte chyby pri alokácii uvoľní

Spíš použije na bezpečné ukončení, ne?

Jinak jsem dost skeptický k tomu, že by to v praxi skutečně fungovalo, zejména na běžným desktopu - asi by musel být jednak vypnut overcommit a taky by ten program musel ukládat na jiný device než ten se swapem, protože ten bude IMHO beznadějně vytížen... Musel by tak mít stěští a být včas naschedulován... Prostě, to celkově moc nevidim.

Vy jste to někdo testoval?

[pavlix]

Mně přijde, že se tu řeší úplné kraviny. Když se člověk podívá na reálný software, tak má problémy úplně jinde. Navíc netestovaná feature je kolikrát horší než neexistující a tohle v praxi nikdo testovat nebude a už vůbec ne dostatečně. Nehledě na to, že je to relativně málo častý problém, který jde spláchnout řešením daleko častějších problémů.

[kralyk z abclinuxu]

Hlavně Jardík řeší kraviny

[mirec]

Ja osobne som to nikdy nerobil, ani neviem ako vyradiť z činnosti OOM, ktorý by to zabil tak či tak. Táto technika o ktorej píšem sa používala na systémoch s primitívnymi OS, v súčasnosti si to možno viem predstaviť niekde na embedded, kde to má človek celé pod palcom.

[little.owl]

v súčasnosti si to možno viem predstaviť niekde na embedded, kde to má človek celé pod palcom.

Tam nepouzijete dynamickou alokaci, jinak to nemate az tak 'pod palcom'.

[pavlix]

Pochybuju, že to dělá stack unwind, popravdě, ono člověku v tom handleru stejně moc nezbude nic jinýho než abortnout. Jenže ono je to celkově problematické, jsou vůbec programy, které se v OOM situaci chovají korektně?

Neznám a u běžných aplikací ani nevěřím. Nemá smysl se patlat s kódem pro OOM, který nikdy nikdo nebude pořádně testovat. Myslím, že je v aplikacích už dost problémů například s ošetřením signálů, na které by se dalo zaměřit. Failující malloc na Linuxu, který při OOM střílí procesy jak na běžícím páse a přednostně střílí ty, které potřebuješ, bych už vůbec neřešil.

Podle mě by mělo maximálně smysl mít nějaký oom nebo dokonce pre-oom handler, který by pracoval nezávisle na kódu, který se snaží alokovat. Jeslti glibc nic takového nemá, dalo by se to tam jednoduše dohackovat.

[pavlix]

Mimochodem...

Takže očividně když se hodně chce, tak můžeš i v současné GLib failed allocation ošetřit.

[Jardík]

Píše se v dokumentaci glib: "g_mem_set_vtable is deprecated, g_mem_set_vtable is stub, do not use".

[little.owl]

+1

[pavlix]

Až na tu mechanickou paměť, která mě donutila napsat glibc místo GLib. :)

[Jardík]

Jinak já chápu, že to spousta aplikací nepotřebuje řešit, nebo prostě neřeší, to je na autorovi aplikace. Ale pokud píšu nějakou knihovnu, kterou bude někdo jiný používat, tak bych ho neměl omezovat abort()em kvůli zjednodušení mé implementace, ale měl bych mu dát možnost to ošetřit. Má knihovna se pak hodí pro oba účely. Pokud však dám abort() je dobrá jen pro jeden a dochází k infikaci všech dalších knihoven používající tuto (příklad právě glib).

[kralyk z abclinuxu]

Ok, ale proč to řešíš? Nechceš to řešit, až když to pro tebe skutečně bude problém?

[Jardík]

Protože já nejsem schopný nic naprogramovat, když to nemůžu naprogramovat tak, aby se mi to zdálo dokonalé. Třeba jak nádherně mi můj BurnApp začal už vypalovat ISO obrazy a nakonec jsem to všechno smazal včetně všech materiálů, co jsem studovat kvůli tomu. A to proto, že v linuxu nešlo zabezpečit, že mi jiná aplikace vypalování nepodělá tím, že zařízení otevře současně s vypalováním a zničí to. Stejně tak nemůžu v aplikaci použít knihovnu, o které vím, že je "rozbitá". Ve výsledku nemůžu naprogramovat vůbec nic, a můžu jen komentovat cizí projekty.

[xm]

Perfect is the enemy of good.

[pavlix]

+1

Ale taky s tím někdy bojuju.

[xm]

Sice tady takhle poučuju, ale občas s tím taky sám bojuju

[kralyk z abclinuxu]

+1

[Radek Miček]

Protože já nejsem schopný nic naprogramovat, když to nemůžu naprogramovat tak, aby se mi to zdálo dokonalé.

Pokud jde pouze o programy, možná by stálo za to vyzkoušet vývoj formálně verifikovaného SW v nějakém tradičním jazyce jako je například Coq nebo Isabelle (novější jazyky jako Idris mají stále mnoho bugů).

[xkucf03]

Tak se nech zaměstnat někde, kde budeš testovat nebo dělat revize kódu – budou ti za to ještě platit (ne jako v diskusích)

[Václav "Darm" Novák]

Nebo dělat konzultanta, přednášet…

[Hans1024]

by jim tam vsechno smazal...

[Josef Kufner]

To je mnohdy to nejlepší, co jde udělat.

[little.owl]

To je spise na vyhledani lekarske pomoci ... s tim ze perfekcionismus je nejlepsi cesta do Bohnickeho pavilonu .

[Jardík]

Nemůžu jít k lékaři, jehož cílem je dostat peníze od pojišťovny za mou 'léčbu'. Stačily mi nedávné problémy asi od září. Měl jsem problémy s dýcháním a cukalo mi u srdce. V prosinci jsem se konečně dokopal jít za doktorem. Všude nekonečné čekání, na plicní, na kardiologii, ... nakonec mi řekli, že mi nic není. A aby taky bylo. Když jsem začátkem února konečně dostal Holtera, tak už mě to nezlobilo ... náhodně ve stejnou dobu, kdy začli mé problémy, se sestra odstěhovala a nechala tu morče, abych se o něj staral, než se zabydlí... pravidelně jsem mu nosil dobrůtky a seno. Někdy v lednu si ho vzala k sobě a můj stav se lepšil. Ke konci ledna chtěla z půdy přivést seno, tak jsem šel pro seno ... a zbytek dne mě zase trápila dušnost a škrábání v krku a bylo mi zle. Další den zase všechno dobré ... z toho jsem si sám udělal diagnózu 'alergie na seno'. Od té doby jsem seno neviděl měsíc a je mi dobře.