TeX – 2 (něcoTeX) (diskuse)

[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ží.