TeX – 2 (něcoTeX)

17. 10. 2013 | Petr Olšák | Různé | 6287×

Učiníme-li první procházku po TeXové distribuci, záhy narazíme na pojmy LaTeX, AMSTeX, eTeX, pdfTeX, encTeX, ConTeXt, LuaTeX, XeTeX, XeLaTeX a mnohé další. V krátkosti si tyto pojmy vysvětlíme.

Obsah

• TeX a jeho formát
  • Přehled používaných formátů
• Rozšíření TeXu

TeX a jeho formát

Před výkladem uvedených pojmů nejprve odbočím a vysvětlím, co to je TeXový formát. Programu TeX se nejprve předloží makra, metriky fontů, vzory dělení slov a příkaz \dump, který způsobí, že TeX nabyté vědomosti ze své paměti uloží do binárního souboru s příponou fmt (tzv. formátu). Při zpracování dokumentu se pak TeX volá například takto:

tex -fmt soubor.fmt dokument

TeX si nejprve obnoví dříve nabyté vědomosti z binárního souboru a pak teprve čte specifikovaný dokument, kde mohou být doplňující makra, příkazy k načtení metrik dodatečných fontů a vlastní text dokumentu. Důvod tohoto dvoufázového přístupu je zejména rychlost: při opakovaném zpracování dokumentu není třeba znovu číst makra a fonty, které jsou už načteny ve formátu. Dnes sice tento důvod není tak významný jako dříve, ale i tak zůstává koncept dvoufázového zpracování zachován. Formáty (tedy zhruba sady přednačtených maker, fontů a vzorů dělení slov) se generují v distribuci obvykle automaticky bez zásahu uživatele. Ten pak jen vhodným příkazem volí, který formát chce použít. Napíše-li na příkazový řádek latex, spustí se TeX s předgenerovaným formátem latex.fmt, napíše-li csplain, spustí se TeX s formátem csplain.fmt atd.

V dávných dobách existovaly dvě binárky TeXu: iniTeX se specializoval na generování formátů a virTeX formát použil a zpracoval dokument. Ta první binárka byla svými schopnostmi nadmnožinou druhé: uměla navíc příkaz \patterns pro čtení vzorů dělení slov a již zmíněný \dump pro uložení obrazu paměti. Důvodem existence ořezaného virTeXu byla snaha šetřit pamětí počítače při zpracování dokumentu (algoritmy pro \patterns zabírají v binárce místo navíc). Již cca 20 let se ale toto dělení na iniTeX a virTeX nepoužívá a pracuje se s jedinou binárkou, která má typicky přepínač -ini, aby fungovala jako iniTeX. Bez tohoto přepínače jsou uvedené algoritmy kolem příkazu \patterns a \dump deaktivovány. Takže bez přepínače -ini nelze zavádět do paměti dodatečně další vzory dělení slov (dalších jazyků). Ustálila se tedy praxe, že všechny použité jazyky musejí mít vzory dělení načteny v době generování formátu. Když tedy chce uživatel použít další jazyk, který nemá vzory dělení načteny při generování formátu, nestačí jazyk nějak vyznačit v dokumentu. Je třeba taky upravit konfiguraci jazyků pro generování formátů a formát přegenerovat. Aby distribuce TeXu zmírnily tuto komplikaci, načítají do formátu co nejvíce vzorů dělení slov a dále nabízejí uživateli nějaké své rozhraní na generování formátů (např. v TeXlive je na to skript fmtutil).

Přehled používaných formátů

formát	verze	engine	příkaz	komentář
plainTeX	3.141592653	TeX	tex	základní makra (Donald Knuth)
LaTeX	2e	eTeX	latex	autorská tvorba dokumentů
pdfLaTeX	2e	pdfeTeX	pdflatex	LaTeX + PDF
CSplain	Sep. 2013	encTeX	csplain	plain + čeština, slovenština (Petr Olšák)
pdfcsplain	Sep. 2013	pdf+encTeX	pdfcsplain	CSplain + PDF
eplain	3.5	eTeX	eplain	plain + tvorba dokumentů (Karl Berry)
XeTeX		XeTeX	xetex	plain + XeTeX
JadeTeX	3.13	eTeX	jade	SGML dokumenty (Sebastian Rahtz)
XeLaTeX		XeTeX	xelatex	LaTeX + XeTeX
LuaTeX		LuaTeX	luatex	plain + XeTeX
LuaLaTeX		LuaTeX	lualatex	LaTeX + LuaTeX
ConTeXt.	MKII	pdfeTeX	texexec	projekt Pragma ADE (Hans Hagen & all)
ConTeXt.	MKIV	LuaTeX	context	ConTeXt + LuaTeX

Sloupec „engine“ označuje použité rozšíření TeXu. O tom pojednává text následující sekce.

Sloupec „příkaz“ označuje příkaz, kterým se spustí odpovídající „engine“ s příslušným formátem. Např. tex document spustí TeX s formátem plain. Jak to je uděláno, řeší každá distribuce v závislosti na hostujícím operačním systému po svém. Poznamenejme, že tex -ini soubor spustí iniTeX bez formátu a příkaz je určen k vygenerování formátu, zatímco tex soubor spustí virTeX s formátem plain.

Kromě formátů v tabulce existuje ještě mnoho dalších. AMSTeX přidává k plainTeXu makra a další fonty pro matematickou sazbu. Není ale nutné použít speciální formát: stačí v plainTeXu psát \input amstex přímo v dokumentu nebo v LaTeXu použít balíček amsmath.sty. MeX je plain, který si vytvořili Poláci, pTeX umožňuje sazbu japonštiny...

CSTUG dlouhou dobu udržoval českou verzi LaTeXu zvanou CSLaTeX. Loni už přišli na to, že to nemá význam a jen to komplikuje uživatelům život. Další vývoj i udržování CSLaTeXu ukončili. Na jejich pokyn jsem do CSLaTeXu přidal hlášení, které TeX při použití tohoto formátu vypíše na terminál, že je to zastaralá verze. Češtinu a slovenštinu lze v klasickém LaTeXu použít prostřednictvím balíčku babel.sty.

Rozšíření TeXu

V roce 1991, kdy Knuth zmrazil vývoj TeXu, zůstal jeho program schopen pracovat jen s 8bitovými fonty a s výstupem do DVI (device independent). To je binární výstupní formát, na který je třeba navázat dalším programem (tzv. ovladačem), který výstup zobrazí na obrazovce (např. xdvi) nebo dokument vytiskne na tiskárně (např. dvips převede dokument do PostScriptu pro tisk). Knuth ve své licenci dává TeX k volnému použití, ale ponechává si „patent na název“. Nic se nesmí nazvat TeX, co se přesně nechová podle jeho rozsáhlé dokumentace a co neprojde náročnými testy trip. Pouze Knuth je oprávněn opravovat chyby, což činí jednou za mnoho let. Tím patentem na název je uživatel ochráněn před živelným vývojem programu. Je tu pevný základ, na který se dá spoléhat, že bude fungovat stejně napořád.

Toto vypadá lákavě, ale má to stinné stránky: nové požadavky na program plynoucí z nových technologií nebudou zapracovány. Navíc TeX je napsán sice po dokumentační stránce zcela excelentně, ale je to monolit, do kterého opravdu může dloubnout jen jeden člověk: hemží se to tam např. mnoha globálními proměnnými, jejichž změna na jednom místě způsobí změněné chování desítek procedur na místě jiném. Pro týmovou práci se to naprosto nehodí. Pokusy o modifikaci TeXu či dokonce jeho přepsání do něčeho modernějšího tu sice byly, ale mnohdy nebyly moc úspěšné. V následujícím textu shrnu tedy jen ty pokusy, které úspěšné byly a přežívají v distribucích dodnes, nebo dokonce udávají další směr. Veškeré modifikace TeXu se z důvodu Knuthovy licence nesmí jmenovat TeX, ale typicky jsou označeny jako něcoTeX. Všechna níže uvedená rozšíření vycházejí z Knuthova kódu a co nejopatrněji do něj zapracovávají nový rys.

Program eTeX rozšiřuje TeX o další příkazy, které začaly některým uživatelům chybět záhy po zmrazení TeXu: více číslovaných registrů, možnost sazby zprava doleva (arabsky) a některé další fiškuntálie.

Program pdfTeX rozšiřuje TeX o možnost výstupu do PDF při nastavení registru \pdfoutput=1. Implicitně je i v pdfTeXu nastaven výstup do DVI (\pdfoutput=0), takže se chová jako klasický TeX. Při výstupu do PDF přidává pdfTeX možnosti programovat interaktivní vlastnosti dokumentu, které PDF formát přináší (např. hyperlinky) a dále přidává některá jemná mikrotypografická rozšíření.

Rozšíření encTeX je můj příspěvek do TeXové komunity, umožňující mimo jiné 8bitovému (pdf)TeXu číst UTF-8 vstup. Vstupní znaky nebo sekvence znaků mapuje na řídicí sekvence tvaru \cosi, které mohou být v TeXu definovány jakkoli.

Dnes se v distribucích obvykle používá i pro emulaci klasického TeXu binárka pdftex, která obsahuje eTeX, encTeX a pdfTeX dohromady. Rozšíření eTeX se zapne při generování formátu přepínačem -etex nebo hvězdičkou před názvem souboru a rozšíření encTeX probudíte k životu přepínačem -enc.

Výrazným posunem vpřed, kterému budu věnovat podrobněji některý z dalších dílů, jsou rozšíření umožňující pracovat se současnými fonty v UNICODE (OpenType fonty). Existují dvě různé vývojové větve: XeTeX a LuaTeX. Obě mají výstup do PDF.

Nejprve ale bylo nutno vyřešit interní reprezentaci znaků v TeXu v 16 bitech, což odstartoval projekt Omega. Toto rozšíření se v současné době moc nepoužívá, ale ze zdrojových kódů Omegy obě následující rozšíření vycházejí.

XeTeX [zítech] linkuje systémovou knihovnu na fonty (např. knihovnu fontconfig pro Linux) a umožňuje číst fonty instalované v systému. Klasický TeX totiž se systémovými fonty nespolupracuje: má své fonty přímo v instalaci a přidávání dalších fontů do TeXu může začátečníkovi činit i značné potíže. Interně XeTeX vystupuje do DVI (16bitové DVI) a na tento výstup přímo navazuje program xdvipdfmx, který bez nutnosti uživatelova zásahu výstup konvertuje do PDF.

LuaTeX linkuje knihovnu interpretačního jazyka Lua. Pomocí příkazu \directlua{kód} lze vkládat Lua kód, přitom některé elementy jazyka Lua jsou přímo napojeny na algoritmy TeXu a umožňují tím změnu jeho chování. Je tedy možné kombinovat programovací jazyk TeXu a Lua. Kódem v \directlua se typicky nejprve vyjmenují všechna rozšíření, která LuaTeX má umět: eTeX, pdfTeX, Omega. Také je pomocí Lua kódu implementováno čtení OpenType fontů.

Poznamenávám, že i 8bitový TeX (např. pdfTeX) umožňuje využít všechny znaky z OpenType fontu. Jak to udělat, bude popsáno v některém dalším dílu seriálu.

Od tohoto poněkud teoretičtějšího dílu si příště odpočineme a ukážeme motivační příklad.

       

Komentáře

[dgvdtfdsffx]

kdysi nekdo zacal psat New Typesetting System v jave, zije jeste neco takoveho?

[olsak]

New Typesetting System (NTS) byl projekt podporovaný německou skupinou uživatelů TeXu (Dante) a v týmu byl hlavní progamátor čech Karel Skoupý. Mám-li o tom správné informace, pak skutečně přepsali TeX do Javy a jejich prvním cílem byla 100% kompatibilita s Knuthovým TeXem, tj. aby to prošlo testem Trip. Tohoto cíle dosáhli cca v roce 2000. Výsledek byl daleko pomalejší, než klasický TeX, navíc tam neměli běžná rozšíření, která v té době už byla víceméně standardem a byla žádaná: pdfTeX, eTeX. To byl jeden důvod, proč se to neujalo. Dále jsem slyšel, že výsledný kód byl sice napsán v objektovém jazyce, ale vzhledem k požadavku 100% kompatibility s TeXem nakonec výhoda objektového programování z toho kódu nějak vyprchala a objektově se na to navazovat asi moc nedá. Takže projekt se dále nerozvíjel. Výjimkou je navazující projekt ExTeX, který do NTS kódu přidává vlastnosti eTeXu a pfTeXu, ale zase pozdě a není to zřejmě dotaženo. ExTeX (rok cca 2003) zůstal v alpha verzi.

[Miloslav Ponkrác]

Chyba byla ta 100% kompatibilita s TeXem.

IMHO nemá smysl dělat něco, co je s TeXem na 100 % kompatibilní.

Navíc si myslím, že pokud by někdo dělal ideového nástupce TeXu, že by měl z TeXu vyhodit mnoho artefaktů, které už jsou překonány.

Například by měl nástupce být striktně založen na Unicode. Vyhodit kategorie znaků (i když se s tím dají dělat různé vylomeniny), zejména možnost kategorie znaků měnit.

Dodat lepší makrovací jazyk. Přidat možnost matematických výrazů do makra. Ideální posadit to na skutečný schopný programovací jazyk.

Do základů dodat geometrii, barvy, a další.

Dělat 100% kopii TeXu nemá sebemenší smysl, věděl jsem to už tehdy, když projekt v Javě začal.

[knedlik]

existuje nieco ako "realtime" kompilator ? potrebujem pisat "kod" a hned vidiet ako to bude vyzerat v PDF, lebo pri pisani zlozitejsich rovnic a mat. vyrazov je to pre mna system pokus-omyl.

[jiřík]

WYSIWYG editor pro LaTeX - LyX či jak se to jmenuje.

[Jakub Lucký]

Nevím, jestli to funguje i pro TeX, ale Gummi tohle umí...

[klusik]

Doporucuju program texmaker, ktery umi delat nahled strany.

[knedlik]

dikes vsetkym, poskusam to

[jiřík]

Texmaker není úplně živý náhled, ale Texmaker nepoužívej a nainstaluj si rovnou Texstudio. To je dá se říct fork (nebijte mne jestli ne, prostě něco v tom smyslu) Texmakeru a doplnilo několik klíčových funkcí (třeba stromová struktura otevřeného dokumentu a do něj vkládaných kapitol a externích tabulek). Jo kdybych před dvěma lety psal bakalářku v Texstudiu ...

[olsak]

Proč tomu neříkají LaTeXstudio, resp. LaTeXmaker? Proč nenazývají věci pravými jmény? Vypadá to, že když chci použít TeX, a přitom ne LaTeX, tak mi to k ničemu nebude.

[jiřík]

No za to já rozhodně nemůžu ...

[jiricek]

Texmacs

[vencas]

To někdo používá? Mně se to líbilo před 5 lety, ale vývoj nula. Jako rozhraní k matematickým programům možná fajn, jinak bych v tom nepsal. A TeX to mimochodem interně nepoužívá.

[Jakub Hendrich]

Zdravím, chodil jsem k vám "do TeXu" myslím v roce 2001 nebo 2002, bylo to fajn a děkuju i za seriál.

Ta poznámka o Knuthově programovacím stylu mě překvapila. Mám před sebou první dva svazky Umění programování, je to opravdu hutné a přínosné čtení, ale o samotném řemesle pramálo (to ani nebylo účelem monografie). Nicméně - právě jsem tam objevil zmínku, kterou chápu tak, že autor dle svých slov dospěl k vyzrálému stylu programování někdy mezi lety 1964 - 1980, tj. TeX by tohoto stylu měl být příkladem.

Tak nějak ho v mých očích polidšťuje, že není expertem v každém aspektu oboru. :)

[Tomáš]

Donald Knuth se v té knize zabývá spíš algoritmy a teoretickými otázkami (třeba rozbor generování náhodných čísel stál za to). Styl programování je taky slovo do pranice, v těch letech frčelo procedurární programování, C++ ještě nebylo, smalltalk sice byl, ale bohužel se masově nerozšířil, objektové programování jaksi nefrčelo.

[Josef Kufner]

Ono programování, pokud mluvíme o "stylu" a nikoliv o algoritmech, je pořád ještě v plenkách.

[Jakub Hendrich]

Ano, jde hlavně o algoritmy/datové struktury, a to pěkně do hloubky s důkazy a cvičeními.

Což o to, nemám nic proti procedurálnímu programování (obecný styl nebo paradigma), spíš mě zarazilo to nadužívání globálních proměnných (osobní styl), to rozhodně není zapotřebí.

[Stanislav Brabec]

Knuth vyvinul svůj vlastní preprocesor kódu (či metajazyk) WEB, který umožňuje psát kód, jako by ty proměnné byly lokální. Ovšem lokální nejsou, takže je na programátorovi, zda je v případě potřeby použije i jinde.

A v roce 1978 byla jasná volba: Pokud využití „lokální“ proměnné v jiné části kódu ušetří deset řádků, vyplatí se to. Dnes jsou programátoři zhýralí, mají v počítači paměti, že nevědí, co s ní, takže dají přednost stylu před efektivitou. Takové zneužití jedné proměnné v jiném místě kódu ušetří třeba tahání reference po zásobníku v deseti mezivrstvách, vytváření objektů, metod, konstruktorů a destruktorů (či struktur, podstruktur a callbacků v méně cool jazycích) jen proto, abychom náhodou nepoužili lokální proměnnou.

Reentrantnost kódu se tenkrát neřešila, relokovatelnost také ne. Ostatně, kdo tenkrát chtěl pouštět dvě instance programu, když byl rád, že si našetřil dost na to, aby spustil jednu. Paměťové požadavky T_EXu byly z tehdejšího pohledu nemalé, a formátování T_EXbooku, které dnešní počítače zvládnou (i se všemi dodatky) v řádu milisekund, trvalo tenkrát dlouhé minuty.

[olsak]

Přesně totéž jsem se chystal odpovědět. Ten web preprocesor umožňuje, že se proměnné směrem k člověku mohou tvářit jako lokální a navíc se tím ušetří režie, která v té době vůbec nebyla nezanedbatelná.

Knuth zřejmě zaznamenal další vývoj, který počítače učinily za jednu lidskou generaci, a velmi trefně to shrnul ve své přednášce. Doporučuji si udělat čas a podívat se na tu půlhodinku. S nadhledem a humorem tam představuje nového následníka všech následníků TeXu, kterého nazval iTeX (zvonek).

[Miloslav Ponkrác]

Dnes nejsou programátoři zhýralí. Optimalizátor jazyka při kompilaci tyto optimalizaci udělá sám a lépe. Lidská invence a ztrácení času zrovna v této věci nic neušetří, spíše naopak.

Přiznejme si, že pro kompilátor není problém mít přehled nad miliónem identifikátorů a jejich přiřazením, pro člověka je to nemožné.

Ostatně i to pravidlo, že identifikátory by se neměly mít větší rozsah viditelnosti, než je nezbytně nutné, je vlastně přiznání neschopnosti lidského mozku to uřídit.

A zde je důvod, proč se dříve znásilňovaly lokální proměnné jako globální. Protože projekty byly malé a koncentrovaný člověk to ještě zvládal v krajním případě.

Zhýralost dnes vidím spíše v tom „znásilňování proměnné“ namísto „tahání reference přes 10 mezivrstev“. Protože u dobrého kompilátoru to druhé se dostane na efektivitu té prasečiny znásilňující proměnné.

Miloslav Ponkrác

[Stanislav Brabec]

Jedno i druhé nakonec skončí jako strojový kód procesoru. Tam jsou jen adresy v paměti, registry a kód. Žádné typy, objekty, proměnné a rozsah viditelnosti tam neexistují. To vše je zde jen pro programátora, nikoliv pro stroj.

Ani ten nejlepší kompilátor vám z proměnné uvnitř objektu neudělá globální proměnnou, a to ani pokud je v takovém kontextu využívána (tzn. existuje jen jedna instance objektu).

Tahání reference se stalo v některých jazycích natolik standardním postupem, že reference na objekt this se předává vždy, a efektivně tak trvale zabírá jeden registr procesoru. Vyhledání takové skoro globální proměnné v instanci nejvyššího nadřízeného objektu pak vždy bude komplikovanější, než prostá reference na pevné místo v paměti. A to i přes optimalizované ukládání mezivýsledků.

Takže vlastně vše kromě programování ve strojovém kódu je zde pouze pro pohodlí programátora, pro přenositelnost a znovupoužitelnost.

[Miloslav Ponkrác]

Mýlíte se. I strojový kód je ústup pohodlnosti. Daleko efektivnější by bylo přímo instrukcemi adresovat a řídit jednotky uvnitř procesoru, jak některé (nex86) procesory dělají.

V zásadě už strojový kód je vyšší programovací jazyk, který je většinou dále překládán v x86 poměrně složitě dále uvnitř procesoru na jednodušší mikrokód a/nebo na akce k jednotkám.

Mě ani tak nezajímá, jestli kompilátor udělá z nějaké proměnné globální, ale jaké jsou vlastnosti výsledného kódu. Ono nadělat globální proměnné znamená třeba to, že se díky přístupu jinam začne vysypávat cache procesoru a efektivita je náhle ve psí. Věci nejsou tak jednoduché a prosté jak se zdají.

Dále samozřejmě proměnné uvnitř objektu mohou být z hlediska umístění v paměti globální, říká se jim statické členy tříd.

---

Abych řekl pravdu, takovéto stesky považuji za nesmysl. Programuji přes 35 let, a vím, co bylo tehdy a dnes. V době Knutha byly kompilátory velmi špatné a špatně optimalizující. Bylo to proto, že C bylo zpočátku rychlovaška, a tak se také implementovala. Navíc omezené rychlosti procesorů a paměti počítačů nedovolovaly kompilátoru použít příliš efektivní metody optimalizace. Dnes jsou optimalizace a schopnosti kompilátorů zcela jinde – a snahy „psát optimalizovaně“ ve smyslu honění pikosekund působí obvykle tak, že výsledný program je pomalejší.

Dnešní procesor není jednoduchý a jeho rychlost je závislá na stovkách věcí. Je tu několik keší, pořadí strojových instrukcí má obrovský vliv, některé instrukce jedou paralelně, jiné ne. Pak jsou tu různé predikce kódu a desítky dalších ptákovin.

Věci, které je možné udělat automaticky, tj. to, co dělá Knuthův WEB + řada dalších, udělá každý dnešní slušný kompilátor lépe, než Knuthovy věci. Na rozdíl od Knuthových nástrojů k tomu udělá lepší matematickou analýzu a optimalizaci, zahrne daleko více aspektů do rozhodování co a jak zkompilovat a výsledek je mnohem lepší. Je jiná doba, než při vzniku TeXu.

[petr_p]

V objektovém přístupu bývají proměnné zabalené do struktur (objektů) a třebaže programátor úzkostlivě předává objekt přes parametry, tak na zásobníku nebude nic než ukazatel, takže až se funkce nakonec rozhodne přistoupit k proměnné, tak se krásný lokální ukazatel na zásobníku dereferencuje na globální proměnnou, která v keši nebude.

A stejně to dopadne i při neobjektovém paradigmatu, kdy nakonec programátor rezignuje na předávání každé proměnné argumentem (protože počet argumentů by vzrostl na nezvladatelný počet) a prostě je zabalí do struktury a bude předávat jen ukazatel na ni.

Jistě že dnešní překladače jsou jinde. Ale ty optimalizace jsou povětšinou jen lokální. Je jich moc. To ano. Ale stále jsou lokálního charakteru (tuhle funkci má smysl inlinovat, tady ušetřit tail-call, tuhle opakující se dereferenci lze nakešovat, tahle proměnná je ve skutečnosti konstanta, tahle podmínka nikdy nebude splněna). Představa, že překladač převede dereferenci objektu v desáté úrovni zanoření na globální proměnnou, „aby se zbytěčně netahaly ukazatele přes zásobník“, je naivní.

[Miloslav Ponkrác]

Ale houby s octem. Pište o tom, čemu rozumíte.

Pomíjím to, že nechápete pojem statické proměnné třídy.

Chápu, že nerozumíte tomu, že objekt lze celý uložit na zásobník. Takže předání ukazatele do dalšího podprogramu může třeba obsahovat ukazatel na data, která jsou o 10 bajtů dále za vrcholem zásobníku.

Chápu, že naprosto nerozumíte tomu, jak dnešní kompilátor optimalizuje. Chápu, že nechápete, že dnešní kompilátor, tedy dobrý kompilátor C/C++, nikoli velmi špatně optimalizující gcc, optimalizuje dosti globálně. A do optimalizace už je dnes zahrnován i linker, který dokáže hodně dotáhnout. Linker už je dnes v podstatě nedálná součást optimalizátoru i kompilátoru a na globální úrovni se dělá leccos.

Ta představa v poslední větě je docela reálná a i to kompilátor zvládne, když dokáže odvodit, že to lze.

Prostě doporučuji se vyjadřovat na téma, kterému aspoň trochu rozumíte.

[Stanislav Brabec]

Na zásobník si kompilátor může uložit pouze objekt velikosti známé v době kompilace, který zaručeně zanikne dříve, než dojde k návratu z funkce. Vše ostatní musí ukládat do haldy. Změna velikosti objektu na zásobníku směrem nahoru není možná, a kód, který by umožňoval referenci na zásobník s předem neznámým indexem by vyžadoval ukazatelovou aritmetiku. Proto se na zásobník ukládají pouze data velikosti známé už v době kompilace. (Což je mimochodem důvod, proč původní jazyk Pascal umožňoval jen staticky deklarovaná pole.)

Většina objektů (s výjimkou jednoduchých typů jako Complex) je ale stejně interně uložena jako struktura s ukazateli, takže na zásobník se většinou uloží pouze pár odkazů do haldy.

Přímý odkaz na zásobník volajícího podprogramu je sice možný, ale aby fungoval, musí být funkce volaná vždy stejnou volací sekvencí funkcí mezí, a funkce musí být funkce statická (exportovaná funkce může být použita v předem neznámém kontextu, kde by tato přímá reference nefungovala). Nejsem si jist, zda to některý optimalizátor umí. Ve všech ostatních případech se musíte spolehnout buď na předaný ukazatel (jeden registr trvale obsazený), nebo na ukazatel zásobníkového rámce (frame pointer; ten sice nezabírá registr, ale každá reference na nadřízenou funkci znamená vystoupání po ukazatelích rámců, tedy jednu položku na zásobníku navíc na každou funkci, a jedno čtení navíc na každý stupeň vynoření).

[petr_p]

Chápu, že nerozumíte tomu, že objekt lze celý uložit na zásobník. Takže předání ukazatele do dalšího podprogramu může třeba obsahovat ukazatel na data, která jsou o 10 bajtů dále za vrcholem zásobníku.

K čemu mi bude dobré ukládat na zásobník kopii objektu, když tam můžu chtít vidět data změněná jinde a hlavně měnit data daného objektu, tak aby byla změna vidět i jinde nebo po návratu z funkce?

[Stanislav Brabec]

Knuthův WEB je vlastně textový preprocesor jazyka Pascal (a odvozenina WEB2C je navíc konvertorem do C). Nedělá nic jiného, než že přesouvá bloky textu seřazené tak, jak se to líbí programátorovi, do bloků kódu tak, jak se to líbí kompilátoru (program tangle), nebo tak, jak se to líbí TeXu (program weave pro dokumentaci kódu), a dělá drobné záměny.

Statická deklarace polí v TeXu (zdrojový kód) zároveň znamená, že se TeX obejde bez ukazatelů a haldy (angl. heap), tedy bez alloc(), malloc(), free() a jejich režie.

[Miloslav Ponkrác]

Chápu, že jde o preprocesor, ale více než o optomalizaci opěvované nad vámi jde o dokumentované programování, o což šlo Knuthovi především.

Správná definice je, že přesouvá bloky tak, jak se to líbí Knuthovi. Kompilátoru se líbí i běžný zdrojový kód v C/C++, který se líbí programátorovi. Navíc nikdo nenutí žádného programátora používat funkce malloc/alloc/free.

Jinak to, že se TeX obejde bez heapu, neznamená, že zkompilovaný program, byť přes Knuthovy nástroje, heap nepoužívá. A tedy interně funkce malloc/alloc/free.

Už takové otevření souboru začíná často interně malloc(sizof(FILE)).

[Stanislav Brabec]

WEB opravdu není optimalizátorem, ani trochu. Vstupem WEBu není běžný zdrojový kód v C (v době, kdy Knuth psal TeX, tak Kernighan a Ritchie svou slavnou knihu The C Programming Language také teprve psali), a dokonce ani běžný zdrojový kód v Pascalu. Proměnnou deklarujete tam, kde jí potřebujete. Stejně tak inicializaci struktur napíšete poblíž místa, kde jsou použity. A WEB je seřadí tak, jak se na zdrojový kód v Pascalu sluší a patří.

Z pohledu moderního objektového programátora je WEB nejspíš ďábelský nástroj na to, jak prasit hromady nesouvisejícího kódu do jedné funkce, používat globální proměnné, a přitom se v tom stále vyznat.

Z tehdejšího pohledu je to nástroj, jak rozumně programovat velký kód s minimální režií.

Pravda, TeX si nalinkuje libc, a ta už malloc() používá. A kompilátor možná nějaké z nich inlinuje i do TeXu.

[w4rr10r]

lisp

[vencas]

Ještě byl taky ctex, implementace TeXu v c++ - zdrojáky snad zde. Plány byly (IIRC) sazba "nekonečně vysokých" stránek do DVI, něco jako průběžná HTML stránka. Aktivita už dlouho žádná.

[vencas]

Aha, už jsem to našel, byl to TeX++.

[TyPo]

Velmi děkuji za tento seriál i knížku TeX pro pragmatiky. Něco takového hledám už dlouho. Všude je samý LaTeX (který je pěkný v případě, že člověku vyhovuje hotový styl a nechce do toho moc vrtat, ale jinak je to poměrně složitý moloch), ale pěkně popsané základy TeXu a Plainu jsem nikde moc nenašel. Moc se těším na další díly. Hlavně ty obecné principy, jak to D. Knuth zamýšlel atd., proč to funguje tak, jak to funguje, progamování maker, širší souvislosti a věci okolo ("něcoTeXy" apod.). Detaily typu, jak se píše nějaký znak v matematické sazbě apod., si člověk bez problémů najde. Následně s TeXBook naruby to bude dokonalé :)

1. Také by mě na úvod zajímalo, jaké má TeX největší omezení. V čem tkví např. problémy při "rámečkové" sazbě (noviny, časopisy, ..., pro což se moc nepoužívá). Tedy které věci z praxe se v TeXu dělají velmi obtížně a jsou s tím problémy (+ jaké problémy a proč).
2. Existuje něco jako minimální distribuce TeXu? Distribuce jako TeX Live, MiKTeX apod. jsou ohromné molochy, které obsahují spoustu věcí od dalších lidí. Nicméně, i když lze nainstalovat jen část z toho, tak mi to přijde příliš rozsáhlé a nevím, co patří do základu TeXu (jak to navrhl D. Knuth - tedy zřejmě TeX, Metafont, fonty Computer Modern, Plain, ...) a co jsou nějaké přídavky navíc). Rád bych pochopil, co v tom základu je a k čemu co slouží.