Co nás ph naučil 2: gsl a zproject (diskuse)

[Ondrej Santiago Zajicek]

Problém: napojit generátor na build systém je těžké.

Asi tak dva radky do makefile?

[Michal Vyskočil]

Díky, ta formulace je hodně nešťastná. Problém není dát volání gsl to Makefile.am. Problém je, když je tohle součástí all, kde už to tak jednoduché není. Upravím zápisek

[Ondrej Santiago Zajicek]

No, ani ten update me moc nepresvedcil.

mluvím tu o případu, kdy je kód generován v rámci all targetu. To sebou nese nutnost dalších závislostí, takže další řádky v configure.ac, nemožnost experimentovat s vygenerovaným kódem, .... Stejně tak není možné projekt přeložit na vašem malém armu bez věcí jako gsl a zproject.

Ze se kod generuje v ramci all targetu nevylucuje:

1) Moznost distribuovat uzivatelum baliky s predgenerovanym kodem (cimz odpadaji zavislosti a nutnost testu v configure.ac).

2) Mit navic target ktery pouze predgeneruje kod (takze je mozne ho pak pouzit pro pripraveni baliku pro uzivatele ci pro preklad na malem ARMu).

3) Nebrani vyvojarum experimentovat s vygenerovanym kodem (dokud neupdatuji puvodni zdroj, tak make nema duvod pregenerovat generovany kod).

[cxx]

Tyto nastroje co pouzivaji deklarativni pristup failujou uz pri prvnim netrivialnim pozadavku. Nesnasim cmake, ale z tech vsech build systemu mi prisel asi nejvic funkcni - Scons a zejmena GYP jsou moje nocni mura.

[kralyk z abclinuxu]

+1

[Michal Vyskočil]

Model a deklarativní zápis bude vždycky omezenější.

Ad cmake, jak v něm vynutit C99?

[cxx]

prvni odkaz 'cmake c99'

Ja jsem si napsal helper, ktery obsahuje nektere funkce co obcas potrebuju, takze treba:

  function(cxx_detect_cflags out)
    set(out_array ${${out}})

    foreach(flag ${ARGN})
      string(REGEX REPLACE "[-=:;/.]" "_" flag_signature "${flag}")
      check_cxx_compiler_flag(${flag} "__CxxFlag_${flag_signature}")
      if(${__CxxFlag_${flag_signature}})
        list(APPEND out_array "${flag}")
      endif()
    endforeach()

    set(${out} "${out_array}" PARENT_SCOPE)
  endfunction()

  function(cxx_detect_standard out)
    set(out_array)
    cxx_detect_cflags(out_array "-std=c++14" "-std=c++11" "-std=c++0x")

    # Keep only the first flag detected, which keeps the highest version supported.
    if(out_array)
      list(GET out_array 0 out_array)
    endif()

    set(out_array ${${out}} ${out_array})
    set(${out} "${out_array}" PARENT_SCOPE)
  endfunction()

Pouziti jednoduche:

  MY_CFLAGS="..."
  cxx_detect_standard(MY_CFLAGS)
  cxx_detect_cglags(MY_CFLAGS "-fno-keep-static-consts")

Nerikam, ze to je super reseni a ze by to neslo deklarativne, ale ... Muj nejvetsi problem s cmake je ten idiotsky jazyk, ktery nema ani 'return'.

[deda.jabko]

Tyto nastroje co pouzivaji deklarativni pristup failujou uz pri prvnim netrivialnim pozadavku.

Scons a zejmena GYP jsou moje nocni mura.

Trochu rozpor, ne? GYP neznam, ale se SCons, kdyz potrebujes neco netrivialniho, prejdes do normalniho proceduralniho programovani a mas po problemu. Ve srovnani s tim mi prisly make+autotools jako generator problemu.

[cxx]

To je jako bych citoval

GYP, SCons, mi prisly jako generator problemu

Scons je mrtvy

[pavlix]

Mě osobně přijde, že se cmake snaží být za každou cenu jiný, takže se mi s jeho pomocí autotools velmi špatně nahrazují, i když o nich nemám žádné iluze.

[dumblob]

Díky za zápisek. Donutil mě znovu se zamyslet nad tím, zdali historický vývoj využívání modelování v IT (čehokoliv) nemá něco do sebe (historicky je většina modelování považována za ztrátu času).

Modelování se v širokém spektru odvětví IT používá velice málo (dle mých subjektivních měřítek přepočtených na procentuální zastoupení modelování ve všech člověkoměsících všech IT pracovníků celosvětově). Zabývám se již mnoho let modelováním na úrovni nikoliv pouze tvorby modelů modelů (tedy technik a vizuální reprezentace budoucích modelů; dále budu používat pouze pojem metamodel), nýbrž zjišťování, pro které případy v IT má modelování smysl a kdy ne.

Ukazuje se, že je tato otázka extrémně složitě zodpověditelná i pro jednoduché projektíky s malým počtem člověkohodin. Dokonce je dle mých pozorování její zodpovězení výrazně složitější než např. výběr vhodného programovacího jazyka či obdobně zásadní technologie (frameworku, nástroje, prostředí, klíčového systému, DB, atd.) pro velké projekty (táhnoucí se např. desítky let).

Řešení, které ohledně metamodelů vnímám je, že metamodel nesmí být omezený pouze na podmnožinu možností, které metamodel nabízí, nýbrž musí nutně poskytovat i "únik" z metamodelu pro případy, které do metamodelu nezapadají, avšak pro daný projekt jsou minimálně tak důležité jako stávající součásti modelu (toto se navíc mění v čase). Jinými slovy, metamodel (včetně jeho implementace v podobě modelovacího jazyka/nástroje/vizuální_reprezentace/...) musí splňovat následující dvě podmínky:

1. Musí být minimálně jednosměrně neodlučitelně spojený s výslednou implementací.
   1. Tzn. buď alespoň generuje finální aplikaci, která se poté již nedebuguje, netestuje funkčními/unit a jinými "systémovými" testy (protože veškeré testování probíhalo nad modelem před generováním; samozřejmě se předpokládá plná korektnost generátoru). Přičemž tuto finální aplikaci není možné převést zpětně na model.
   2. Nebo je model ekvivalentem parametrizované implementace - je tedy obousměrně spojený s implementací a za předpokladu znalosti parametrů dané implementace je tedy možné zpětně automatizovaně sestavit stejný model z dané implementace. Čehož se využívá při úpravách, debugování apod. (všimněme si, že zde debugování a testování může probíhat jak nad modelem, tak nad finální aplikací, což je obrovská výhoda).
   Druhý bod se dle mně dostupných informací vyskytuje pouze u vysoce teoretických (často matematických) a malilinkatých (dle metriky minimální reprezentace algoritmu) projektíků (projekty typu MPS [2] se snaží o další rozšíření pro tyto malinkaté use-cases). Ve většině ostatních nasazení se tedy používá jednosměrné generování, a sice pouze malinkatých částí aplikace (např. injection v Java *beans, různé FSM, tabulky, apod.).
2. Má plně integrovanou (nikoliv "dobastlenou") podporu pro neomezené zacházení s čímkoliv, s čím se v modelu nepočítalo (často cíleně, protože od modelu chceme, aby byl vhodným zjednodušením reality). Jinými slovy, model od samého začátku má zabudovanou a plně integrovanou podporu (tedy neodlučitelnou, avšak např. volitelně zakázatelnou či alespoň detekovatelnou pro účely verifikace) pro turingovsky kompletní výpočty.

V tomto světle GSL dle mého názoru stále selhává, a proto si kladu otázku, proč bych např. měl nahradit Premake (který je maliličkatý, bez závislostí, plně multiplatformní, pseudo-deklarativní, srozumitelný, vizuálně atraktivní - tedy vysoce čitelný s minimálním množstvím textu a podporuje v článku uvedené požadavky na CI apod.) něčím jako GSL (které minimálně v druhém bodě selhává - integrace je neexistující či "dobastlená")?

Mimochodem, velice blízko této oblasti "sestavování, testování a nasazování aplikací", avšak naopak téměř plně bez použití jakéhokoliv modelu lze použít pro sestavování aplikací Ekam, který plně automatizovaně (bez počáteční uživatelské konfigurace a bez uživatelské intervence) a v reálném čase (jak přibývá programátorův/architektův kód/popis_aplikace) generuje, testuje a popř. i nasazuje danou aplikaci.

[Michal Vyskočil]

Pozor, premake je ekvivalent některých skriptů ze zproject. Gsl je obecný nástroj na generování souborů. Například zproto je projekt, který má modely pro binární kodeky a stavový diagram pro klient a server. Takové google protocol buffer pro zeromq.

Neříkám, že se tohle všechno nedá do premake dostat, ale za mě vedou gsl skripty tím, že je obvykle snadné je ručně upravit.

[kralyk z abclinuxu]

Když jsem posledně něco takového potřeboval, použil jsem python + Mako. Mako má svoje záludnosti, ale s obecným pythonem se integruje velmi snadno a zatím nevím o lepším řešení. Nepřijde mi, že GSL by bylo zlepšením, XML data a DSL skriptovací jazyk ve mě úplně nadšení nevyvolávají...

[Michal Vyskočil]

Tak já bych byl všemi za python, nebo alespoň lua, ruby, nebo perl. Ale to bych musel zproject psát bez komunity sám a zase tolik zábavný projekt to není

[kralyk z abclinuxu]

Věřím, že ph byl skvělý programátor, ale nemám úplně rád tenhle přístup, kdy někdo vydá seznam pravidel a pouček a prohlásí je za svaté. Co se týče zproject, připadá mi, že bych tím jen vyměnil problémy s cmake/autotools/whatever za problémy se zproject...

[Mirda]

problémy s cmake/autotools/whatever za problémy se zproject...

jo. Sem ze stare skoly a proto mam radu problemu s temito 'pomuckami'. Napr. predevcirem jsem chtel rozchodit na centos5 nejnovejsi podofo paket. (protoze jsem vubec necekal, ze bude na epelu existovat startsi verze jako rpm-ko). Nejdrive jsemm si musel nainstalovat cmake28 (cmake nestacil) a pak to hlasilo, ze konfigurace se nepovedla protoze ....

Takze jsem jeste zkusil centos6 a zase jine hlasky. Musim rict, ze to jsem fakt necekal, tyhle systemy musi byt preci naprosto blbovzdorne, jestlize podle navodu odsadim ty prikazy a ono to nefunguje a ani nerekne, co mam delat, tak to by bylo lepsi predat seznam tech zdojaku a clovek si to prelozi sam.

Fakt hruza.

[Ondrej Santiago Zajicek]

Co se týče zproject, připadá mi, že bych tím jen vyměnil problémy s cmake/autotools/whatever za problémy se zproject

Ja mam pocit, ze to ma tento vyvoj:

1) Programator chce programovat, ale moc nezna make.

2) Pouzije automake, zkopiruje nekde par sablon, a ve vysledku tam ma make a automake, kterym obema moc nerozumi.

3) V dalsi fazi tam prida zproject, takze ve vysledku tam bude make, automake a zprojekt, pricemz ten programator kloudne nezna ani jedno z toho.

4) Pokud by chtel pridat nejakou neobvyklou vlastnost, tak bude muset vyresit v zproject, aby to generovalo spravne predpisy pro automake, aby ten generoval spravne predpisy pro make, takze to radsi vzda.

5) V konecnem dusledky by asi udelal lip, kdyby si rovnou precetl manual ke GNU make a napsal to primo v tom.

[Michal Vyskočil]

4) Pokud by chtel pridat nejakou neobvyklou vlastnost, tak bude muset vyresit v zproject, aby to generovalo spravne predpisy pro automake, aby ten generoval spravne predpisy pro make, takze to radsi vzda.

Lepší postup je šťouchat do autotools tak dlouho, až dělají to, co potřebuji. A potom výsledek nakopírovat do zproject a nahradit konkrétní jména za $(proměnné). Pak napsat make code pro finální test skriptu a udělat pull request.

5) V konecnem dusledky by asi udelal lip, kdyby si rovnou precetl manual ke GNU make a napsal to primo v tom.

Akorát při použití zproject má člověk rovnou strukturu projektu (include/, src/, doc/), viditelnost symbolů, správně vyřešené závislosti na dalších knihovnách, podporu unit testů, podporu code coverage, callgrind a valgrind, automatické generování dokumentace, verzování ABI i API, ... a to mluvím jenom o ekvivalentu GNU make předpisu.

Jinak je podpora pro docker file, Travis testy, balíkářské informace pro Debian, RedHat, bindingy pro Javu, Python, Lua, Ruby, NodeJS a Qt/QML, build předpis pro Visual Studio a jiné.

[deda.jabko]

Ovšem generování kódu má obvykle mezi programátory špatnou pověst. Ať vygenerovaný, či ne, kód je kód a bude obsahovat chyby. Opravovat chybu v generátoru bývá těžké. Napojit generátor na build systém je složité. V praxi se tak generování používá u magických věcí jako Google Protocol Buffers, nebo msgpack.

Nad timto se musi nejeden lispar pousmat. ;-]

[kralyk z abclinuxu]

To dává smysl - nevšiml jsem si, že by kromě posměšků nad ostatnímy jazyky produkovali lispaři někdy něco jiného.

(Výjimkou jsou autoři Clojure, těm se podařil malý zázrak - vytvořit variantu lispu, která je skutečně používaná v praxi...)

[deda.jabko]

To dává smysl - nevšiml jsem si, že by kromě posměšků nad ostatnímy jazyky produkovali lispaři někdy něco jiného.

Asi jsi malo vsimavy. Kazdopadne tech 50+ let posmesku ma neco do sebe a uz zacina sklizet ovoce.

Staci se podivat, jak vypadaly mainstreamove jazyky na prelomu tisicileti, kdy for-cyklus byl pomalu nejslozitejsi konstrukt, a jak vypadaji jazyky dnes, ... ta mas samou lambdu, map, line vyhodnocovane kolekce, atd. Mozna se casem dobereme toho, ze se rozumne pouzitelna makra (generatory kodu) stanou integralni soucasti jazyka a metod vyvoje a nebude to budit takove pozdvizeni, jako kdyz nekdo z XML generuje kod v cecku.

[kralyk z abclinuxu]

No jistě, když už není lisp úspěšný, tak se aspoň řekne, že úspěchy ostatních jazyků jsou stejně jen díky lispu atd. atd.

Škoda, že nedostávám dolar vždy, když se někdo nechá osvítit moudrostí lispu, což se projevuje zejména lezením po fórech a trousením těchto osvícených mouder do diskusí o v praxi používaných jazycích...

[Odin1918]

trousením těchto osvícených mouder do diskusí

Ty snad delas neco jineho? Nedelas. Delas to same a dukazem toho jsou i prispevky v diskusi pod timto blogpostem.

[kralyk z abclinuxu]

Máš pravdu, taky to dělám. Koneckonců ábíčko je od trousení mouder, že Nicméně v téhle diskusi jsem se snažil poradit Mako. Nevidím se autorovi zápisku, že měl špatnou zkušenost s Jinja, právě proto jsem zmínil to Mako, páč se na tyhle účely snáz ohýbá než Jinja (alespoň taková byla moje zkušenost). Přijde mi to jako celkem konstruktivní, ačkoli jsem to asi mohl líp napsat / zdůvodnit.

A pak přijde lispovej osvícenec a řekne ti, že tvoje snaha generovat kód pro C je úsměvná a že lisp měl makra už v rove 1523 a tyhlety řeči :-/

[Radovan]

Informovaní četli "Revenge of nerds".

Inteligentní ho pochopili

[Michal Vyskočil]

Jak to vidím já, tak generování autotools souborů je podobně populární

[pavlix]

Mimochodem jsem zkoušel jinja2 a chová se to jako strašný bullshit. Jednak to bez nějakého speciálního whitespace modulu nezvládá správě ani opakovat řádky (for cyklus), jednak to i nakonci souboru za různých okolností buď sežere nebo nesežere konec řádku, ačkoliv je na posledním řádku jenom text, žádné šablonové prvky. To jen takový námět k diskuzi. Zkušel jsem Mako a to fungovalo od prvního pokusu bez problémů.