Textilosaurus - textový editor (hobby projekt)

14.12.2017 11:16 | Přečteno: 3391× | OSS |

Tak nějak jsem byl nespokojen s textovým editorem, co jsem používal na Linuxu (Geany), nelíbil se mi třeba způsob definice externích příkazů a pár dalších bugů (hlavně ve vykreslování Scintilly). Tak si píšu svůj textový editor.

Repo najdete tady. Na wiki mám i takový jednoduchý přehled některých funkcí.

Externí příkazy

O tohle mi šlo hlavně, chtěl jsem, abych si mohl přehledně definovat jednotlivé externí tooly a zároveń si je dát do kategorií (podmenu).

Portabilita nastavení

Další věc je, aby fungovalo sdílení nastavení (třeba přes Dropbox) mezi různými platformami. U ostatních prohlížečů se mi většinou stávalo, že třeba ty definice externích utilit mi nefungovaly, i když jsem měl daný interpret (bash) dostupný na obou mašinách (windows a linux). Taky se mi stávalo, že některá nastavení se mi prostě při otevření programu na jiném stroji ztratila. Proto jeden z hlavních cílů je, aby uživatelské nastavení bylo plně portabilní, bez výjimek.

Tak, a teď do mě!

       

Komentáře

[Helb]

Editor nehodnotím, ale ten qmake projekt je pěkný a jdu ho vykrást

[skunkOS]

Co konkrétně, smím se zeptat?

[Marián Kyral]

Mně teda zatím vždy stačil kate/kwrite na Linuxu. Windows naštěstí nemusím používat. Ale i tam mám kate nainstalován. Kdyby bylo někdy nejhůř

[skunkOS]

KDE, nechci si instalovat tuny závislostí. Maj i Flatpak, ale tam nefunguje tisk.

[Marián Kyral]

Tomu rozumím. Já KDE používám, takže závislosti mi nevadí.

[jiwopene]

Na Windows se mi osvědčil PSPad.

[Marián Kyral]

Z toho jsem kdysi přecházel. Ze začátku mi na Linuxu dost chyběl, ale časem jsem objevil zajímavé vlastnosti editoru kate (sezení) a ani na windows nemám potřebu se k pspadu vrátit. Ale stejně to je jen hypotetická možnost, windows na služebním NB nabootuju tak jednou, dvakrát ročně, nainstaluji aktualizace a zase je vypnu

[Petr Tomášek]

vim jsi už někdy zkoušel?

[chrono]

V čom je lepšia tá stará verzia Scintilly pre Qt oproti (oficiálnej) pre Gtk?

[Marián Kyral]

Funguje na Qt?

[Petr Tomášek]

On se ale neptal, v čem je horší...

[Marián Kyral]

Jo? Ono je GTK lepší než Qt? O tom silně pochybuji

[Petr Tomášek]

Cokoliv je lepší než ta sračka Qt .

A GTK+ je tedy lepší o dost .

[Marián Kyral]

Nesouhlasím. B-)

[pavlix]

Preferuju GTK z různých důvodů včetně toho, že nemám rád C++. Ale technicky vzato nelze souhlasit.

[skunkOS]

Sorry ale jaká starší verzi pro Qt? Scintilla má v repu normální oficiální Qt binding. Není to žádná "starší" verze.

[pirated_byte]

Od te doby, co geany presel z GTK2 na GTK3, reaguje opozdene a renderuje tak 5x pomaleji. Ve skutecnosti jsem tohle zaznamenal s prakticky vsemi aplikacemi co presly na GTK3, nejdrasticteji si to pamatuju pred par lety u Synapticu.

[pavlix]

Když vidím, jak GTK/Glib lidi programují a na čem stavějí základní datové struktury, tak se mi dělá špatně nezávisle na verzi.

[kutr]

Pěkný, jenom mi přijde škoda, že tak nový projekt je psaný v C++03. Jak je na tom vůbec QT s podporou pro C++11/14/17? Zběžné nahlédnutí do dokumentace mi přijde, že s tím asi počítají (např. QString má implementovaný move).

[skunkOS]

Jaké featury z C++ 03 byste rád odstranil a čím z C++ 14 je nahradil? V qmake projectu mám C++ 14 povoleno, Qt to umí.

[kutr]

Nemyslím odstraňovat feature, spíš že v kódu nejsou použité nové možnosti.

• definice konstant přes makra místo constexpr (definitions.h)
• QString předávaný vždy jako const reference, přitom by často bylo efektivnější hodnotou a využít std::move (namátkou prakticky všude v Downloader)
• nepoužívání unique_ptr místo new/delete (ShortcutCatcher)
• prázdné construktory/destruktory mi přijde přehlednější deklarovat = default místo prázdného těla funkce
• místo deklarace private constructoru napsat = delete pro zákaz instanciace třídy (GuiUtilities)

Jsou to spíš drobnosti, ale asi tím, jak dlouho dělám s novými standardy, tak to úplně bije do očí.

[skunkOS]

Zkusím to zabudovat.

[kutr]

Jestli to dobře chápu a nemáš zkušenosti s moderním C++ tak doporučuju přečíst Effective Modern C++ od Scotta Meyerse. Spoustu věcí můžeš klidně odložit (hlavně šablony pokud nechceš psát knihovny nebo generický kód), ale hodně to pomůže pochopit nové věci a jak je správně použít. Protože třeba ten std:move se dá použít i blbě a pak výkonnost ještě zhorší (tady často pomůžou warningy překladače). Myslim, že na učení nových věcí je takovýhle projekt úplně ideální.

[skunkOS]

Jj, právě to čtu, dík.

Něco už jsem zabudoval (default/delete u konstruktorů, constexpr u compile-time konstant.

[xkucf03]

Kde se tyhle věci učíš? Nějaké weby, knížky…? Já mám Mistrovství v C++, ale to je deset let stará kniha, a pak různé náhodné zdroje, co najdu na internetu, když řeším něco konkrétního. Ale hodil by se mi nějaký ucelený výklad moderního C++.

[Josef Kufner]

Prostě si vemeš specifikaci C++ a než to dočteš, vyjde další díl.

[xkucf03]

Toho jsem se obával

[Ivorne]

Já prostě čtu std api reference na http://www.cplusplus.com/ a http://en.cppreference.com/. Většinu věcí co vím o novým c++ jsem se naučil tam.

[Ivorne]

Jo a abych věděl, co tam mám vůbec hledat, tak používám wikipedii jako osnovu: https://cs.wikipedia.org/wiki/C++11, https://en.wikipedia.org/wiki/C++14, https://en.wikipedia.org/wiki/C++17 a https://en.wikipedia.org/wiki/C++20.

[kralyk z abclinuxu]

+1, cppreference.com je dobrý zdroj.

Co se týče nových verzí C++, mám z toho smíšené pocity. Jsou to užitečné featury (třeba move semantics - super), ale je to na ten jazyk dost doděláno, nesedí to úplně. Move semantics mi přijdou nemístně výřečný (všade std::move , etc). Navíc už tak vysoká komplexita jazyka tím ještě roste... Třeba value categories už mi přijdou dost šílený.

[Ivorne]

Já jsem z nového C++ dost nadšený. Je fakt, že zrovna věci kolem rvalue referencí jsou fakt trochu překomplikovaný. Je trochu zvláštní, kolik pravidel se tam vymyslelo jen za tím účelem, aby šlo dělat move semantics a perfect forwarding. Protože ač jsou ty rvalue reference definovaný relativně obecně, tak se to stejně k ničemu jinýmu použít nedá. Ale jsem rád, že to v tom jazyce je, protože to je fakt hodně užitečný.

Ostatní věci v novým C++ jsou ale mnohem čistší. Třeba lambda funkce jsou dobrý, i když člověk musí rozumnět, jak fungují, aby si mohl být jistý, že je používá korektně. Jsem si jistý, že Linus je považuje za nejhorší featuru C++, kvůli tomu, kolik kopírování sem tam se v nich schovává . Potom type_traits a všechny ostatní věci k generickýmu programování jsou skvělý. SFINAE je trochu retardovaný, ale to je spíš takový užitečný side effect něčeho, co v C++ už bylo, takže za to se nedá na nikoho zlobit.

Jsem taky rád, že neschválili do c++17 standardu ty koncepty. Sice se dost těším na koncepty, ale je jasný, že ten návrh chce dotáhnout, aby s sebou netáhnul tolik neintuitivních sémantických pravidel. Věřím tomu, že až se ty koncepty někdy do c++ dostanou, tak to bude skvělá věc, která zpřehlední spoustu templatovaného kódu. A mohlo by to taky nahradit SFINAE (možná ne, ale uvidí se).

[pavlix]

Já bych z C++ blil a zrovna tak z PHP a přijde mi škoda se ty jazyky snažit udržovat při životě a vylepšovat. To jenom, ať tu máme trochu vyvážené emoce v diskuzi.

[xsubway]

... a který programovací jazyk bys doporučil?

[Bedňa]

Dnes za najlepšiu alternatívu pokladám Rust, C++ odjakživa topilo v ..., je pravda, že sa to zlepšilo, ale proste mi ten návrh stále pripadá divný.

Alebo si napíš vlastný :)

[xsubway]

Hlavně ne vlastní :) ... je pravda, že mě Rust zaujal, třeba s řešením mutability, atd.

[Bedňa]

V Ruste sa proste intuitívne píše pekný kód, v C++ sa proste viac menej prasí. Keď sa na kód pozrieš, tak ťa to musí potešiť a nie zhnusiť :)

[kutr]

Ono je to spíš kvalitou programátorů. Pokud se stane z Rustu mainstream, věřím tomu, že se najde spousta lidí, kteří budou ty pravidla kreativně obcházet např. s pomocí unsafe s argumentem, že to přece funguje nebo i něco lepší co si teď nedokážu ani předstait. Ale souhlasím s tím, že C++ rozhodně s psaním slušného kódu nepomáhá, spíš škodí. Třeba jenom vyznat se ve všech undefined konstrukcích je na dlouhé zimní večery. Pokud ale víš co děláš a můžeš založit projekt bez ohledu na historický kód, tak se v tom dá psát celkem slušně (otázka je, jestli by si někdo dobrovolně pro vybral C++ pro nový kód).

[pavlix]

Tak daleko, abych doporučoval konkrétní jazyky, asi nepůjdeme...

[xsubway]

Ok .-)

[kralyk z abclinuxu]

Ale jsem rád, že to v tom jazyce je, protože to je fakt hodně užitečný.

S tim naprosto souhlasim, jen úplně nejsem nadšnej z toho, jakým způsobem se to do toho jazyka integruje. Ty složitosti ohledně rvalue referencí jsou v zásadě skoro celé způsobené zpětnou kompatibilitou. K move semantics v C++ jsem přišel až po zkušenosti z Rustu (který byl tehdy sice v plenkách, ale zrovna tohle se od té doby jen málo změnilo) a oproti tomu je to v C++ hrozně nepohodlné, navíc C++ v podstatě jako takové ani move semantics nepodporuje, pouze máš k dispozici to primitivum rvalue references, nad kterým to můžeš naimplementovat, pokud to uděláš spránvě a nenaběhneš si přitom na nějaký hrábě, kterých C++ má dost.

Je sice hezký, že přidávají užitečný featury - třeba koncepty se mi samy o sobě taky líbí - ale s dřívějšími, dnes už spíše historickými vlastnostmi jazyka to moc nejde dokupy a má to tendenci vytvářet šílenou komplexitu a přidávat další ležící hrábě.

Pokud by se měly přidat koncepty, moduly a další "velký" fíčury, už by to IMHO bylo na zvážení, jestli neporušit zpětnou kompatibilitu, alespoň třeba v nějakým omezeným režimu (třeba na úrovni souborů nebo nějakých bloků nebo tak něco), jinak z toho bude naprosto šílenej guláš.

[t]

Effective Modern C++. Kniha obsahuje asi 30 kapitol, kde každá rozebírá nějakou konstrukci z nového C++ (např. constexpr) a vysvětluje kdy a proč použít, které případy to řeší.

[Martin Tůma]

Opravdu jsou tyhle kosmetický záležitosti natolik cool, že se kvůli nim vyplatí obětovat kompatabilitu s mnoha současnými systémy/distribucemi?!

[:::]

Tak odstraneni maker urcite a move semantika taky

[kralyk z abclinuxu]

Mně připadá nejdůležitější to používání smart pointerů místo ručního new a delete. Oproti tomu jsou ty ostatní věci opravdu spíš kosmetika.

Jinak zajímalo by mě, které systémy/distribuce má kolega na mysli. Nejsem si 100% jistej, ale AFAIK třeba gcc na Debianu Wheezy ty výše zmíněný fíčury podporuje. Je ještě nějaké konzervativnější distro?

[Martin Tůma]

Zrovna ty zmiňovaný fíčury jsou IMHO všechny c++11, takže tam už to dneska (kromě RHEL6) prakticky není problém, nicméně v původním příspěvku se hovořilo o c++14 a to už nepřeložíte ve spoustě distribucí, např. v aktuálním RHEL7.

[xkucf03]

BTW: jak je to s mapami a chytrými ukazateli? Je potřeba mít v mapě jako typ hodnoty shared_ptr, když chci, aby se to pak „samo uklidilo“, nebo to jde nějak elegantněji?

[KS]

Obecně je nejlepší se shared_ptr pokud možno vyhnout, protože sdílená zodpovědnost za dealokaci zdroje většinou vnáší zmatek. Je opravdu jen málo případů, kdy je shared_ptr dobrý nápad. V jiných případech je lepší najít si konkrétní část programu, která má nést za daný zdroj zodpovědnost.

[xkucf03]

Dobře. A dá se to tedy v C++ nějak udělat, aby s tím šlo pracovat aspoň tak dobře jako v Javě? Tzn. do mapy nastrkám objekty k nějakým klíčům a když pro daný klíč přepíšu hodnotu nebo záznam odstraním, tak se uklidí i ten objekt (pokud ho nikdo další nepoužívá). Totéž v případě, že už nikdo nepoužívá tu mapu – pak by měla zmizet celá včetně klíčů a hodnot.

[KS]

Ano, to se děje bez ohledu na nějaké chytré ukazatele. Mapa, alespoň ta ze std::, je zodpovědná za dealokaci objektů, které vlastní. Ať už je to int, std::string, nebo třeba std::shared_ptr.

[xkucf03]

A když tu hodnotu z mapy vytáhnu a budu zároveň používat i někde jinde, jak se pozná, kdy je možné ji uvolnit?

[pavlix]

Nevytáhneš. Uděláš kopii.

[xkucf03]

Proč bych dělal kopii, když chci tu samou instanci?

[kralyk z abclinuxu]

Protože nic jiného než kopie ve výsledku udělat nejde. Dokonce i move je v podstatě jen kopie + znevalidnění původní hodnoty.

Ono úplně stejně je to pod kapotou i v té Javě (kopírují se reference, tj, gc pointery), jen jsi od toho odstíněn. Teda většinou, narazit na to můžeš např. ve chvíli, kdy se pokusíš porovnávat instance pomocí operátoru ==.

[xkucf03]

Kopie ukazatele ať se klidně udělá, to je mi jedno. Ale jde mi o to, že mám instanci nějaké třídy. Tuto instanci může být nákladné vytvořit (načte se konfigurace, něco se vypočítá atd.) nebo má držet nějaký společný stav → takže chci mít jen jednu instanci a nechci ji kopírovat. Tuhle instanci chci dát do mapy, abych ji mohl vyhledávat podle nějakého klíče. A když už tu instanci nikdo nepotřebuje (v mapě jsem danému klíči přiřadil jinou instanci a ani jinde tuhle instanci nikdo nepoužívá), tak by se měla „sama uklidit“ (resp. někdo ji uklidí, ale nechci to hlídat ručně). Tohle se tedy dělá tak, že dám ty shared_ptr do mapy nebo to jde nějak elegantněji?

[kralyk z abclinuxu]

Tohle se tedy dělá tak, že dám ty shared_ptr do mapy nebo to jde nějak elegantněji?

Sorry, ale na to se IMHO nedá rozumně odpovědět. Možná ne, možná jo, podle toho, co to je za objekt a jakým způsobem ho chceš používat. Přijde mi, že popisuješ jakoby javovský návrh, který se snažíš namapovat na konstrukty v C++, ale to prostě nejde, protože ty jazyky nemapují 1:1.

Velký rozdíl je např. v tom, že v Javě do kontejnerů dáváš objekty (resp. reference na objekty), kdežto v C++ obecně jakýkoli hodnoty a "objekty" jsou toho jen specielní případ, navíc různě stejný nebo jiný podle toho, jakým způsobem. Atd. Opravdu se na tyhle dotazy těžko odpovídá. Přijde mi, že by bylo mnohem snažší začít s C++ víc na zelené louce a nesnažit se na něj namapovat Javu.

[pavlix]

C++ se běžně prezentuje jako alternativa Javy, takže by mělo jít udělat nějaké srovnání a stoprocenně bude i specializovaná literatura pro javisty, kde se jim vše základní vysvětlí na základě již existujících znalostí a ve srovnání s nimi.

Jeden z hlavních problémů C++ je, že ten jazyk se z různých důvodů snaží být pořád ještě trochu céčko a zároveň už céčko pokud možno nebýt. Z toho podle mě vychází většina prasoidnosti toho jazyka. Java je oproti tomu relativně čistá a jednotná a má něco jako jednotné best practices, zatímco céčko (myšleno čisté C) umožňuje využívat strukturované objekty libovolně, tedy jako objekty alokované staticky tam, kde jsou potřeba ideálně ve formě lokálních proměnných uložených na stacku, nebo jako dynamicky alokované objekty s předáváním prostého pointeru. A ta práce s nimi je zatraceně odlišná.

Různé systémy nad tím přidávají ještě různé reference based smart pointery. No a C++ se v podstatě chová jako specifický (a ne moc chytrý) objektový systém nad céčkem s upravenou a rozšířenou syntaxí. To samozřejmě řeší spoustu věcí jako je konstrukce objektů, kdy člověk nemusí explicitně volat různé inicializační funkce a podobné ptákoviny, ale stačí se podívat na režimy předávání argumentů (value, reference, pointer) a člověk vidí, že je něco trochu špatně.

[kralyk z abclinuxu]

ale stačí se podívat na režimy předávání argumentů (value, reference, pointer) a člověk vidí, že je něco trochu špatně

Až do téhle věty jsem souhlasil, tohle ale moc nechápu. Předání hodnotou vs pointerem máš v C úplně stejně. Navíc je v C++ oproti C jen ta reference, která IMHO v C++ celkem dává smysl, jako takový "bezpečnější" (a optimalizovatelnější) pointer (ona ta reference nejde tak daleko jako třeba v Rustu, kde je skutečně bezpečná, no nicméně to není zaměření C++). Koneckonců, ono i v tom C je vidět potřeba pro něco takového - viz přidání restrict .

[Ivorne]

Tak já to teda řeknu, jak to s těmi pointery je :D. V c++ se dá udělat to samé jako v javě tak, že všude použiješ shared pointery. Do hahtabulek a vektorů se dají shared pointery a všechen další kód, který by tu instanci mohl také používat si bude držet shared pointery na tu věc. A až dojde ke zničení všech shared pointerů, objekt se automaticky smaže. To proč se každý zdráhá tohle říc a proč se to v C++ dělá celkem nešikovně je protože je špatný nápad to dělat. Je prostě špatný nápad mít v c++ sdílené vlastnění objektů. Je lepší vždycky mít nějakou specializovanou autoritu, která bude určovat, jak dlouho ten objek má existovat. A dělat sdílené vlastnění objektů je hloupost i v Javě. V Javě se to akorát dělá snadno, tak je to příhodné řešení v situacích, kdy to zas tak nevadí.

Java se rozhodla, že se v ní bude snadno dělat sdílené vlastnění objektů. Ale zase se v ní špatně dělá předvídatelné RAII. C++ se rozhodlo, že se v něm bude snadno používat RAII místo init/destroy funkcí a že se v něm bude těžko dělat sdílené vlastnění objektů. A skončilo to tak, že se v Javě doporučuje dělat jedno a v C++ se doporučuje dělat to druhé.

[kralyk z abclinuxu]

V C++ se dá udělat to samé jako v javě tak, že všude použiješ shared pointery.

Tady nemůžu tak úplně souhlasit, protože GC v Javě řeší cykly, zatímco shared pointery ti klidně leaknou cyklus, což může způsobit nejen memory leaky, ale v horším případě třeba neuzavření dalších zdrojů, transakcé a kýho čerta... To je mj. další důvod, proč není dobrý nápad je používat víc, než je nutné.

[xkucf03]

Teda většinou, narazit na to můžeš např. ve chvíli, kdy se pokusíš porovnávat instance pomocí operátoru ==.

V Javě? Můžeš uvést příklad? Když dám do mapy nějaký objekt a pak si ho pod daným klíčem vyzvednu, tak se budou rovnat, bude to ta samá instance, ne kopie. Nebo myslíš něco jiného?

[pavlix]

Proč bych dělal kopii, když chci tu samou instanci?

Protože nemáš navýběr. Bavíme se o kontextu, kdy máš fyzicky v paměti pole objektů. Nemůžeš si jen tak vzít ten kus paměti, když je součástí toho pole.

[pavlix]

Pokud chceš pracovat jako v Javě, musíš použít smart pointery, které zhruba odpovídají javovské implementaci referencí. Naopak pokud používáš pole fyzicky uložených objektů, vcelku logicky je nemůžeš bez kopírování nebo referencování předávat jinam. Java je oproti C++ daleko jednodušší jazyk a běžně se v ní tyhle nástroje vůbec nepoužívají ani nejsou při její úrovni abstrakce k dispozici.

[kralyk z abclinuxu]

BTW: jak je to s mapami a chytrými ukazateli? Je potřeba mít v mapě jako typ hodnoty shared_ptr, když chci, aby se to pak „samo uklidilo“, nebo to jde nějak elegantněji?

To záleží, co myslíš tím "samo uklidilo". Hashmapy stejně jako další kolekce ze standardní knihovny samozřejmě "uklízejí" po sobě v tom smyslu, že při smazání prvku z kolekce volají destruktor toho prvku. Jestliže ti to stačí, pak smart pointer nepotřebuješ, stejně jako nepotřebuješ smart pointer, pokud do té mapy dáváš POD typy.

Pokud bys chtěl do mapy uložit pointer na objekt a zároveň k němu přistupovat nezávisle ještě někde jinde (tj. sdílené vlastnictví), budeš nejspíše potřebovat shared_ptr nebo něco podobného, ale doporučoval bych spíš se zamyslet nad návrhem a zkusit to třeba udělat jinak. Vzhledem k tomu, že v C++ musíš řešit vlastnictví a druh přístupu, Javovský návrh ti moc nepomůže, spíše naopak.

[xkucf03]

Dejme tomu, že v té mapě chci držet nějaké moduly nebo procesory jako hodnoty a klíčem bude kód příkazu/operace nebo nějaký typ úlohy. Pak mám někde frontu přicházejících požadavků, vždycky se podívám na jeho typ a podle něj to pošlu do správného procesoru z mapy (celé to bude schované v nějaké metodě). To se může dít i ve víc vláknech… Konfigurace procesorů se může v čase měnit a ty staré již nepotřebné by se měly uklidit. Ale pokud procesor ještě pracuje, musí doběhnout, nikdo by ho neměl smazat. Těmi vlákny se to ještě komplikuje o synchronizaci, ale i bez těch vláken je snad jasné, co mám na mysli. Je mi jasné, že to nikdy nebude jako GC, ale chtěl bych něco, co se tomu komfortem a bezpečností alespoň blíží případně poradit nějaký jiný návrh, který bude lepší. Dávat shared_ptr do mapy jsem zkoušel, ale vypadalo to fakt hnusně – snad existuje nějaká lepší cesta, jak s tím pracovat.

[kralyk z abclinuxu]

První, co mě napadá, když to čtu, je, že se zřejmě chystáš mít 'globální' hashmapu a v ní mutovat objekty, navíc mezi vlákny. To je trochu red flag. Skutečně to potřebuješ? Nemůžeš mít v té mapě třeba nějaké factory funkce nebo objekty a z nich ty 'procesory' vytvářet? Ie., ekvivalentně, skutečně potřebuješ, aby mezi voláními ty 'procesory' udržovaly stav a musí skutečně ten stav být v té globální mapě?

Tohle je ta věc, nad kterou by ses měl zamyslet primárně. Pokud by ti stačil immutabilní přístup do té mapy, odpadla by ti spousta problémů: nejspíš bys nepotřeboval ten shared_ptr, nemusel bys tu mapu zamykat, ... Tyhle otázky, jako co kdo vlastní a jaký má kdo kam přístup, se v Javě řeší až ex post nebo vůbec. Tady to ale musíš řešit dopředu nebo nejpozději během tvorby programu.

Pravidla palce: Používej primárně const přístup a mutabilní přístup až když si jsi jistý, že to je správně. Tj. proměnné jsou const by default, ditto member funkce (const na konci deklarace). Věci do funkcí předávej primárně const referencí nebo movem, u menších POD/POD-like typů hodnotou. Jinými až způsoby, hlavně mutabilní referncí, opět jen až když víš jistě, že to je správně a nejde to jinak. Používej primárně přímé vlastnistcí bez heap alokace, pak unique_ptr, pak teprve až něco dalšího (třeba shared_ptr).

Sdílené vlastnictví a sdílený mutabilní přístup by měly být až poslední instance, kór když je to ještě navíc mezi vlákny.

[xkucf03]

Teď zrovna řeším něco hodně primitivního*, kde ani vlákna nejsou, ale snažil jsem se nad tím přemýšlet, jak by to vypadalo v o trošku složitější aplikaci. Máme nějaký vstup, proud zpráv potažmo volání metod. Ty zprávy můžou přicházet i z víc vláken. Zprávy je potřeba nějak roztřídit a poslat „procesorům“ Procesor se zprávou něco provede, někam odešle výsledek… To směrování zpráv může být mnohem složitější, ale prozatím uvažujme, že se budou třídit jen podle typu – textového klíče. Tudíž mi přišlo celkem přirozené použít mapu. Těch procesorů by mohlo být od každého typu víc a mohli bychom balancovat s tím, že vytvoření procesoru na jedné straně spotřebovává nějaký výpočetní výkon a procesor následně zabírá víc paměti a na druhé straně víc procesorů může lépe pracovat paralelně… tohle by se dalo nějak dynamicky konfigurovat a měnit za chodu – ale opět to nechci zesložiťovat, takže pro jednoduchost jsem chtěl zatím jen jeden procesor od každého typu.

*) Má to být interpret příkazů, které budou řídit RGB LED diody. Nakonec to poběží na nějakém jednočipu, ale nejdřív jsem si to chtěl vyzkoušet na „stolním“ C/C++ a udělat si tam prototyp, kde si ujasním formát, příkazy atd. Na vstupu bude posloupnost bajtů a výstupem je, že to různě rozsvěcí RGB LEDky. V podstatě takový jednoúčelový assembler. Je to taková blbost, ale říkal jsem si, že se na tom něco naučím. Má to fungovat tak, že tomu pošleš tu posloupnost bajtů a pak to pojede samo – tzn. v jednom programu si připravíš tu posloupnost (zatím to budu psát ručně), pošleš ji jednorázově jinému programu, ukončíš s ním „spojení“ a v tom druhém programu to pojede. Tzn. nemusíš pokaždé přeflashovat jednočip, aby jinak blikal, jen mu pošleš ty bajty, on si je uloží do RAM a bude je interpretovat. Příkazy můžou být typu: čekej X ms (jeden bajt je ID příkazu, pak jsou volitelně parametry, které můžou být různě dlouhé podle příkazu), nastav intenzitu určité barvy (parametr) na určité diodě (parametr) na hodnotu, kterou najdeš na Xté (parametr) pozici v té posloupnosti bajtů, inkrementuj/dekrementuj hodnotu na Xté pozici, nastav barvu na pevně danou hodnotu (parametrem příkazu je přímo ta hodnota, ne odkaz na její pozici), GOTO na určitou pozici, podmíněné GOTO, které porovná hodnoty na dvou pozicích nebo hodnotu proti konstantě atd. V té posloupnosti tedy nebudou jen data, ale může tam být i nějaká logika, v podstatě program.

Např. při bootu počítače to to tam pošle jednu sekvenci bajtů a od té doby to bude nějak blikat/svítit, dokud se tam nepošle jiná sekvence – bude se interpretovat pořád dokola (když na konci bude GOTO 0); když nastartuje KDE, tak se tam pošle něco jiného a bude to svítit jinak, když přijde e-mail, tak to třeba začne zuřivě blikat, když pustím videopřehrávač, tak se to ztlumí atd.

Na tom jednočipu to bude muset být zjednodušené, ale zatím si s tím hraji na počítači, kde můžu používat i věci z C++17. Původně jsem to chtěl udělat tak, že co příkaz, to položka v mapě a ukazovalo by to buď na nějakou instanci nebo na funkci. Tady by to bylo asi jedno, protože program se jednou nakonfiguruje a pak už se to nemění, ale schválně jsem si říkal, jak by to bylo u programu, který běží dlouhodobě a během svého života se mnohokrát překonfiguruje, změní se hodnoty v mapě atd. – kdo tam bude uklízet ty staré hodnoty, jak poznat, že už ty instance nejsou potřeba… Pak je taky potřeba si mezi tím nějak předávat odkaz na tu paměť, ze které se čte a případně se do ní i zapisuje.

V té paměti se mimochodem nerozlišuje mezi příkazy a daty, takže by tam šlo dělat různá kouzla/prasárny :-). Kdyby se narazilo na neexistující příkaz nebo došla data, tak by to skočilo na nějakou domluvenou pozici (obdoba odchycení výjimky), kde by se pokračovalo dál. Mohla by se třeba dělat soutěž, kdo v tom napíše nejzajímavější blikání – něco jako se kdysi dělala dema. Paměť by byla omezená hardwarem, takže třeba jen 1024 bajtů.

[ehm]

Dej na radu oryctolaguse – nedělej z toho Javu. To, co navrhuješ, by byl kontroverzní návrh i v té Javě, ale aspoň se to tam dá implementovat jednoduše. V C/C++ nikoliv.

Pokud je cílem napsat nějakou obdobu Brainfucku, tak to tak napiš – nejpřímočařejší možnou cestou. Nenaučíš se tím sice perfektně spravovat paměť v různých situacích, ale narazíš na jiné praktické problémy. Osaháš si to.

Rozumím tvému postupu tak, že se snažíš udělat si tahák, jak se které javovské konstrukce zapíší v syntaxi C++. Také mívám tendence tak uvažovat a postupovat, ale není to moc šikovné.

Takže jestli můžu radit, začal bych fakt od triviálních prográmků (a nepsal je zbytečně příliš „rozšiřitelně“ a „architektonicky správně“; časem zjistíš, že v kontextu daných jazyků ten architektonicky správný návrh může vypadat i jinak než jsi zvyklý).

A konečně, zvaž, jestli má smysl se C++ učit. Před Javou jsem jej považoval (po několik let) za svůj hlavní jazyk. Ovládl jsem jen jakýsi jeho velmi striktní subset a když jsem byl konfrontován s cizím kódem, netušil jsem, která bije – a navíc mě postupem času stále méně bavilo se ty věci učit. Dnes je pro mě C++ mrtvé; zlomky si pamatuji, ale na své opakované pokusy se k němu vrátit jsem rezignoval. Občas si něco zkouším psát v čistém C, kde nemám komfort výjimek a OOP, ale mám komfort relativně jednoduchého jazyka, kde si vcelku snadno představím, co se děje na úrovni procesoru.

Pokud nemáš nějaký specifický důvod, proč se zaměřovat právě na C++, snad bych doporučil raději D, nebo nějaký jiný moderní nízkoúrovňový jazyk. A nebo zůstat u toho C. Ono je ostatně zajímavé zkusit si napsat program třeba bez výjimek, ale přitom ošetřit všechny chybové stavy apod. Jako programátorovi v Javě ti to určitě prospěje víc (z hlediska rozšíření obzorů) než učit se přiohnout C++ tak, aby se od Javy zas tolik nelišilo. Ten opruz z toho všude muset vracet nějaké chybové kódy z funkcí apod. a pak to ještě volat z podmínek tě totiž dovede k tomu navrhovat programy tak, aby v nich pokud možno žádné chyby vznikat nemohly. A to je to rozšíření obzorů, o kterém mluvím.

BTW: +1 všem zúčastněným za zajímavou diskuzi.

[pavlix]

A konečně, zvaž, jestli má smysl se C++ učit.

K tomu se zvlášť přikláním.

[kralyk z abclinuxu]

Když jsem si psal ze srandy interpret Befunge, tak jsem prostě použil pole o velikosti 256, ve kterém byly pointery na funkce. Prostě jsi vzal bajt, indexoval jím do pole a zavolal tu funkci. Pracovalo to s globálním stackem a polem dat, bylo to extrémně jednoduché (mj. proto, že jsem chtěl, aby se zdroják vešel do 80×25). Žádný OOP design.

Switch je asi taky celkem dobrá volba. Případně co se dělá při psaní třeba nějakých jednodušších emulátorů je, že se instrukce matchují oproti nějakým bitmaskům do nějakých kategorií (třeba ALU, load/store, jumpy/branche, apod.), tím pádem se před-dekódují a konkrétní operace se řeší až v dalším kroku, tj. máš to víceúrovňové a není to celé naházené v jednom velkém switchi/tabulce/mapě. Tohle bych asi doporučoval, jestli si vytváříš DSL assembly.

Jinak řešíš tu hodně široký rozsah požadavků - od provozu na jednočipu až po desktop s GUI a e-mailem a runtime rekonfigurací interpreteru - nemyslim si, že je rozumný snažit se vytvořit návrh, který bude fungovat ve všech těhle režimech.

[Josef Kufner]

Datová struktura, která se hodí na takovou tabulku, se jmenuje trie. (Nemusí se to hodit na každý případ, ale alespoň pro inspiraci.)

[kralyk z abclinuxu]

Myslim si, že trie ti až tak nepomůže, musel bys mít stále všechny instrukce v jedný struktuře. Já měl na mysli to, že třeba na jednom místě rozlišíš nějaké základní kategorie a na základě toho každou pošleš někam úplně jinam, kde proběhne konkrétnější rozhodnutí, co s ní. Ale to se asi vyplatí jen u netriviálních instrukčních sad.

[xkucf03]

Na tom jednočipu to bude asi ten switch (pole by zbytečně zabíralo další RAM), rozhodně to nebude ten samý kód jako u prototypu. Ale na tom desktopu se nad tím snažím přemýšlet, jak by to vypadalo ve větší aplikaci, která běží delší dobu, rekonfiguruje se za chodu, nemá globální kontext (může tam být např. více e-mailových účtů a každý bude mít jiné filtry)… nicméně nemusí to být nutně objektový návrh.

[kralyk z abclinuxu]

Na tom jednočipu to bude asi ten switch (pole by zbytečně zabíralo další RAM)

Ne nutně, to pole může být konstatní, tj. společně s kódem v readonly datech. Mohlo by se i stát, že ten switch bude ve výsledku větší. Záleží samozřejmě na okolnostech, na paměťové architektuře toho jednočipu, na toolchainu atd.

Například ESP8266 umí vykonávat kód z SPI flashe bez kopie do RAM a IIRC C kód může k readonly datům ve flashi přístupovat přes adresní prostor.

[xkucf03]

P.S. Zatím to mám jako FOR cyklus a v něm SWICH, ale chtěl bych to strukturovat nějak líp a zároveň to udělat nějak dynamicky – např. kdyby ten program měl GUI, tak by sis mohl zvolit, čím se který příkaz (obecně typ zprávy) bude zpracovávat (předvolená množina procesorů). A tahle konfigurace by se za běhu programu měla někde držet (a tam mě právě napadá ta mapa jako nejjednodušší řešení). Kdyby to byl třeba e-mailový nebo IM klient, tak by to mohly být filtry zpráv – v nejjednodušším případě by šlo filtrovat jen podle odesílatele (klíč mapy?) a ten „procesor“ (hodnota mapy?) by třeba zařídil přehrání zvuku, zobrazení upozornění, přesun zprávy do určité složky, automatickou odpověď atd.

[KS]

Myslím, že obecně se tomu říká stavový automat.

[xkucf03]

Ano, ale mě by právě zajímalo, jak to v C/C++ implementovat tak, aby to nebylo zadrátované v kódu, nýbrž aby to bylo dynamické a šlo to teoreticky měnit za chodu (např. tím, že uživatel něco nakliká v GUI nebo že se načte nový konfigurační soubor z disku). A vlastně původně jsem řešil ještě mnohem primitivnější problém – jak pohodlně pracovat s mapami (obecně kolekcemi) a mít zabezpečenou správu paměti.

[kralyk z abclinuxu]

Ano, ale mě by právě zajímalo, jak to v C/C++ implementovat tak, aby to nebylo zadrátované v kódu, nýbrž aby to bylo dynamické a šlo to teoreticky měnit za chodu (např. tím, že uživatel něco nakliká v GUI nebo že se načte nový konfigurační soubor z disku).

Pokud to vyloženě nepotřebuješ, tak bych to nedělal. Možná máš pocit, že se tim víc naučíš, ale spíš si myslim, že to je tak, že by ses naučil něco jinýho / jinej aspekt. Začal bych co nejjednodušeji.

A vlastně původně jsem řešil ještě mnohem primitivnější problém – jak pohodlně pracovat s mapami (obecně kolekcemi) a mít zabezpečenou správu paměti.

Kolekce nejsou nijak specifický co se správy paměti týče. Kolekce si sama spravuje svou pamět, kterou potřebuje. Co se týče "objektů", které do ní dáš a pak smažeš, tak o ně se postará v tom smyslu, že správně zavolá destruktor, když je odstraňuje. A když se volá dtor té kolekce jako takové, tak se zbaví zbývajících prvků, tj. zavolá jejich dtory a uvolní paměť, kterou zabíraly (ale pozor, pouze ty prvky jako takové - tj. když to bude raw pointer, uvolní se pouze ten raw pointer jako takový, už ale ne to, na co ukazuje).

Pravděpodobně máš spíše problém obecně se správou paměti, resp. lifetimes, který se jen projevuje při nějaké práci s kolekcemi. Je důležitý, abys měl na paměti, že narozdíl od Javy, kde se pracuje primárně s objekty, v C++ se pracuje primárně s hodnotami a "objekt" je spíš takové vágní označení, které může mít v různých kotextech různý význam. V C++ je všechno obecná hodnota (nějaký shluk bajtů). Kolekce neobsahuje objekty jako v Javě, ale hodnoty nějakého typu. Pojmem "objekt" nejspíš myslíš nějaký pointer na nějakou heap-alokovanou instanci struktury/třídy (zejména v případě smart pointeru to je asi nejblíže té referenci v Javě). Kolekce ti mileráda pointer uskladní (jako každou jinou hodnotu) a na požádání vydá, ale interpretace toho, co ten pointer je a kdy se třeba nad ním má/nemá zavolat dealokace je na tobě a/nebo na smart pointeru (v případě, že se jedná o smart pointer), ta kolekce se o tohle vůbec nestará. Ta hodnota může reagovat na to, když ta kolekce zavolá třeba některý operátor nebo destruktor, ale to je všechno. Díky tomu můžeš mj. také instance ukládat do mapy napřímo bez pointeru, v takovém případě jsou veškerá data instance obsažena fyzicky přímo v prostoru, který si alokuje ta kolekce (tohle v Javě vůbec nejde). V tom případě pak lifetime té instance je svázán s jejím obsažením v té kolekci, ve chvíli, kdy se z kolekce odstraní, zavolá se její dtor (což ti ale stále nebrání ještě před tím tu instanci někam vykopírovat nebo použít move). Dokonce můžeš v dostatečně novém C++ ty instance takhle přímo konstruovat ("emaplacing"). Jestli dává smysl mít ty instance v kolekci napřímo nebo přes pointer, případně přes jaký druh pointeru, to je něco, co si musíš vymyslet sám tak, aby to co nejlépe sedělo na tvůj usecase (a je pravda, že to asi vyžaduje určitou znalost / zkušenost, kterou někdo, kdo přišel z Javy, asi mít nebude).

Možná by sis mohl zkusit naimplementovat svou vlastní verzi smart pointerů jako unique_ptr a shared_ptr , to by mohlo vést k lepšímu porozumění tomu, jak fungují (a že to jsou vlastně jen zase celkem jednoduchý hodnoty). Když člověk neřeší 100% korektnost, atomicitu, atd., tak to je na pár řádků (že to nebude 100% korektní ve všech corner-casech nevadí, jde jen o ten principielní základ). Určitě by nebylo špatné si vytvořit nějakou dummy třídu, která bude třeba vypisovat na výstup něco v těle ctoru, copy ctoru, assignment operatoru a dtoru, a instance takový třídy třeba pak naládovat do nějaké kolekce a sledovat, co se děje (a zkusit si to napřímo i přes nějaký pointer), to by mohlo trochu přispět k získání nějaké intuice. Pokud by se ti nechtělo psát ty smart pointery, tak v pohodě, ale tuhle logovací dummy třídu bych opravdu hodně doporučoval.

[xkucf03]

Pokud to vyloženě nepotřebuješ, tak bych to nedělal.

Teď to nepotřebuji, ale pokud bych v tom měl psát cokoli složitějšího než „hello world“ tak to potřebovat budu. Nechce se mi psát rovnou větší program a na něm se to teprve učit – přijde mi lepší (na učení) psát malý program, ale stylem, jako by byl trochu větší nebo jako by to byla součást nějakého většího programu.

Začal bych co nejjednodušeji.

Já se tu přece nesnažím reimplementovat EJB, ORM, JAXB, IoC/DI nebo nějaké návrhové vzory z Javy… ale řeším úplně základní věci. Připomíná mi to, jak se tuhle někdo divil, že mám v programu několik #include a volám nějaké, podle něj zbytečné, funkce – ale já jsem chtěl jen vypsat text na standardní výstup, což považuji za naprosto základní věc. Akorát jsem chtěl, aby se výstup nerozesral, když text bude obsahovat háčky a čárky (což v 21. století taky považuji za základní věc), a jednodušeji to prostě nešlo.

Sčítání integerů nebo předávání hodnot/ukazatelů/referencí do funkcí, to už jsem si vyzkoušel a tohle snad zvládám a vím, jak se to chová, ale to bohužel k napsání nějaké smysluplné aplikace nestačí.

Jestli dává smysl mít ty instance v kolekci napřímo nebo přes pointer, případně přes jaký druh pointeru, to je něco, co si musíš vymyslet sám tak, aby to co nejlépe sedělo na tvůj usecase

To, co jsem v tomhle případě hledal, je tedy asi ta mapa obsahující chytré ukazatele. Jen mi bylo zvláštní, že neexistuje nějaké elegantnější řešení, protože s tímhle se fakt moc dobře nepracuje. Čekal bych něco, co bude kombinovat mapu a chytrý ukazatel v jednom, ale to možná nejde.

[kralyk z abclinuxu]

Já se tu přece nesnažím reimplementovat EJB, ORM, JAXB, IoC/DI nebo nějaké návrhové vzory z Javy… ale řeším úplně základní věci.

Možná seš hustej a já tě zbytečně podceňuju, ale interpret custom assembly-like DSL, jehož příkazy/ISA je možné rekonfigurovat runtime a který má GUI a umí přijímat e-mail mi nepřipadá jako "úplně základní věc"...

To, co jsem v tomhle případě hledal, je tedy asi ta mapa obsahující chytré ukazatele. Jen mi bylo zvláštní, že neexistuje nějaké elegantnější řešení, protože s tímhle se fakt moc dobře nepracuje.

Můžeš si definovat nějaké typedefy / aliasy pro smart pointery, které potřebuješ. V jedné větší codebase, kde jsem něco dělal, měli v každé třídě typedef pojmenovaný ptr pro smart pointer na tu třídu, ie použití pak bylo FooBar::Ptr nebo taknějak.

Ale přijde mi to negativní v tom, že to může vést k nadužívání shared_ptr .

Čekal bych něco, co bude kombinovat mapu a chytrý ukazatel v jednom, ale to možná nejde.

Cože? To mi nezní úplně smysluplně. Technicky vzato by to jít mělo - jestli chceš, můžeš si tu mapu podědit na konkrétní typ nebo si vytvořit templatovaný potomek té mapy, který bude pro typ T instancovat mapu obsahující shared_ptr<T> . Nicméně tohle bych pokudmožno nedělal. Můžu se mýlit, ale stále se s těmi shared pointery v mapě nemůžu zbavit dojmu, že se snažíš naroubovat javovský návrh na C++.

BTW: Nemáte někdo zkušenost s tímhle: A garbage collector for C and C++.

Nedoporučuju. Boehm GC má špatnou pověst (AFAIK není to moc dobrý GC), navíc s ním to bude tuplem "Java v C++" a nenaučíš se, jak ty věci řešit standardním způsobem...

[deda.jabko]

Nedoporučuju. Boehm GC má špatnou pověst (AFAIK není to moc dobrý GC),

Tohle je tezka dojmologie. Nevim, jak v C++, ale v C jsem s BDWGC nejakou dobu intenzivne a pracoval a na zadne problemy, ci propad vykonu oproti beznemu alokatoru jsem nenarazil. V nekterych scenarich, kdy se GC ani nestacil spustit, byly vysledky dokonce lepsi.

navíc s ním to bude tuplem "Java v C++" a nenaučíš se, jak ty věci řešit standardním způsobem...

Otazka je, ceho chce dosahnout. Jestli se naucit C++ nebo udelat funkcni aplikaci, ktera resi nejaky konkretni problem.

[kralyk z abclinuxu]

Tohle je tezka dojmologie. Nevim, jak v C++, ale v C jsem s BDWGC nejakou dobu intenzivne a pracoval a na zadne problemy, ci propad vykonu oproti beznemu alokatoru jsem nenarazil. V nekterych scenarich, kdy se GC ani nestacil spustit, byly vysledky dokonce lepsi.

Ok, dobře. Já ten názor četl na jednom fóru, kde se na to někdo ptal.

[xkucf03]

Viz C/C++ a projekt RGB assembler.

[xkucf03]

BTW: Nemáte někdo zkušenost s tímhle: A garbage collector for C and C++.

[citanus]

https://martinfowler.com/books/dsl.html

[xkucf03]

Máš tu knížku, je tam konkrétní řešení tohoto problému? Nebo to odkazuješ jen, že se tady v diskusi náhodou taky řeší něco jako DSL?

Ve skutečnosti mi nejde o nějaké DSL nebo jazyky – může to být cokoli, filtry e-mailu, obdoba servletů nebo prostě cokoli, co se na základě nějakého klíče (nebo složitějšího mechanismu) vyhledá, předají se tomu nějaká data, ono je to zpracuje a vrátí nebo odešle jinam… a tyhle procesory dat se můžou v čase měnit, můžou vznikat, zanikat.

[deda.jabko]

Nemůžeš mít v té mapě třeba nějaké factory funkce nebo objekty a z nich ty 'procesory' vytvářet?

A nerozciloval ses nedavno, ze se v Jave na jednu vec vzdycky vytvori dve tovarny a pet singletonu?

Co navrhujes je zbytecny over-engineering (ve vetsine pricetnych programovacich jazyku). Jestli jsem to spravne pochopil, procesor je ,,volatelny objekt'', kteremu se predaji data a on neco vyplivne nebo neco udela. To jestli ma nejaky stav je podruzne a je na jeho zodpovednosti, aby si ten stav korektne udrzoval. To same se tyka pripadne synchronizace.

[kralyk z abclinuxu]

A nerozciloval ses nedavno, ze se v Jave na jednu vec vzdycky vytvori dve tovarny a pet singletonu?

Myslim si, že na opravdové Java enterprise řešení ten můj návrh fakt nemá...

Co navrhujes je zbytecny over-engineering (ve vetsine pricetnych programovacich jazyku). Jestli jsem to spravne pochopil, procesor je ,,volatelny objekt'', kteremu se predaji data a on neco vyplivne nebo neco udela.

Tak kdyby to takhle stačilo, tak to mi samozřejmě přijde lepší, nicméně tazatel vyhrožoval, že bude potřeba ty procesory rekonfigurovat a nějak je mazat a znova vyvolávat a kdovíco dále. Je mi to celkem jedno, přijde mi, že stejně nemá cenu to řešit, když nevíme pořádně zadání...

To jestli ma nejaky stav je podruzne a je na jeho zodpovednosti, aby si ten stav korektne udrzoval. To same se tyka pripadne synchronizace.

Ve chvíli, kdy se do toho dají vlákna, už mi to podružné nepřijde. IMHO je lepší, když mají vlákna každý svoje vlastní data, která si mohou u sebe mutovat, než když mutují nějaký sdílený data, kde se pak musí řešit zamykání et al. (Samozřejmě ne vždycky to je možný takhle udělat.)

tfw cely tym jede ve vimu

[pm]

Hezký den

nepovedlo se mi to zkompilovat (gentoo, qt-core-5.7.1-r3)

Chybová hláška: PasteBin

Děkuji PM

[skunkOS]

Zkuste nový [master].

[Virgin Kernel]

A o Vimu nebo Emacsu jste slyšel? Upravit by je šlo přesně podle vašich představ a nemusel by jste bastlit ten váš špatný pokus o editor.

[Bystroushaak]

Taky mě napadlo napsat něco podobného. Jenže na druhou stranu, proč ne? Autor se na tom kopec naučí.

Osobně měl taky párkrát takové nutkání a extenzivní rozhovory s jedním emacsitou mě přesvědčily, že by to byla blbost. Kdybych někdy vytvářel editor, tak je to jen taková hrubá kostra, která se scriptuje jak uživatel chce. Což v podstatě přesně je emacs, akorát je to o 40 let bugů odladěnější.

Vytvářet další omezeně-konfigurovatelný a omezeně-scriptovatelný editor imho nemá moc smysl z hlediska přínosu něčeho nového, ale proč to hned hejtovat?

[Dirka]

Tak on autor tohoto zapisku udelal - imo - nejlepsi soucasnou cteku rss. Puvodne to byl taky takovej jen jakoze pokusicek co nic neumel, pak pridal to a tamto, pak jeste vic a uz dva roky nema (opet imo) zadnou konkurenci. Samozrejme, ze ten editor nemuze ani z rychliku mit moznosti Geany, ktery Martin zminuje, ne dnes, a asi to ani nezkusim, dokud to nebude umet zaklad jako std klavesovy zkratky (coz uz nekdo nareportoval, a ja tehdy reportoval u rssguard), ale proste kdo si hraje, ten si hraje.

[Bystroushaak]

Tak on autor tohoto zapisku udelal - imo - nejlepsi soucasnou cteku rss.

Jako, nechci to hejtovat, ale když jsem to zkoušel (když vydal poslední blog o tom), tak to bylo naprosto brutálně nedotažené, při používání se mi to rozpadlo (layout), stahování RSS trvalo asi tak půl hodiny v blokujícím režinmu. Žádné filtrování, žádné scriptování, nic. Neviděl jsem jediný důvod to používat místo inoreaderu.

Samozřejmě, jako projekt je to fajn a věřím, že to někam dotáhne, ale momentálně to fakt má k nejlepší čtečce hodně daleko.

[little-drunk-jesus]

Ja myslim, ze to smysl ma. Muzes takovym zpusobem objevit nejaky novy zpusob editace a zpropagovat ho do ostatnixh editoru, jako se stalo treba mutliple cursors u sublime textu.

On Emacs je sice super, ale pro nektere vetsi zasahy do nej se proste obcas dostanes z elispu az do core veci, co jsou v C a nekdy ne uplne snadno citelnem (Emacs pouziva treba GTK, ale neni to GTK aplikace a podobne veci). Navic pouzivani Emacs znamena, ze si napises vlastni editor, jen mas jine vychozi podminky :)

[xkucf03]

A používá i systemd :o

$ ldd `which emacs` | grep systemd
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fe8351ab000)

[little-drunk-jesus]

nic neocekavaneho, socket activation pro daemon mod? Toho kodu kolem je tam relativne malo a je to za ifdefovane ;)

[xkucf03]

Jenže kvůli tomu to pak závisí na půlmegabajtové knihovně (a kódu, který je za ní):

$ du /lib/x86_64-linux-gnu/libsystemd.so.0.14.0 
524K    /lib/x86_64-linux-gnu/libsystemd.so.0.14.0

Tohle je přesně věc, která se mi na systemd nelíbí – je příliš monolitické a jeho rozhraní je IMHO špatně navržené – mělo by být modulární, aby každý mohl záviset jen na tom, co opravdu potřebuje + tam, kde to má smysl, by to měl být otevřený standard, aby totéž rozhraní mohly implementovat i jiné init systémy. Jednotlivé moduly by šlo taky samostatně verzovat, takže když budeš záviset na nějaké základní funkcionalitě, která se moc nemění, tak tě nemusí trápit, že vyšla nová verze systemd, protože to tvoje rozhraní se nemění.

[little-drunk-jesus]

Ja tak nejak naivne doufam, ze tyhle headery a funkce v nich se moc v systemd nemeni a jsou defacto standard. Budu se muset trochu vic zase na systemd podivat, jeho zdrojaky jsem videl naposledy pred hodne lety, po Lennartove talku na devconfu a to jeste nebyl jeste ani ve fedore rawhide, pokud se nepletu :) Ale na druhou stranu, dokud to jde v tom SW lehce vypnout jednym define, tak me to zas tolik netrapi :)

[xkucf03]

(Možná už to někdo udělal…) dobré by bylo mít nějakou abstrakci (např. pro socket activation), aby to bylo jednoduché stabilní rozhraní, na které by se mohly napojit aplikace. A pak by existovaly implementace/přemostění na různé init systémy – zpočátku klidně jen na ten systemd, ale důležité je, že aplikace by závisela na otevřeném obecném rozhraní jehož implementaci by mohl dodat kdokoli (libovolný init systém nebo třeba nějaký testovací framework).

Ale na druhou stranu, dokud to jde v tom SW lehce vypnout jednym define, tak me to zas tolik netrapi :)

Aspoň, že tak.

[Bystroushaak]

On Emacs je sice super, ale pro nektere vetsi zasahy do nej se proste obcas dostanes z elispu az do core veci, co jsou v C a nekdy ne uplne snadno citelnem (Emacs pouziva treba GTK, ale neni to GTK aplikace a podobne veci).

To je sice pravda, ale vůči editoru, kde nemůžeš mimo C++ udělat nic je to pořád silný pokrok.

[little-drunk-jesus]

Imho je to relativne jedno, nekdo radeji c++, nekdo lisp, jinej chce vse rustu a go. Vicemene podobne funguje Xmonad, kde je to fajn, veci od suckless se take upravuji v cecku a lide s tim nejak ziji.

Imho jedine dulezite je, jak slozite je udrzovat svoje patche mimo upstream - a tady to neni o jazyku ale o stabilite API - kdyby emacs v kazde verzi zmenil elispova primitiva (mrk mrk atom a JS api), tak mas vetsi problem nez aplikovani vlastnich patches na C++ projekt, ktery je uvnitr stabilni :)

Snad se mi podarilo predat myslenku, musim na psanem projevu pracovat :)

[xkucf03]

Hlavně to, že je jazyk kompilovaný, není překážkou pro rozšiřitelnost (třetí stranou, formou modulů/pluginů).

trochu je

ta uzasna vec na emacsu (a dnes i dalsich editorech/prostredich, hlavne v javascriptu) je, ze se interaktivne modifikuje primo prostredi... jeste lip je to videt na tech ruznych smalltalkovinach

vlastne i *nix shell je neco podobneho, jen na malicko jine urovni

[xkucf03]

Dynamická knihovna se přece dá načíst i za chodu programu, ne?

ze se interaktivne modifikuje primo prostredi...

Tam ale narážíš na problém: kde je hranice mezi rozhraním (které by mělo být stabilní, dokumentované, dlouhodobě podporované…) a interními záležitostmi programu/jádra (ty si jeho autor může měnit a refaktorovat, jak se mu zachce). Když se začneš hrabat ve vnitřnostech programu (dynamický jazyk to přece podporuje) a začneš na nich záviset, tak se ti tvůj plugin/skript může kdykoli bez varování rozsypat. To není zrovna dobrá vlastnost u nástroje, který používáš k práci (a vlastně by mi to vadilo i u hry nebo třeba přehrávače filmů).

to neni problem, ale vlastnost, tim spis s funkcionalnim programovanim

samozrejme musis prvni opustit jeskyni zkostnatelych systemu v jave a zhlednout neco jineho nez holou zed

[pavlix]

To je nesmysl. Stabilita API dokáže hodně pomoct stran kvality software. Na druhou stranu Java není zrovna příklad systému okolo stability API/ABI postaveného, což už jsem tu jednou řešil.

[Virgin Kernel]

Je to překážkou, a dokonce velmi značnou.

[Virgin Kernel]

Udržovat balíčky jako patche C/C++ je ten nejhorší nápad vůbec. Všechny prostředí které se rozhodly jít touto cesto buď umřeli na nezájem a nedostatek balíčků, a nebo bojují s uživatelskou základnou desítek jedinců (obvykle autorů a jejich nejbližších).

[Virgin Kernel]

Pokud Váš balíček potřebuje udělat zásah do Cčka v Emacsu, něco děláte strašně špatně. Většina Emacsu je napsaná v Elispu který můžete samotřejmě v initu kompletně předělat. V Cčku je naprosté jádro které prostě v 99.99% případů nemáte nejmenší důvod modifikovat. A pokud ano, stojí to za udělání pull requestu do masteru.

[little-drunk-jesus]

Ale my tu preci resime rozsiritelnost editoru ne jen Emacs packages. Rozsireni editoru je i podpora waylandu, integrace guile pro elisp, uprava zobrazovani bufferu, upravy elisp engine, ci proste veci jako remacs prepisujici cast cecka do rustu.

Vetsina toho se samozrejme deje v nejakych forcich a do masteru se dostava po delsi dobe nebo vubec - coz je presne to, ze si nekde udrzuje patchset a je jedno jestli je to jedne clovek nebo komunita stovek lidi. Navic tohle je zpusob vyvoje s nejvetsi tradici prave v Emacs a komunita se prelevela v historii hodne mezi forky.

[xkucf03]

Vytvářet další omezeně-konfigurovatelný a omezeně-scriptovatelný editor imho nemá moc smysl

A myslíš, že nejuniverzálnější a nejméně omezené řešení je vždy nejlepší? To můžeš dát uživateli rovnou kompilátor nebo interpret nějakého jazyka a okno, kam jde psát text – zbytek už si dodělá sám.

[Bystroushaak]

A myslíš, že nejuniverzálnější a nejméně omezené řešení je vždy nejlepší? To můžeš dát uživateli rovnou kompilátor nebo interpret nějakého jazyka a okno, kam jde psát text – zbytek už si dodělá sám.

Myslím si, že ano. Programátorský editor by ti měl poskytnout nějaký druh frameworku. Jednoduchý, jednotný a multiplatformní způsob, jak reagovat na různé eventy, ať již jsou to stisky kláves, nebo třeba označení textu. Způsob jak definovat syntaxe. Všemožné hooky. Vykreslování textu, ale i obrázků. A ten engine na pozadí by měl být rychlý a pokud možno inteligentní, aby zvládl otevřít i 10GB SQL a obarvit v něm syntaxi.

Samozřejmě, že neprogramátorský editor tak vůbec fungovat nemusí a je to ok, ale pokud mám něco používat, tak rozhodně už nikdy v životě nechci být omezován fantazií autora;

Časová investice do editoru je velká, přitom je to můj primární nástroj, který mi vydělává na živobytí každý den. Pokud se mám přeučit na něco jiného, tak chci abych to mohl upravit, když potřebuji. Editory, které to nenabízí jsou pro mě jen hračky. Tím samozřejmě nechci shazovat autora - je zcela možné, že spoustě lidí se bude editor líbit a bude jim vyhovovat.

[Virgin Kernel]

Ano, sám se divím že programátoři používají Vim/Emacs tak málo, přitom z hlediska efektivity nemají konkurenci. A efektivní Editor/IDE je pro programátora to samé jako dobrá lopata pro dělníka. Programátoři většinu svého bdělého života stráví v editoru, je šokující že do něj obvykle investují tak málo času. Respektive, často vůbec žádný.

[deda.jabko]

Divim se, ze to tu jeste nezaznelo: Proc autor programuje dalsi textovy editor a tristi tak sve sily, kdyz mnohem dulezitejsi pro Linuxovou komunitu by byl svobodny CAD?

[xkucf03]

Svobodný parametrický CAD? Ten už existuje: SOLVESPACE. Pro začátek by stačilo vylepšovat ten…

BTW: Pracuje se v tom docela dobře a je to i zábava (člověk si tu geometrii užije víc než ve škole). Narážel jsem tam na nějaké nepříjemné problémy, ale to bylo hlavně v UI – nemělo by být tak těžké to upravit. Hlavně když chceš mít víc „vrstev“ nebo vkládat modely z jiných souborů, tak se s tím špatně pracuje (v tomhle je lepší OpenSCAD – i když tam člověk píše zdroják).

[kralyk z abclinuxu]

Dík za link, to vypadá pěkně. Pro tiskárnu jsem si zatim vytvářel věci v OpenSCADu, ale tohle vypadá, že to umí líp vyádřit vztahy mezi rozměry apod. Jestli jsem to dobře pochopil, tak export do STL to umí, že?

[xkucf03]

jj, funguje to, jednu věc už jsem z toho vytiskl.

Při návrhu něčeho netriviálního jsem měl trochu problém se v tom neztratit, ale jak jsem psal, to je primárně otázka UI a jejich pojetí „vrstev“ (resp. on je to spíš proces, jehož jednotlivé kroky se na model postupně aplikují – v tomhle mi víc vyhovuje, jak řeší kompozici OpenSCAD). Jinak je to ale hodně dobré a je to přesně přístup k modelování, který bych chtěl.

[skunkOS]

Protože to nedělá pro komunitu, ale primárně pro sebe? Prostě se v tom hrabu a to mě baví.

Teď zrovna koukám na ty nový featury v c++11/14 a je tam toho celkem hodně a je to dost zajímavý.

[deda.jabko]

Tady uz si clovek ani nemuze udelat srandu z trolla/u, aby ho jini nebrali vazne...

[xkucf03]

Programátorský editor by ti měl poskytnout nějaký druh frameworku. Jednoduchý, jednotný a multiplatformní způsob, jak reagovat na různé eventy, ať již jsou to stisky kláves, nebo třeba označení textu.

Programátoři jsou sice dost specifická cílová skupina, ale v zásadě mají dost podobné potřeby resp. jde najít nějaký společný základ, na kterém se většina shodne (a ten zbytek si editor dokonfiguruje nebo rozšíří podle svého). On taky ten programátor může chtít programovat svoji aplikaci a ne se vrtat v editoru a vyvíjet si svůj vlastní (když má stejné potřeby jako spousta jiných programátorů a mohli by používat stejný editor).

Způsob jak definovat syntaxe.

Tohle editory běžně mají – a přesto to nejsou jen nějaké frameworky, nad kterými by sis musel editor teprve postavit, ale hotové programy, které můžeš hned používat.

Nicméně definovat si vlastní syntaxi jazyka není úkol pro uživatele editoru, ale pro autora jazyka – což jen v malém zlomku bude tatáž osoba – většina uživatelů si vlastní jazyk definovat nebude.

Zajímavou funkcí je ten Highlighter, o kterém píšu níže – tam nadefinuješ jen regulární výrazy a přiřadíš jim barvy a ono ti to pak zvýrazňuje text – nemusíš definovat celou gramatiku, ale jen pár věcí, co tě zajímá. Přidáš si tam třeba (TODO|FIXME):.* nebo jiné věci, které chceš mít dobře viditelné. Dobrý kompromis mezi užitečností a jednoduchostí ovládání.

A ten engine na pozadí by měl být rychlý a pokud možno inteligentní, aby zvládl otevřít i 10GB SQL a obarvit v něm syntaxi.

To je prakticky nereálné resp. řešitelné je to jen s obrovskými nároky na paměť a CPU.

Takhle velký soubor si budeš chtít spíš namapovat do paměti než že by sis ho načetl do nějaké proměnné jako běžný obsah textového souboru. To je úplně jiný případ užití. A v té namapované paměti budeš skákat na nějaké adresy. Pokud bys chtěl (správně) zvýraznit syntaxi, tak bys musel parsovat podle dané gramatiky celý soubor od začátku až do místa, které edituješ / prohlížíš. Kdybys to zvýrazňoval od prostředka (třeba jen to, co vidíš na obrazovce), tak to není zvýrazňování syntaxe, ale jen vybraných klíčových slov – to je primitivní a dá se to udělat s minimálními nároky na zdroje, ale bude to dávat chybné výskledky. Ten velký SQL soubor totiž může obsahovat dlouhou textovou hodnotu, která bude obsahovat slova jako SELECT, FROM atd. ale protože jsi ten soubor neprojel od začátku, tak nevíš, že to nejsou klíčová slova, ale text uvnitř apostrofů. U SQL ta textová hodnota většinou nemůže být moc dlouhá, takže tam se začátku výrazu možná nějak dobereš, ale třeba u takového XML omezení délky pro CDATA snad ani není.

…rozhodně už nikdy v životě nechci být omezován fantazií autora; Časová investice do editoru je velká, přitom je to můj primární nástroj, který mi vydělává na živobytí každý den. Pokud se mám přeučit na něco jiného, tak chci abych to mohl upravit, když potřebuji.

Pokud je to svobodný software (což třeba Sublime není) tak se můžeš zapojit do vývoje. Věci užitečné (nebo aspoň neškodlivé) pro většinu uživatelů se můžou dostat do jádra programu nebo základních modulů, věci specifické pro úzkou skupinu lidí můžou být ve volitelných modulech a když bude úplně nejhůř, tak si můžeš udržovat vlastní patch. Ten se ti sice může rozsypat, když autor nekompatibilně překope kód, ale úplně stejným způsobem by se ti rozsypal plugin/skript v dynamickém jazyce, který závisí na vnitřnostech programu (něco si tam šmudlá s jeho objekty, aniž by je autor programu prohlásil za veřejné API a zavázal se tím, že to bude stabilní).

[Virgin Kernel]

Bystroushaku, nebylo to myšleno jako hejt, pouze povzdech nad znovuvynalézáním kola. Jeho řešení nebudu nikdy používat, kdyby ale napsal modul do Vimu/Emacsu rozšířilo by se to. Ten jeho editor bude používat kolik lidí? Deset? Jeho funcionalitu by mohli využívat tisíce...

[xsubway]

Právě jsem narazil na projekt, o kterém jsem nevěděl: spacemacs.org

Je to nakonfigurovaný emacs s balíčky emacsu. Hned na začátku lze vybrat, jestli chci ovládat editor jako emacs nebo jako vim a pak se stáhnou balíčky pro emacs. Nic nového pod sluncem (prostě jen konfigurace v .emacs a .emacs.d), ale pro někoho kdo nechce takovou "věc" nastavovat sám, to může být i přínosné.

Nehodnotím jestli je zrovna tento projekt (spacemacs) dobrý nebo špatný. Skvělé je, že je to vůbec možné :)

[pirated_byte]

Ja jsem nedavno dospel k nazoru, ze Emacs prakticky nelze upravit tak, aby mi vyhovoval, aniz bych ho prakticky cely prepsal vcetne ceckovych zakladu, na kterych je postaveny. Je to primarne terminalovy editor a treba takova zakladni vec, jako scrollovani souborem pri zachovani pozice kursoru v textu, neni realizovatelna jinak nez hacky s ulozenim a obnovenim pozice. Elisp neni moc hezky jazyk a to rikam jako lisper.

Jak v Emacsu tak ve Vimu je scrollovani se zapnutym syntax highlightem na pomalejsim CPU znatelne opozdene. Chapu, ze vyvojari maji asi jine priority, a moc je nezajima, ze nekdo chce pracovat na ARMovem prditku napajenem solarnim panelem. Ale pripada mi to trochu smutne, vzhledem k tomu, ze i to "ARMove prditko" ma dnes z meho pohledu vykonu na rozdavani.

[petr]

takove male rejpnuti, kolik lidi na svete pouziva textovy editor se zapnutym syntax highlightem na armovom prditku napajenem solarnim panelem? Ano, vyvojari maji opravdu jine priority nez optimalizovat pro 2 specificke uzivatele.

[pirated_byte]

Nejde o nejaky specificky pripad, ale obecne o vsechna slabsi/starsi CPU, at uz je to Raspberry Pi, nebo treba 10 let stary x86 PC. Pripada mi, ze to bud vyvojari testuji jenom na svych vykonnych strojich, nebo jsem precitlively a ostatnim proste ta latence pri interakci s editorem tolik nevadi.

[KS]

Tisíce řádků dlouhý zdroják v C scrolluje ve Vimu zcela plynule i na Raspberry Pi.

[pirated_byte]

Tak jsem to ted zkousel a s Ceckovym zdrojakem opravdu neni tak pomaly, jak jsem si ho pamatoval, ale treba s Lispem je to horsi a obecne paren matching je absolutne katastrofalne pomaly.

[xkucf03]

Kdysi se to tu probíralo – někdo by chtěl žít jako počítačový poustevník částečně odstřižený od civilizace, což znamená i malý přísun elektřiny a s tím spojený nevýkonný HW.

Nicméně pokud budu editovat 10 GB soubor, tak to pravděpodobně nebudu dělat interaktivně a už vůbec při tom nebudu řešit nějaké zvýrazňování syntaxe.

[pirated_byte]

Ja ale nemluvim o 10GB souboru, me staci otevrit 1000radkovy ceckovy zdrojak.

[Virgin Kernel]

Tak si snižte kvalitu barvení syntaxe z 3 na 2 a nebo 1.

[Virgin Kernel]

Nebo si nechte celí soubor obarvit hned při otevření místo toho aby se barvil v JIT modu který je defaultní.

[kralyk z abclinuxu]

Símtě vrať se radši k emulování 40k Raspberry na 1 GPU a nepruď...

[Virgin Kernel]

Nechápu, pokus být vtipný?

[xkucf03]

Pěkné, přidal jsem do výběru.

Zatím jsem nezkoušel, ale koukal jsem do manuálu – pár otázek a tipů:

• Nikde tam nevidím „najít a nahradit“ s podporou regulárních výrazů – umí to? Jak vypadá GUI? To je dost zásadní vlastnost.
• Když označím slovo/text, označí to i ostatní jeho výskyty v dokumentu?
• Např. jEdit má plugin Highlighter – tam si nadefinuješ regulární výrazy a barvy a on pak podbarvuje výskyty v textu. Taky hodně užitečná vlastnost.
• V Netbeans můžeš kliknout na panel se souborem a dát „Select in Projects“ a v panelu s projekty (v tvém případě se souborovým systémem) to najde a označí daný soubor.
• Podpora verzovacích systémů (Mercurial, Git, Subversion…) – opět bych se inspiroval v Netbeans – zásadní vlastnost je podbarvování změněných řádků, pak se hodí procházení historie souboru a anotace/blame (ne v novém okně, ale rovnou v editoru, vlevo se zobrazí sloupec obsahující data/verze/autory). Naopak commit/pull/push a další věci jsou spíš taková třešnička na dortu – k tomu moc nepotřebuji GUI a klidně to dělám na příkazové řádce.
• Hodil by se panel s živým náhledem, kde by se (pravděpodobně přes plugin) vykreslil zpracovaný obsah souboru – TeX, XHTML, Markdown atd.

[skunkOS]

1 - hledat to umí, nahrazovat zatím ne, regexy to umí.
2 - not yet, file a bug (tuhle funkci sám pro sebe nepotřebuju, není to priorita)
3 - file a bug
4 - file a bug
5 - toto určitě nebudu nikdy přidávat pokud to nepřidá někdo jiný, snad nikdy jsem integraci verzáku s IDE nepoužil
6 - nad zobrazením markdownu velmi přemýšlím, sám bych to hodně využil, přemýšlím, jak a zda nějakou obdobu pluginového systému zařadím

[McBig]

Hoj,

jako autor mnoho "nepotřebného" software, který vznikl právě proto, že se mi prostě něco nelíbilo, nebo že mi něco chybělo ti rozhodně fandím! I kdyby nic jiného, tak se může stát, že se tvé myšlenky dostanou do konkurenčního editoru, takže to nakonec pomůže nejen tobě.

[sad]

Takže člověk se nejdříve musí naučit tuny sraček a šílené syntaxe, aby nakonec skončil v docela úhledném frameworku. To pro budoucnost C++ zřejmě není moc dobré.

[lizbee]

thanks for sharing this! great help! santa barbara laser hair removal