Názory k článku Psaní aplikací pro terminál: ošetření vstupů

prima clanek, diky

Jako všechny od Pavla Stěhuleho. Respekt.

Taky se pripojuju.
Jsem moc rad, ze curses/ncurses se jeste nezapomelo.

Pripomina mi to doby DOS a Turbo Pacalu jak jsme kreslili ramecky pomoci ASCII a skryvali kurzor skrz IRQ.

Zrovna se touto cinnosti zabyvam a libuju si ze Windows console uz umi 24bit barvy .-)

A není nějaký C++ wrapper? Tohle C peklo je prostě .... peklo.

Samozřejmě, že existují C++ wrappery. Pokud ale budete používat ncurses API, tak si myslím, že vám to moc kódu neušetří. Jinak docela hezká stará (a nyní zmodernizovaná záležitost) https://github.com/magiblot/tvision

Nauč se Rust a máš vyřešeno.

Nechápu reakci. Jak to souvisí?
Rust řeší C peklo
C++ řeší C peklo taky ne?

C++ ho řeší nedůsledně. Navíc nemá třeba automatickou správu závislostí. Hlavně ale vím, že pro Rust existují snadno použitelné TUI knihovny a nebál bych se je použít, proto to uvádím jako cestu.

To poslední asi beru jako validní argument u jinak trollí reakce, ale ok.

Rust je teď nové řešení na všechno?

@Calculon: Nerozumím otázce. Jako náhrada C a C++ pro interaktivní aplikace mi to přijde jako dobré řešení. Na tohle jsi se ptal?

Byla očividně řečnická. Nic proti Rustu, ale cpát ho všude a všem horem dolem není ta nejlepší strategie.

takze chces z C pekla do C++ pekla :-)

Tak jasně, pokud člověk v C++ používá C techniky, pak souhlas. Peklo to je no.

Tak pekel je podle Danteho devět, první je Limbo Roba Pika (nápadně se podobá Go), druhé je Rust :-)

Doporucuji pouzit normalni jazyk. Mame 21. stoleti. https://github.com/webfolderio/curses4j

Jo, Java peklo. Na to se tady úplně zapomnělo. 🤞

Ak by sa mi napr koli pageru pre db ktory je napisany pomocou ncurses este do pamate natlacil java interpreter, tak by som bol asi dost nevrly...

Tak jsme se zasmáli, a teď vážně: https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub

Zdá se, že Google se chystá rustifikovat C++ (ostatně clang už přidal do C++ lifetimy).

Tohle je strašný, protože ukazuje, jak nesourodý je programming style v C++. Tam bych asi viděl největší problém. Například nemohu v jednom odstavci volat po odstranění raw pointerů a v druhém odstavci navrhovat, aby se pointery které jsou uvolněny přes delete nastavily na null (nehledě na to, že to nic neřeší, protože null-> je obecně UB.

Tady asi C++ není exaktní řešení. Maximálně se shodnout na tom, co je safe programovací a co není (RUST a jiné managed jazyky samy oddělují safe a unsafe kód). A tahle shoda musí jít na úrovni zápisu bez zásahu do generování kódu (různé snahy protlačit do C++ GC a podobně). Pokud jde o managování vlastnictví tak ať klidně do C++ zavedou nový typ reference, třeba ^p (namísto &p) - kritice se to stejně nevyhne, protože kdo mi zabrání použít stary typ reference (safe a unsafe directivita?). Nemám u C++ problém s oddělením levely zabezpečení kódu - sám bych asi používal ten nejvyšší, ale chci si nechat prostor pro dočasného snížení levelu protože potřebuju udělat něco, co by na vyšším stupni bylo vysoce neefektivní.

Vypadá to, že po deseti letech v Googlu objevili C++11 :)

To je mi diskuse!
Nedaly by se ty příklady psát v Pascalu? To je přeci takový dobře čitelný a školometský programovací jazyk... ;oD

To jsou nervy! To bylo hodně těžké dočíst. Když s něčím začínáš, tak o tom nepiš, protože až později zjistíš, že jedné polovině nerozumíš a druhou máš taky blbě.

Díky za názor a kritiku.

Když jsem s ncurses začínal, tak jsem o této knihovně fakt nevěděl vůbec nic. Teď po 4 rokách vývoje (z toho poměrně 2 intenzivního) pspg a ncurses-st-menu si troufám tvrdit, že o ncurses už něco vím. Motivací pro tuhle sérii článků je učitá osvěta - jelikož jsem zjistitl, že moje povědomí o ncurses nebylo předtím úplně špatné, ale bylo nedostatečné - některé základní konceptuální věci mi uniklaly, a nikde jsem se o nich nedočetl.

Druhým důvodem je popis několika triků, o kterých se běžně nedočtete - pspg je celosvětově druhým pagerem napsaným nad ncurses, a z pohledu UI prvním, který nabízí CUA TUI (drtivá většina TUI aplikací v Linuxu nejsou CUA, a mají výrazně jednodušší interface). Abych se dostal do stavu, kdy jsem spokojený s rychlostí a vzhledem, tak pořešit pár problémů, kdy jsem musel procházet zdrojáky, případně komunikovat s maintainerem, protože nikdo jiný na planetě neporadil.

Můj styl psaní i výuky je dost založený na ukázkách, jak něco dělat špatně, a jak něco dělat lépe. Osobně mi nestačí, když mi někdo ukáže jen jednu dobrou variantu, protože mne napadají i další varianty, a chybí mi pak znalost proč vybrat zrovna tu a upozadit druhou variantu.

10. 9. 2021, 06:24 editováno autorem komentáře

A rovnou vás napadne, proč nepoužít tu samou knihovnu readline.
Co pamatuju, klasickým důvodem proč nepoužit readline bývala licence - viz např. https://github.com/JoshCheek/clisp/blob/master/doc/Why-CLISP-is-under-GPL (ok, 1992, mohlo dojít k posunu, ale ještě o pár let později jsme ji kvůli tomu nepoužili - shodou okolností také v db konzolovém klientu).

K posunu nedošlo - readline je stále pod GPL. Existuje několik alternativ - ať kvůli licenci nebo nárokům na zdroje.

K posunu mohlo dojít jen teoreticky, v praxi se to očekávat nedá. Naopak, FSF ve svém traktátu vyzývajícím používat GPL místo LGPL i pro knihovny uvádí právě readline jako příklad knihovny, kde je (podle nich) vhodnější použít GPL.

Prošel jsem si tento díl a vnucuje se otázka, proč (ne)použít ncurses, když je s tím tolik práce. V dnešní době, sám za sebe, bych se snažil využít nějakou knihovnu vyšší úrovně, pravděpodobně s jiným programovacím jazykem, jak asi z diskuse výše vyplynulo.

Jsem zvědav na poslední díl - bude tam nějaké spojení poznatků z minula v jednu funkční aplikaci, byť třeba jednoduchoučkou. Hrozně rád bych si to reimplementoval a ověřil, že jsou všechna ta úskalí vyřešena taky.

Za "jednoduchoučkou" měl být otazník. Nepovedlo se mi to opravit v časovém limitu.

Těch důvodů proč nepoužít ncurses bude celá řada - nejsou modulární, není tam podpora pro tvorbu komponent, a tudíž existují jen tři rozšiřující komponenty, občas se chovají "divně", protože dost funkcionality je implementováno tak, že se o ni stará terminál nebo se emuluje v ncurses (a vy jako autor nemáte jistotu na co se spolehnout).

Na druhou stranu pořád je to poměrně lehká a jednoduchá knihovna, která nemá zbytečně moc vrstev. Je všude a v sobě nese brutálně velkou knowleadge base. Terminály jsou hrozná bažina, a od toho vás ncurses v 99% odizoluje. Navíc implementuje jakýs double buffering a optimalizaci tisku (tiskne se jen změněný obsah). To knihovny, které jedou nad ANSI terminálem většinou nedělají.

20 let dělám s Cčkem, protože je Postgres v Cčku, takže nemám s Cčkem problém, a naopak mi vyhovuje, že se pohybuji plus mínus na podobné vrstvě abstrakce jako v Céčku - a u pageru chci rychlý start, a na to je ncurses ideální.

Určitě bych nechtěl psát komplexnější aplikaci v ncurses. Návrh formulářů je peklo (z dnešního pohledu). Na druhou stranu nemusí být na škodu se s ncurses seznámit, když se zajímáte o TUI. Je to nejrozšířenější API, které žije velice těsně nad hw vrstvou, a přitom pokrývá prakticky veškerý dostupný hw (včetně sw emulací). Je to podobné jako s assamblerem - nemusíte v něm psát, ale čím víc o něm víte, tím snáze ladíte nejrůznější špeky

Dík za odpověď. Bude prosím teda nějaká "sloučená" aplikace pro referenci?

O žádné takové aplikaci jsem zatím neuvažoval. Ale můžete se podívat na demo ncurses-st-menu https://github.com/okbob/ncurses-st-menu/tree/master/demo případně na pspg https://github.com/okbob/pspg/blob/master/src/pspg.c - ale spíš ta dema k st-menu.

Děkuju, za mě asi stačí. Beru, že cíl miniseriálu je asi ohraničený jinak, než by se hodilo pro mnou nastíněný nápad.