abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 08:00 | Zajímavý projekt

    Společnost Mycroft AI představila Mimic 3 (YouTube). Jedná se o open source neurální engine pro převod textu na řeč (TTS) běžící rovněž offline. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0. Přispět na vývoj lze také koupí chytrého reproduktoru Mycroft Mark II.

    Ladislav Hagara | Komentářů: 1
    včera 23:22 | Komunita

    Organizace Software Freedom Conservancy vyzývá všechny vývojáře svobodného a open source softwaru k opuštění GitHubu. Proprietárního GitHubu vlastněného společností Microsoft, jejíž manažeři opakovaně napadají copyleftové licence a komerční Copilot je dokonce ignoruje.

    Ladislav Hagara | Komentářů: 4
    včera 20:33 | Nová verze

    Byla vydána verze 1.62.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

    Ladislav Hagara | Komentářů: 2
    včera 20:11 | IT novinky

    OpenGL (Wikipedie) slaví 30 let. Specifikace verze 1.0 byla vydána 30. června 1992.

    Ladislav Hagara | Komentářů: 5
    včera 13:00 | IT novinky

    Rodina Raspberry Pi se rozrostla o 3 nové členy Raspberry Pi Pico W, H a WH aneb jednočipový počítač Raspberry Pi Pico s Wi-Fi, Header (piny) a Wi-Fi a Header.

    Ladislav Hagara | Komentářů: 8
    včera 12:22 | Komunita

    Byly zveřejněny prezentace a videozáznamy přednášek z česko-slovenského setkání poskytovatelů přístupu k internetu, provozovatelů telekomunikačních sítí, registrátorů domén a provozovatelů počítačových sítí a technických nadšenců CSNOG 2022 (Czech and Slovak Network Operators Group) konaného 20. a 21. června v Brně.

    Ladislav Hagara | Komentářů: 0
    včera 08:00 | Nová verze

    Společnost Collabora vydala verzi 22.05 online kancelářského balíku Collabora Online Development Edition (CODE). Přehled novinek i s náhledy v oznámení. Nová je kontrola stylu a gramatiky pomocí LanguageTool. Calc umí 16 384 sloupců. Přidána byla podpora WebP. Zdrojové kódy jsou k dispozici na GitHubu. Vydání Collabora Online s podporou je plánováno na červenec.

    Ladislav Hagara | Komentářů: 0
    29.6. 16:33 | Humor

    Slovenská ministryně investic, regionálního rozvoje a informatizace používá heslo Mirri2020. Zveřejnila video, kde je vidět heslo nalepené na notebooku (Facebook, TA3).

    Ladislav Hagara | Komentářů: 31
    29.6. 16:11 | Nová verze

    UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch (seznam podporovaných zařízení), vydala Ubuntu Touch OTA-23. Nejnovější verze je pořád založena na Ubuntu 16.04. Pracuje se na přechodu na Ubuntu 20.04.

    Ladislav Hagara | Komentářů: 0
    29.6. 14:11 | Nová verze

    Svobodný video editor Pitivi (Wikipedie) byl vydán ve verzi 2022.06 — Reel Easing. Z novinek je zdůrazněna možnost sledování objektu pomocí OpenCV a detekce rytmu pomocí librosa. Nový Pitivi by měl být na Flathubu do několika dnů.

    Ladislav Hagara | Komentářů: 0
    Na sociálních sítích nebo jiných webových diskuzích vystupuji pod
     (65%)
     (17%)
     (18%)
    Celkem 716 hlasů
     Komentářů: 29, poslední 24.5. 00:02
    Rozcestník

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

    20.12.2016 23:09 | Přečteno: 1805× | Jen tak | Výběrový blog | poslední úprava: 21.12.2016 08:26

    V předchozím zápisku jsem nastínil CLASS. Nicméně zakládání projektů v C je obtížné, protože je potřeba znát a ovládat spoustu "plumbingu" kolem. Typický C projekt tedy začně jendím souborem, nějakým ručně psaným Makefile a postupně iteruje.

    O generování kódu

    Pieter generování kódu doporučoval a používal.

    5. Learn to use code generators.
    I've spoken of GSL before. A general-purpose code generator is an essential tool for a serious programmer. There are a few options. Try them, choose one.
    Ten Habits of a Good Programmer

    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.

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

    Update: 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. Zproject na to má target code. Ten není součástí hlavního buildu, takže takto generované projekty mají jenom smysluplné závislosti pro sestavení.

    Řešení: pokud to není nezbytně nutné, nedělejte to. Člověk, který neumí změnit model a přegenerovat kód stejně není dostatečně kvalifikovaný, aby takové úpravy dělal. A kolegové programátoři budou rádi, pokud budou moci vyenerovaný kód prošpikovat print statementy pro účely ladění.

    Problém: výstup je nečitelný, nedá se upravit

    Řešení: používejte imatix/gsl. Nebo podobný nástroj.

    O GSL

    GSL je skriptovací a šablonovací jazyk, který se šablony a modelu vytvoří výstupní dokument. Celé to zní složitě. Ale v zásadě se nejedná o nic jiného, než variantu šablonovacího systému jako je Jinja2 pro Python.

    .output "deposits.c"
    // Generated by C.gsl, do not edit by hand
    #include <stdio.h>
    
    int main () {
    .for deposit
        printf ("amount=%d, rate=%d, years=%d\\n", $(amount), $(rate), $(years));
    .endfor
    }
    
    Šablona zdrojového skriptu vypadá jako kód v jazyce C společně s pár předpisy gsl.
    <?xml version="1.0"?>
    <deposits script = "C.gsl" >
        <deposit amount = "1000000" rate = "5" years = "20" />
        <deposit amount = "500000" rate = "4" years = "10" />
        <deposit amount = "2500000" rate = "6" years = "15" />
    </deposits>
    

    Vstupní model, který gsl zpracovává. Zkoušel jsem přiohnout Jinja2 na něco podobného, protože Python je přeci jenom známějším jazykem, ale gsl je ke svému účelu perfektně postaven. Asi největší výhodou celého tohoto systému je, že je rozdělen na tři navzájem nezávislé části. Skriptovací jazyk/engine gsl, model a potom samotný skript. Díky tomu se s celým systémem velmi dobře "hraje" a zkoumá, co to vlastně dělá. No a měnit šablony je obvykle triviální, protože jde o cílový text a pár značek.

    Zproject

    Problém: zakládat projekty v C je obtížné.

    Řešení: zproject

    Zproject je asi největším projektem napsaný v gsl. Jedná se (především) o generátor projektů pro jazyk C (a C++). Vytvořit nový projekt je noční můra každého vývojáře v C. Existují tři způsoby

    1. Zkopírovat nějakou autotools šílenost odvedle
    2. IDE řeší všechno
    3. Cmake, scons, whatever

    Problém je v tom, že jenom build systémem to nekončí. Člověk musí znát jak se generují sdílené knihovny, jak umět paralelní build, jak instalovat soubory, jak dělat skripty pro Travis CI, jak generovat dokumentaci, jak spouštět testy, ... A když napíše konečně všechno to Makefile.am/confiure.ac a přežije tisíce volání autoreconf

    AC_PREREQ(2.61)
    AC_INIT([zyre],[m4_esyscmd([./version.sh zyre])],[zeromq-dev@lists.zeromq.org])
    AC_CONFIG_AUX_DIR(config)
    AC_CONFIG_MACRO_DIR(config)
    AC_CONFIG_HEADERS([src/platform.h])
    AM_INIT_AUTOMAKE([subdir-objects tar-ustar foreign])
    m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
    PV_MAJOR=`echo $PACKAGE_VERSION | cut -d . -f 1`
    PV_MINOR=`echo $PACKAGE_VERSION | cut -d . -f 2`
    PV_PATCH=`echo $PACKAGE_VERSION | cut -d . -f 3`
    AC_DEFINE_UNQUOTED([PACKAGE_VERSION_MAJOR],[$PV_MAJOR],
        [ZYRE major version])
    AC_DEFINE_UNQUOTED([PACKAGE_VERSION_MINOR],[$PV_MINOR],
        [ZYRE minor version])
    AC_DEFINE_UNQUOTED([PACKAGE_VERSION_PATCH],[$PV_PATCH],
        [ZYRE patchlevel])
    AC_SUBST(PACKAGE_VERSION)
    LTVER="2:0:1"
    AC_SUBST(LTVER)
    ZYRE_ORIG_CFLAGS="${CFLAGS:-none}"
    AC_PROG_CC
    AC_PROG_CC_C99
    AM_PROG_CC_C_O
    AC_LIBTOOL_WIN32_DLL
    AC_PROG_LIBTOOL
    AC_PROG_SED
    AC_PROG_AWK
    PKG_PROG_PKG_CONFIG
    

    ... nějaká dobrá duše bude chtít překládat pod Windows, takže nebohý programátor bude zkoumat, jak to napsat v CMake. A popravdě neexistuje žádný podstatný rozdíl mezi autotools a CMake, ani jako mezi rcs a csv.

    cmake_minimum_required(VERSION 2.8)
    project(zyre)
    enable_language(C)
    enable_testing()
    set(SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
    set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
    foreach(which MAJOR MINOR PATCH)
        file(STRINGS "${SOURCE_DIR}/include/zyre.h" ZYRE_blah blah
        string(REGEX MATCH "#define ZYRE_VERSION_${which} ([0-9_]+) blah
        if (NOT ZYRE_REGEX_MATCH)
            message(FATAL_ERROR "failed to parse ZYRE_VERSION_ blah blah
        endif()
        set(ZYRE_${which}_VERSION ${CMAKE_MATCH_1})
    endforeach(which)
    set(ZYRE_VERSION ${ZYRE_MAJOR_VERSION}.${ZYRE_MINOR_VERSION}. blah
    include(CheckIncludeFile)
    CHECK_INCLUDE_FILE("linux/wireless.h" HAVE_LINUX_WIRELESS_H)
    CHECK_INCLUDE_FILE("net/if_media.h" HAVE_NET_IF_MEDIA_H)
    include(CheckFunctionExists)
    CHECK_FUNCTION_EXISTS("getifaddrs" HAVE_GETIFADDRS)
    CHECK_FUNCTION_EXISTS("freeifaddrs" HAVE_FREEIFADDRS)
    include(CheckIncludeFiles)
    check_include_files("sys/socket.h;net/if.h" HAVE_NET_IF_H)
    if (NOT HAVE_NET_IF_H)
        CHECK_INCLUDE_FILE("net/if.h" HAVE_NET_IF_H)
    endif()
    file(WRITE ${BINARY_DIR}/platform.h.in "
    #cmakedefine HAVE_LINUX_WIRELESS_H
    #cmakedefine HAVE_NET_IF_H
    #cmakedefine HAVE_NET_IF_MEDIA_H
    #cmakedefine HAVE_GETIFADDRS
    #cmakedefine HAVE_FREEIFADDRS
    ")
    configure_file(${BINARY_DIR}/platform.h.in ${BINARY_DIR}/platform.h)
    

    Zprojekt tedy přichází s řešením, modelem.

    
    

    Todo je model projektu zyre.

    <project
        name = "zyre"
        description = "an open-source framework for proximity-based P2P apps"
        script = "zproject.gsl"
        email = "zeromq-dev@lists.zeromq.org"
        url = "http://github.com/zeromq/zyre"
        repository = "http://github.com/zeromq/zyre"
        >
        <include filename = "license.xml" />
        <version major = "1" minor = "1" patch = "0" />
        <use project = "czmq" />
    
        <class name = "zyre" />
        <class name = "zyre_event" />
        <class name = "zre_msg" />
        <class name = "zyre_peer" private = "1" />
        <class name = "zyre_group" private = "1" />
        <class name = "zyre_node" private = "1" />
        <model name = "zre_msg" />
    
        <main name = "perf_local" private = "1" />
        <main name = "perf_remote" private = "1" />
        <main name = "zpinger" />
        <main name = "ztester_beacon" private = "1" />
        <main name = "ztester_gossip" private = "1" />
    
        <target name = "*" />
        <target name = "nodejs">
            <option name = "version" value = "0.0.6" />
            <option name = "repo" value = "https://github.com/hintjens/zyre-nodejs" />
        </target>
    
        <constant name = "ZRE_DISCOVERY_PORT" value = "5670">IANA-assigned UDP port for ZRE</constant>
        <constant name = "REAP_INTERVAL" value = "1000" private = "1" >Once per second</constant>
    </project>
    

    Na základě modelu zprojekt vygeneruje strukturu projektu, čili adresáře doc, include a src. V doc jsou manuálové stránky generované ze speciálních sekcí ve zdrojových souborech skriptem mkman. Adresář include obsahuje veřejné API, s tím, že projekt.h je hlavním souborem projektu. A v src jsou potom zdrojové kódy, hlavičkové soubory soukromých tríd a další soubory jako pkg-config, konfigurační soubory, anebo systemd předpisy.

    Všechen kód ze tříd putuje do sdílené knihovny, v tomto případě libzyre.so.1. Tím je libovolný zproject projekt i sdílenou knihovnou, pokud obsahuje alespoň jednu veřejnou třídu. Zprojekt vygeneruje zároveň i testovací funkce, jako zyre_test. Takže make check spustí testy všech tříd, a make memcheck je spustí pod valgrind, takže se rovnou otestují i případně problémy s pamětí.

    V základu zprojekt generuje předpisy pro autotools a CMake. Ovšem je k dispozici hromada skriptů, které umí generovat jiné zajímavé věci.

    1. Balíkářské informace (zproject_redhat.gsl) a (zproject_debian).
    2. Build systém gyp (zproject_gyp.gsl)
    3. Docker file (zproject_docker.gsl
    4. Testy pro Travis (zproject_travis.gsl

    Draft API

    Základ draft API byl položen ve SVatém^WPieterově zápisku The End of Software Versions. Hlavní myšlenkou je, že verze software je jako obvykle umělý konstrukt. Důležité je, které protokoly (standardy) daný program podporuje a v jaké verzi. Autoři prohlížečů to pochopili dávno. Takže dneska se nikdo neptá na aktuální verzi Firefox, nebo Chrome. Zajímavá otázka je jenom - podporuje aktuální verze standard foobar 4.0, nebo ne?

    Zproject implementuje contract lifecycle tak, že pomocí konceptu draft API (a méně zajímavého deprecated) umožňuje projektům libovolně rozšiřovat a přídávat nová API s tím, že ta označená jako draft, se ve výchozím stavu nepřeloží.

    Celé to potom vede k filozofii dávejte všechno do master větve, takže poslední vydání libzmq a czmq ani nepoužívají release forky, jako tomu bylo v minulosti. Viz Git Branches Considered Harmful, nebo A succesful Git branching model considered harmful

    API model

    Už jen ve stručnosti, zproject obsahuje i generátory bindingů. Díky tomu, jakje CLASS striktní, tak je možné popsat model API v XML. A později vygenerovat dopovídající binfing. Zajímavostí je nástroj mkapi.py, který z C souborů vytvoří XML model.

           

    Hodnocení: 83 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    21.12.2016 02:29 Ondrej Santiago Zajicek
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    Problém: napojit generátor na build systém je těžké.

    Asi tak dva radky do makefile?
    21.12.2016 08:22 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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
    When your hammer is C++, everything begins to look like a thumb.
    22.12.2016 03:13 Ondrej Santiago Zajicek
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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).
    21.12.2016 12:14 cxx
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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.

    21.12.2016 12:58 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    21.12.2016 13:11 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    Model a deklarativní zápis bude vždycky omezenější.

    Ad cmake, jak v něm vynutit C99?
    When your hammer is C++, everything begins to look like a thumb.
    21.12.2016 14:00 cxx
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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'.
    21.12.2016 19:00 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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.
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    21.12.2016 20:55 cxx
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    To je jako bych citoval
    GYP, SCons, mi prisly jako generator problemu
    Scons je mrtvy
    pavlix avatar 21.12.2016 22:26 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    21.12.2016 12:20 dumblob | skóre: 10 | blog: dumblog
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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.
    21.12.2016 13:10 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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.
    When your hammer is C++, everything begins to look like a thumb.
    21.12.2016 13:15 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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í...
    21.12.2016 15:35 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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í ;-)
    When your hammer is C++, everything begins to look like a thumb.
    21.12.2016 16:19 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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...
    21.12.2016 16:36 Mirda
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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.
    22.12.2016 03:28 Ondrej Santiago Zajicek
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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.
    22.12.2016 08:28 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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é.
    When your hammer is C++, everything begins to look like a thumb.
    21.12.2016 19:55 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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. ;-]
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    21.12.2016 21:54 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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...)
    22.12.2016 00:11 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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.
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    22.12.2016 08:23 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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...
    22.12.2016 23:13 Odin1918 | skóre: 6 | blog: Valhalla
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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. :-D
    22.12.2016 23:41 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    Máš pravdu, taky to dělám. Koneckonců ábíčko je od trousení mouder, že :-D 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 :-/
    25.12.2016 07:32 Radovan
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    Informovaní četli "Revenge of nerds".

    Inteligentní ho pochopili :-D
    22.12.2016 08:31 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    Jak to vidím já, tak generování autotools souborů je podobně populární ;-)
    When your hammer is C++, everything begins to look like a thumb.
    pavlix avatar 21.12.2016 22:23 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Co nás ph naučil 2: gsl a zproject
    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ů.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.