Ne, vhodnější nadpis, než je zbytečná tautologie v druhé části, mě opravdu nenapadl :). Debian Testing jsem na svém notebooku používal od srpna minulého roku až do poloviny února, kdy byl uvolněn Debian Lenny a já jsem (z důvodů dočasné absence bezpečnostních updatů) zůstal na stabilní verzi (Lennym). Po ukončení semestru jsem však na začátku června opět přešel na testovací verzi Debianu, na které jsem zůstal až do začátku srpna tohoto roku, kdy jsem přešel na "nestabilní" verzi Debianu - Unstable. Mé důvody a dojmy po měsíci používání naleznete dál v příspěvku ;).

Minule se mně sice nikdo s řešením neozval (nevím, zda to bylo náročností úlohy nebo prostě tím, že jsou prázdniny), ale nevadí, zkusíme jinou úlohu :). Tentokrát jsem si hádanku vypůjčil z jednoho zdroje, který a priori uvést nemohu, protože pak byste se místo samotného řešení pokoušeli hledat řešení v onom zdroji :), ale po zveřejnění řešení ho samozřejmě uvedu. Kód jsem ale mírně upravil, aby to bylo zajímavější, takže není úplně shodný. Tentokrát se budou moct zapojit i ti, kteří znají "jen" Jazyk C.

Před pár dny jsem si nainstaloval Iceweasel 3.5.2 (sestavení Firefoxu pro Debian GNU/Linux)) z experimentální větve, protože v testing a unstable je stále pouze Iceweasel 3.0.12 (přitom 3.0.13 je venku už téměř měsíc a 3.5 dva měsíce) a ve stabilní větvi dokonce pouze Iceweasel 3.0.6... Když ale koukám na stav Firefoxu v jiných distribucích (v Ubuntu 9.04 je 3.0.8, v OpenSUSE 11.1 je 3.0.4, ve Fedoře 11 je 3.5.beta4), tak jsem rád za situaci, co je v Debianu (informace mám ze serveru distrowatch.com). Je mně jasné, že nových verzí balíčků z upstreamu je hodně, ale Iceweasel bude určitě patřit k těm nejpoužívanějším balíčkům, u kterých je oprava bezpečnostních chyb velice důležitá. No, ale třeba je za tím něco, o čem nevím, takže se v tom nebudu rýpat. V tomhle příspěvku bych chtěl zmínit moje dojmy z nové verze a problémy, na které jsem narazil (včetně jejich řešení).

Toto ale uběhlo... Ještě nedávno jsem v prváku na bakalářském studiu hledal Aulu Q, kde jsme měli většinu přednášek, a za necelé tři týdny začíná ročník páty, čili poslední. Stejně jako minulý rok bych chtěl uvést, které předměty mě letos čekají a jak se na ně těším.

Na téma tohoto příspěvku mě přiměl příspěvek Martina Kopty v článku Vim Plugins You Should Know About: snimpate.vim. O co jde? Drtivá většina programů umožňuje měnit své chování, vzhled atd. pomocí editace nastavení. Pokud vám něco nevyhovuje, případně chybí, a máte možnost to změnit, tak proč to neudělat, že? Co ale když budete pracovat s tímto programem na jiném stroji, kde nebudete mít své nastavení? Budete schopni s tímto programem obstojně pracovat? Nad těmito otázkami bych se chtěl v tomto příspěvku zamyslet.

Po půl roce sucha (konečně) přináším další zajímavou programovací úlohu. Tentokrát se jedná o úlohu pro programátory v C++ a na své si přijdou především milovníci bitových manipulací :). A nebojte, nebude to žádná úloha stylu "vytvořte makro pro vzájemné prohození polovin předaného intu".

Valgrind je open-source nástroj, který slouží především pro ladění paměťových chyb (umí toho víc, např. profilování, ale tím se teď zabývat nebudu). V tomto příspěvu bych se chtěl ukázat jeho možnosti, co se týče detekce problémů při práci s pamětí a to tak, že vždy uvedu jednoduchý příklad kódu (omezím se na jazyk C, ale valgrind zvládá programy napsané v libovolném jazyce, ať už je výsledek kompilovaný či interpretovaný, ovšem hlavně se používá pro programy napsané v C a C++), ve kterém se nachází paměťová chyba a ukázku, jakým výstupem na tuto chybu zareaguje valgrind.

Předtím, než jsem začal k editaci zdrojových souborů k LaTeXu používat VIM, tak jsem používal vývojové prostředí Kile (mohu s klidem doporučit). Mezi jednu z výhod tohoto prostředí bylo automatické vytváření koster pro bibliografické záznamu v BibTeXu. Z menu jste si zvolili typ záznamu a vygeneroval se vám kostra. Jelikož mně něco takového ve VIMu chybělo a nenašel jsem plugin, který by to řešil, tak jsem si napsal vlastní plugin, který to řeší.

Většina programátorů ví o tom, že některé konstrukce mají tzv. nedefinované chování a že by se jim měli vyhýbat. Méně se ale už ví, že kromě nedefinovaného chování norma definuje další typy chování: "specifikované", implementačně závislé a nespecifikované. Po přečtení tohoto příspěvku byste měli mít jasno, jaký je mezi těmito chováními rozdíl a kterým z nich se vyhýbat.

Ve Vimu jsem si oblíbil šikovnou utilitu (plugin) Taglist, která s pomocí programu ctags umí pro editovaný soubor (či explicitně zvolené soubory) zobrazit postranní okno se seznamem (stromem) symbolů, které se v daným souborech vyskytují, jako je např. seznam modulů, typů, funkcí atd. Ostatně mrkněte na screenshoty. Usnadňuje to orientaci a přechod mezi jednotlivými soubory. Tento plugin podporuje celou řadu jazyků (kolem 40), mezi které patří např. C, C++, Python, PHP atd. Bohužel jazyk Haskell není podporován a nepodařilo se mně najít kompletní postup, jak tuto podporu přidat (pouze střípky z diskusí), proto v tomto příspěvku přináším kompletní návod, jak tuto podporu přidat.