Důležité upozornění!

Policie České republiky a šéfcensor Ústavu pro studium totalitních režimů Jaroslav Čvančara varují: citovat jakékoli texty z tohoto blogu způsobuje vážné risiko trestního stíhání! Četba na vlastní nebezpečí!

Počítače

To jsem celý já. Stává se mi často, že chci něco udělat, a skončím u něčeho úplně jiného, protože to v danou chvíli pokládám za důležitější a/nebo zajímavější. Je to jedna z mnoha vlastností, které činí život se mnou tak nesnesitelným. Ilustruji: rozhodnu se kupř. vyměnit zářivku v kuchyni, tedy se pro ni vypravím, ale domů se vrátím se silikonovým tmelem do koupelny (v lepším případě) nebo s novým multimetrem (v tom horším).

Přesně tak dopadl první pokus o návrh grafického rozhraní k mému emulátoru počítače PMD-85. Potřeboval jsem na hlavní plochu vhodný vzor (pattern), a skončil jsem u problému, jak udělat z bitmapy nekonečnou bezešvou texturu.

Ten problém je totiž zajímavý a rozhodně netriviální.

Představme si, že máme obdélníkovou bitmapu s motivem, který chceme takto použít. Pro jednoduchost předpokládejme, že je (makroskopicky) homogenní a isotropní, tzn. invariantní k translaci a rotaci.

To nejjednodušší, tzn. udělat z jednoho obdélníku čtyři a ty příslušným způsobem zrcadlit a sesadit do matice 2×2, nebude fungovat, protože pixely na hranách sice budou navazovat, ale větší útvary už ne, např. z kroužku může být osmička; takto kdysi vytvořili nekonečnou krajinu autoři jednoho leteckého simulátoru, tuším, že Flight Unlimited, a sklidili posměch.

Problém lze vyřešit u jednoduše strukturovaných ploch. Např. skládá-li se bitmapa z malých kružnic, můžeme u každé, která protíná hranu, doplnit její pokračování na druhé straně, a aby se v okolí hran pole kružnic nezhustilo, s pravděpodobností odvozenou od toho, jaká část plochy kruhu kružnice je vyťata hranou, některé místo toho vypustit.

Ale jak upravíme třeba kameny nebo prostou texturu z bublin? U kamenů si umím představit, že budeme postupovat podobně jako u kružnic, i když ani tam to nepůjde dokonale, protože kamínky se navzájem překrývají a může nám některá část chybět, ale u bublin jsem bezradný. Podle mne ten problém nemá algorithmické řešení.

Nejsem nijak výrazným nostalgikem a retro-mániemi většinou netrpím, přesto jsem se dal na Facebooku zviklat Vítem Zvánovcem a vida, jak jiní propadají počítačové retrovlně, podlehl jsem vábení a rozhodl se přispět svými pár bity do díla, když pro nic jiného, tak – řekněme – ze studijních důvodů.

Rozhodnuto, budu tedy emulovat… Což o to, emulovat se dá leccos a lecjak. S rostoucím výkonem procesorů roste obliba emulátorů starších a museálních zařízení fungujících přímo v prohlížeči a psaných v JavaScriptu. Takto se podařilo naemulovat mj. Linux a emulátory spekter a prvních PC s MS-DOSem jsou běžnou věcí.

To pokládám za určitý paradox, protože účelem JavaScriptu rozhodně nemá být dodat uživateli prohlížeče software. K tomu měla být primárně určená Java a javové applety, jenže té jako kdyby dnes už nikdo nevěřil a – další paradox – Java se používá nejvíc tam, kde existuje fixní API a kde by bylo výhodnější psát v C/C++, protože procesorového výkonu rozhodně není nazbyt, tedy v Androidu. Trochu mi to připadá, jako kdybychom výpočty pro předpověď počasí zadávali superpočítači v makrech tabulkového procesoru a rodinný rozpočet počítali v assembleru…

Rozhodl jsem se proto, že budu kanonický a programovat budu v Javě.

Druhou otázkou bylo, který osmibitový počítač zvolit. Zalovil jsem v paměti. První počítač jsem si koupil v r. 1991 a bylo to už PC, tehdy s procesorem 386SX na 16 MHz a jedním megabytem paměti; vlastníkem osmibitového počítače jsem nikdy nebyl. Z osmibitů jsem intimně poznal několik strojů: o panictví jsem přišel cca v r. 1983 na Video Genie System (klonu TRS-80), později jsem používal československé výrobky SP-830 (?), PMD-85 a IQ-150/151, a jako poslední osmibit jsem měl jakýsi polský stroj s CP/M. Z něj jsem přešel na PC kompatibilní monstrum Tesla PP-06, což byl pozoruhodný výtvor československé improvisační školy: protože např. nebyly k mání procesory Intel 8088, pépéčko používalo 8086 (takže bylo vlastně rychlejší než na stejné frekvenci taktované IBM PC). A, překvapivě, ač to bylo obrovské a vážilo to snad metrák, jako jediný počítač, se kterým jsem do té doby přišel do styku, měl jakž-takž vyřešené chlazení a nepřehříval se.

Retrovášeň jsem se rozhodl ukojit pomocí PMD-85, což byl počítač, který mne svou notorickou nespolehlivostí a frapantně chybným návrhem přivedl k hardwaru: tyto počítače bylo nutné nejen opravovat, ale uživatel je musel i nejrůznějšími způsoby modovat, aby vykompensoval konstrukční vady.

Tedy dobrá, javový emulátor PMD-85, vzhůru do díla.

Začal jsem emulací procesoru. Péemdéčko běží na procesoru 8080A, tzn. na tom nejjednodušším, co se dá emulovat: emulace byla hotová za večer, a druhý den mi virtuální procesor prošel testem 8080/8085 CPU Excerciser (Sunhillow), který kontroluje i všechny idiosynkratické hodnoty flagů.

Emulátor CPU jsem si napsal nejprve v C, pak jsem ho ze zvědavosti přepsal do Pythonu a nakonec do Javy, dosti nezpůsobně u toho kleje, maskuje a castuje, proklínaje společnost Sun za to, že neimplementovala unsigned typy (Microsoft tuto chybu, tuším, v C# nezopakoval).

Překvapilo mě, jak je Java proti C pomalá. Na svém nikoli špičkovém počítači (optimalisovaném na tichost provozu, nikoli na procesorový výkon) mi celý Sunhillow test v C trvá 18 sekund, kdežto v Javě to samé zabere 9 minut. Buď neumím v Javě dobře a efektivně programovat, anebo jsou propagační řeči P.R.-manů Oraclu o tom, jak se Java blíží rychlostí k C/C++, od reality stále na hony vzdáleny. V Pythonu, podle očekávání, trval test přes hodinu, ale jeho doménou podobné výpočty nejsou (ano, přiznávám, přesto mne to jako zamilovaného pythonistu poněkud ranilo, dva řády je prostě moc…).

Zbývá maličkost, implementovat hardware počítače, což by neměla být s ohledem na jeho jednoduchost práce na příliš dlouhou dobu. Výstup na display a emulace magnetofonu jsou jasné, pro vstup chci použít nezávisle myšovatelnou javovou klávesničku, jejíž grafický návrh má arci, jak patrno, k dokonalosti dosud daleko.

Jsem tedy zvědav, co nakonec vytvořím. Za dosud nejlepší pokládám emulátor slovenského RM-Teamu, uvidíme, jak se s tímto benchmarkem poperu; o výsledku budu samozřejmě na tomto místě informovat.

Zvěsti o tom, že ministerstvo spravedlnosti hodlá opustit systém formulářů ZFO (o němž jsem měl vždy za to, že jde o pomstu svazarmovců 602 za příliš vysoký úplatek za získání státní zakázky) a přejít na formuláře inteligentní, jsem přijímal s nelíčenou hrůzou, představiv si, co asi dokáže neschopný český úředník ve spolupráci s neschopným českým programátorem pod takovým termínem vytvořit.

Nemýlil jsem se, ba má očekávaní za realitou ještě zaostala.

První pokus o generaci registrační dokumentace pro zápis Sudetoněmeckého krajanského sdružení v Čechách, na Moravě a ve Slezsku skončil ve fasi náhledu. Už z něj bylo zřejmé, že něco není v pořádku: na str. 6 se objevila v poli adresy bydliště Jana Šinágla varující hodnota null, což v Javě vždy věstí problémy, a neméně ominosní byla nula v poli vymazávaného počtu členů statutárního orgánu.

Moje obavy se ukázaly důvodnými: všechny další pokusy o práci s formulářem skončily interní chybou, jejíž kod ve formě UUID je mi vpravdě užitečný. Nepomůže ani návratový kod, který má uživateli umožnit v rozepsaném formuláři pokračovat: výsledek je stejný, s formulářem se nedá dál pracovat, všechny pokusy končí interní chybou systému. A snaha opatřit si telefonickou podporu na hotline vedla toliko k oznámení, že mám čekat, jelikož všichni agenti právě hovoří.

Tolik tedy k ministerstvu spravedlnosti a jeho inteligentním formulářům…

Aktualisováno.
Návratový kod je 0EJY1LD70GCQ, stránka inteligentního formuláře je zde; komu se podaří něco s formulářem udělat, aniž by se dostal k interní chybě, obdrží odměnu ve formě pochvalné zmínky na tomto blogu.

Aktualisováno.
Podlehl jsem nátlaku malomyslníků mezi svými čtenáři, formulář zahodil a vše vyplnil znovu, a hle, podařilo se.

Bulvární blog vyžaduje bulvární themata, jinak hrozí, že se bulváruchtiví čtenáři a najmě čtenářky odeberou jinam, kde jejich intelektuální libido ukojí lépe. To je jasné. Ale kde brát, když člověka napadají samé seriosní myšlenky? Aspoň nějaké bulvární zážitky kdybych měl, ale jako naschvál, už několik týdnů nic, vyjma snad pokusu o opravu plynové karmy, jenž arci thematicky spíše než tomuto blogu odpovídá rubrice Pat a Mat opět v plném nasazení.

Něco snad přece. Naučiv se TeX, pojal jsem záměr nahradit letitý hlavičkový papír něčím modernějším, vzdušnějším, elegantnějším. To provést je v TeXu hračka, leč běda, TeX je tak výkonný, že dokáže být svému uživateli prokletím. Dohotoviv návrh, chtěl jsem se přesvědčit, jak by vypadal v jiné barevné kombinaci než oné potenciálně závadové, ve které jsem ho původně vytvořil. Vzal jsem tedy ze stránky Chiraga Mehty seznam pojmenovaných barev a s použitím Pythonu a TeXu si sestavil dokument, zachycující hlavičkový papír v jednotlivých barvách. Samotný pythono-texový úkon zabral pár minut, ale výsledkem je soubor, který má cca 1500 stran a k mému zděšení obsahuje tolik použitelných barevných variant, že už tři hodiny jím listuji a listuji a jako Buridanův osel jsem skončil bez hlavičkového papíru, protože si prostě nejlepší variantu nevyberu.

Jen z první stovky barev se mi líbí: Allports (str. 12), Aluminium (str. 17), Amazon (str. 19), Amber (str. 20), Anzac (str. 29), Apple (str. 33), Astral (str. 52), Astronaut (str. 54), Atoll (str. 58), Azure (str. 68), Barberry (str. 78), Bay of Many (str. 84), Bay Leaf (str. 85), Bermuda Gray (str. 92) a Bilbao (str. 97). A to jsem, prosím, v jedné patnáctině, a jestli jsem neumřel, tak listuji a vybírám dodnes.

Aktualisováno.
Vyřešil jsem to takto.

Aktualisováno.
Oprava: takto. Ale teď už s barvami definitivně končím!

Ne, moji milí, nermuťte se ani nejásejte, anžto se neloučím s vámi, nýbrž rozloučil jsem se s počítačovým programem, který jsem dlouho používal, zvykl si na něj a vposledku si jej i oblíbil: s word procesorem LibreOffice, dříve OpenOffice. Je to pro mne událost tak převratná, že zaslouží několik slov.

První dokument v elektronické spisovně v OpenOffice napsaný pochází z ledna 2007, a celkem jsem jich za necelých sedm let vytvořil více než 2 800, což je, řekl bych, slušná uživatelská zkušenost. Oproti Microsoft Wordu, který jsem užíval do to doby, jsou mé zkušenosti s openofficy takřka bez výjimky kladné. Program dělal vždy přesně to, co jsem po něm požadoval, choval se stabilně a předvídatelně, na rozdíl od Wordu, který pravidelně míval své dny, kdy bych ke komunikaci s ním potřeboval tlumočníka (eventuálně dostatečně pádné kladivo, nejméně desetikilové, programátorský model). V LibreOffice jsou napsána téměř všechna podání, která na tomto blogu průběžně vystavuji, tedy není třeba nic blíže vysvětlovat.

Nyní jsem přece jen LibreOffice opustil a rozhodl se vytvářet veškeré dokumenty v TeXu. Důvody jsou dva: jednak si ušetřím dobré dvě třetiny času, který jsem vždy strávil kopírováním různých údajů a editací rubra, tabulek s přílohami atd., a také mohu výsledek ovlivnit v míře, která byla u LibreOffice nemyslitelná. Hladká sazba vypadá daleko lépe, v rubrice jsem si naprogramoval glue tak, aby se jednotlivé bloky vyrovnaly do estheticky optimálních poloh (a když se rozhodnu, že adresy stáhnu do jednoho řádku, udělám to jediným přepínačem, o zbytek se postará sázecí program), díky používání maker ušetřím čas i s věčným opisováním, příp. kopírováním, obvyklých frasí.

Vezměme jedno z prvních podání, které jsem v TeXu pořídil: žádost o proplacení faktur z prostředků zablokovaných na účtu společnosti guidemedia. Pro vytvoření takového PDF mi nyní stačí napsat v textovém editoru toto – přirozeně ne od nuly, ale editací jiného podání.

Hrubým odhadem mi práce zabere třetinu času než dřív, a výsledek vypadá kvalitněji a profesionálněji.

Naučit se TeX nebylo ovšem záležitostí na jeden večer a jedno přečtení manuálu. Autor programu Donald E. Knuth zjevně vyšel z premisy, že programátor musí při používání jeho produktu trpět, a tak vytvořil systém, který popírá všechny zásady normálního programování: rekurse, kterou programátoři téměř neužívají, protože vědí, že ji lze nahradit efektivnějším cyklickým algorithmem, je v TeXu základní technikou, bez které neobejdete, zvyk upravit zdrojový program pomocí mezer a tabulátorů se můžete rovnou odnaučit, protože každá mezera škodí a nikdy nevíte, kde se s lehkomyslně zapomenutou zpřehledňovací mezerou setkáte, a ladění vašeho programu připomíná cosi z kvantové mechaniky: u složitějších maker každý ladicí tisk téměř s jistotou změní chod laděného programu. Co by se dalo vyřešit jednoduchým regulárním výrazem (např. zjištění, jestli určitý řádek adresy obsahuje kod datové schránky nebo optické přiblížení dvou po sobě následujících lomítek v URL), v TeXu řeší makro se dvěma až třemi lokálními podmakry, s mírou přehlednosti někde na půl cesty mezi digitálním šumem a konfiguračním souborem Sendmailu – nezapomínejme, mezery jsou v kodu zapovězeny…

Abych to zkrátil, učicí křivka programu TeX se mi zprvu jevila připomínat severní stěnu Matterhornu, ale přesto jsem vytrval, přežil a na TeX po cca dvou týdnech zápasu přešel, a tak snad nebudu litovat.