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

Zdálo se, že to bude Haßliebe na celý život, a možná to nakonec bude jinak.

Když jsem se koncem loňského roku rozhodl, že se konečně naučím Javu, skončilo to nezdarem, tak jako všechny předchozí pokusy. V učebních textech, které jsem používal, se o Javě hovoří jako o tom nejskvělejším počinu lidstva od vynálezu polohrubé mouky, a když jsem si spustil běžnou javovou aplikaci, zjistil jsem, že – minimálně na Linuxu – soudruzi z Oraclu udělali kdesi chybu, případně jim zapomněli říct, že některá písmena mají onu ošklivou vlastnost, že nekončí na účaří, a je dobrým a pereniálním typografickým zvykem zobrazovat i to, co je pod čarou ponoru. Java je propagována jako kompatibilní na všech platformách, tudíž předpokládám, že se stejně projevuje všude…

Ačkoli běžně studuji nové věci se zaujetím a informace absorbuji velmi rychle, v tomto případě skončil milostný vztah rozchodem hned zkraje. Přispělo k němu i to, že jako mnoho jiných z mé generace nemám příliš dobrý vztah k objektově orientovanému programování (OOP), a pokládám ho za modní výstřelek konce 80. let, který z nějakého důvodu opomněl odeznít. Ačkoli jsem čas od času donucen něco v objektech naprogramovat nebo upravit, nečiním tak nikdy s potěšením, jsa přesvědčen, že neobjektově by se to samé dalo napsat mnohonásobně jednodušeji a efektivněji. Vrcholem této nelásky bylo, když jsem cca před 7 lety upravoval pro své potřeby skripty MediaWiki, psané objektově v PHP (které také nemiluji, od doby, co jsem v něm byl kdysi nucen vytvořit redakční systém Britských listů). Nepřehlednosti a programátorská zmatenosti, tvé jméno je MediaWiki!

Javě jsem arci dal ještě jednu šanci, a to ve svém retro-programu, hlavně z toho důvodu, že pokud chci vytvořit software, který bude multiplatformní, mnoho jiných možností se mi nenabízí. Zpočátku to drhlo, např. když jsem zjistil, že optimalisátor z nějakého důvodu odmítne zoptimalisovat switch s velkým počtem variant a aby vůbec začal fungovat, musí se vše rozdělit do method.

Po několika dnech programování se ale ukázalo, že Java pro tuto aplikaci není vůbec tak špatný nápad. Vyloženě jsem si ji zamiloval ve chvíli, když jsem potřeboval implementovat chování podpůrných obvodů v osmibitových počítačích. Tyto obvody (např. 8251, 8253 a 8255) jsou velmi universální a je obtížné zachytit jejich chování čistě procedurální, resp. funkční cestou, a ani klasický event-driven přístup není to pravé.

OOP mi umožnilo vytvořit obecný model, kdy spolu jednotlivé propojené prvky počítače komunikují posíláním zpráv, jejichž formát jsem díky podpoře abstrakce dokázal v Javě vytvořit dostatečně obecně a zároveň robustně: je-li prvkem vodič, je zpráva tvořena informací o tom, zda na něj zařízení posílá nulu, jedničku nebo je ve třetím stavu, periferní obvod komunikuje s procesorem přes porty posíláním jednoho bytu, když budu implementovat disketovou jednotku, může být ve zprávě obsažen celý sektor apod. Jednotlivé objekty, představující prvky hardwaru, postačí propojit tak, jako jsou propojeny v emulovaném počítači, o zbytek se postará Java. Mohu dokonce nechat vypisovat situace, které svědčí o chybě v programu emulovaného stroje, např. že dvě zařízení se snaží táhnout jeden a ten samý pin (v horším případě každé jinam) nebo se naopak čte pin, na který neposílá data žádné zařízení.

A podobně přívětivou se Java ukázala i k propojení GUI s koncovým hardwarem: stisknutí klávesy na klávesnici počítače PMI-80, který emuluji jako první (chtěl jsem, pravda, začít PMD-85, ale tento klenot jsem prostě nemohl opominout), propojí switch v matici, což způsobí, že modul klávesnice bude po předvolenou dobu – počet cyklů mikroprocesoru – reagovat na zprávy o změně úrovně na výstupu skenovacího demultiplexoru, případně přímo na skenovacím pinu 8255 příslušnou zprávou na čtecí pin. Podobně strobované mody obvodu 8255, které přesně emulovat není snadné, se rozdělením na jednotlivé bity a abstrakcí vyřeší jako zázrakem. Potřebujete naemulovat řadič přerušení Intel 8259? Po bitech hračka!

Takto si mohu po libosti sestavovat i přídavný hardware, který původní počítač nemá (např. tuto desku I/O), a po připojení na příslušné piny mi bude vše fungovat samo od sebe, a to samé zařízení mohu připojit např. i k emulátoru Atmel AVR, jediné, co se změní, je zapojení/přiřazení pinů.

Tedy se zdá, že můj vztah s Javou bude nakonec konsumován.

PS: Jakmile bude emulátor funkční, vystavím ho, včetně zdrojového kodu, ku potěše dalších elektro-nostalgiků.

Aktualisováno.

Pomalu se chýlím k závěru, avšak žádná zvláštní infatuace ve vztahu k Javě se nedostavila. Někdy je práce s ní příjemná, třeba když kompilátor najde ve zdrojáku daleko víc chyb než kompilátor C/C++, ale několikrát se mi stalo, že si javac stěžoval na možnost použití neinicialisované proměnné v situaci, kdy z logiky algorithmu vyplývalo, že taková eventualita je nemožná.

Rozpačitý jsem rovněž ze Swingu, který, jak jsem pochopil, se v Oraclu chystají nahradit dalším API, Java FX. Měnit každých pět let API pro GUI nesvědčí o tom, že by firma příliš dobře věděla, kam chce dojít.

Aplikaci PMI-80 mám naprogramovanou ve třech jazykových mutacích (ovšemže nemohla chybět slovenština, jde přece o slovenský stroj!) a čtyřech velikostech, základní framy jsou v absolutních posicích, což by mělo vyloučit většinu problémů. Naprogramoval jsem bohatá rozhraní pro práci s daty, v XML, binárních podobách i všech používaných formátech pro pásek i paměť (a zvažuji, že budu podporovat i ELF, kdyby chtěl někdo překládat GNU Assemblerem). PMIčko funguje hladce a rychle, stejně jako magnetofon. Ještě musím dokončit debugger a vyřešit několik odložených bugů, týkajících se vesměs potíží se Swingem, a poté vygeneruji versi k distribuci a zvážím, zda by mělo smysl upravit program i do podoby appletu.

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!