Právě dnes uběhne 121 let od narození sira Karla Raimunda Poppera.
Člověka, který měl na mě větší vliv než kdokoli jiný v mém životě a proti kterému
jsou i živí lidé jen stíny z podsvětí. A na jeho památku vyvrátíme některé nesmysly,
které se o jeho učení šíří.:)
Dole byste měli vidět screenshot příspěvku, který jsem chtěl použít jako zadání „napište, v čem text Popera dezintepretuje“.
Už jsem tady kdysi popisoval dezinterpretace principu „intolerence vůči intoleratním“.
A tady máme další nádherný příklad zaštiťování se autoritou, i když autor komentáře
Popperovo dílo nezná, nebo se s ním seznámil v příručce typu „jak věrohodně předstírat
na večírku znalosti o evropské filosofii“. Nebudu vás ale trápit a tvrzení nekompatibilní
s Popperovým učením odhalím sám.
(Zase jde o typ článku, který se před mnoha lety objevoval i na tomto blogu. Jestli
vás tato témata zajímala, pokračuje prosím ve čtení
článku.)
V memories na FB se mi objevil příspěvek, který potěší některé mé přátele, kteří si mysleli, že historka, kterou doprovázím striktní doporučení, proč musí všechny testy po sobě důkladně uklízet, je jen vymyšlená didaktická pomůcka a nikdy se v reálu nestala.
1) To si tak vyvinete virtuální GPS. GPS, která simuluje reálnou GPS, ale posílá pozici vypočtenou z pozice BTS stanic mobilních operátorů. Já vím, že dnes máte všichni lokalizaci mobilního telefonu přes BTS operátorů v Androidu i v iOS, ale nebývalo tomu tak. Určitě ne na Windows Mobile/CE.
2) Tuto virtuální GPS potřebujete otestovat. Testy by měly odpovědět na zásadní otázky typu "Ukradl jsem a dekódoval data z Googlu správně?" "Když BTS s pozicí v mé databázi není, načte se z Googlu, pokud ten ji už stačil ukrást jiným uživatelům, a zobrazí navigační program správně polohu"? Protože vaše žena je samodruhá a prochází se často na čerstvém vzduchu, instruujete ji, kudy se má procházet, aby nasbírala všechna potřebná data a negenerovala moc "false positives" testů.
Všechno dobré, domácí idyla trvá.
3) Asi po týdnu, kdy všechny mé testy úspěšně doběhly, jela Petra nakoupit do Prahy. Měla na svém telefonu zapnutou navigaci TomTom. Až do Prahy cesta probíhala normálně, jen bylo Petře divné, že někdy TT ukazoval, že jede mimo silnici.
4) To jsme se dověděl při telefonátu (asi) z Chodova, kdy mi zoufalá Petra říkala, že na Chodově se navigace zbláznila a ona neví, kde teď je. Prý pozice v TomTomu neustále lítá z jedné silnice na druhou, TT stále počítá trasu a dostal se do smyčky, kdy jediná instrukce, kterou pan Miloslav vydává, zní "až to bude možné, otočte se".
Chvíli jsem přemýšlel nad příčinou a došlo mi, že TT je stále připojen k virtuální GPS s aproximovanou polohou. A ve městě se nedivím, že neustále přepočítává jednu trasu za druhou.
5) Pointa je, že po dokončení všech testů musíte po sobě důkladně uklízet. Protože po telefonu instruovat uživatele, aby v registrech odstranil záznamy virtuální GPS a zadal původní hodnoty, je trest pro něj i pro vás a takovou situaci si zapamatujete, i kdybyste nechtěli. Petra sice předčasně neporodila, ale nebylo k tomu při ťukání stylusem na neznámém místě, kdy výsledek celé operace byl nejistý, a při vědomí, že její vestavěné biologické navigační schopnosti jsou horší a chaotičtější než navigace TT s virtuální GPS, daleko.
Automatizované unit/integrační/ akceptační testy, které běží v nějakém cloudu, sice nejsou tak nepříjemné, když zhavarují kvůli datům, které zanechal test nějakého vývojářského prasete před vámi, ale zkoumat, proč spadnul nějaký test, abyste zjistili, že jen proto, že někdo zapomněl odmazat nějaké soubory, klíče, nebo třeba certifikáty, není také žádná zábava. Nemůžete-li zlikvidovat celou instanci testovacího virtuálního stroje, ukliďte po sobě alespoň ručně veškerý bordel. Jinak má člověk, který přijde testovat po vás, chuť zlikvidovat úplně jinou nevirtuální hmotu a objednat si k tomu fyzické služby v nějaké agentuře ve zcela reálném světě.
Je tu tradiční přehled knih, které mě v roce 2022 nejvíce zaujaly.
Opět připomínám, že v seznamu jsou knihy, které jsem přečetl v roce 2022, ale vydány mohly být v kterémkoli jiném roce.
Poslední tři roky ještě vyhlašuji "kniha - zklamání roku". Nejde tedy o absolutně
nejhorší knihu, kterou jsem tento rok přečetl, ale o knihu, u které byl největší rozpor
mezi tím, co jsem od knihy čekal a co jsem nakonec dostal.
Odkaz
na celý článek.
Pythonista, který čte knihy pro začátečníky a dokáže poznat, která je dobrá. Najde
se tu někdo takový? Asi ne, ale přesto se zkusím zeptat.
Pro synka Míšu (13 let) bych chtěl doporučit nějakou pěknou knihu o Pythonu. Asi raději
v češtině, čímž se výběr dost zužuje.
Kniha by měla nenásilně vysvětlit.
1) Základy programování v Pythonu.
2) Základní datové struktury a kdy je použít.
A jniha by měla fungovat jako základní referenční příručka, která je vždy po ruce.
I Míša ví, že na webu je dost tutorialů, ale nějaká kniha s výkladem, kde zazní "proč",
a ne jen "jak", by pro něj mohla být přínosná.
Míša se naučil v Pythonu "nějak" programovat a s pomocí knihovny PyGame napsal pár
her. Létající objekty, raketky, autíčka.
Programuje dost živelně a rychle, což není na škodu, ale přišla doba, kdy:
1) Bylo by dobré, aby viděl i někde jinde, že není nejlepší pokaždé celý kód narvat
do jedné funkce. Výkřik "Tak jsem něco napsal. Pojď se, taťko, podívat, jak jsem to
zase naprasil." sice výborně utužuje naše vzájemné vztahy, ale z posledního proifovaného
kódu mě už přece jen bolely oči. Příklady v knize by ale neměly působit uměle - refaktorizace
už tak malé funkce do ještě menších funkcí jen kvůli tomu, že to tak autorovi přijde
správné a nepoučený čtenář snese hodně.
2) Nějaký základní výklad datových struktur. Posledně Míša vytvořil piškvorky na ploše
3x3, ale jak jsem později zjistil, plocha 3x3 byla v malování vytvořený statický obrázek
:), na který potom vykresloval kolečka/křížky, příznak, jaký čtverec je aktivní atd.
Když jsem po něm chtěl, aby vykresloval "nekonečnou" plochu, nebo alespoň čtvercovou
plochu o velikosti zadané uživatelem, dostali jsme se právě k tomu, proč je pro reprezentaci
stavu tohoto typu hry vhodné (dvourozměrné) pole a proč se nedá vše v programu řešit
konečným množstvím ifů, několika tucty špatně pojmenovaných proměnných a enumerací
fixního počtu "vítězných" stavů.
3) Výklad by neměl svou suchopárností potlačovat právě tu radost z "prasení" kódu
a objevování. Neměl by dogmaticky tvrdit, že se pokaždé programuje právě jen takto
a nikdy jinak. Naopak, měl by ukazovat, že k výsledku vede mnoho cest a že programování
je aktivita v otevřeném světě, kde jen úplní hlupáci postupují po vyznačených cestičkách
a v ruce nesou bibli momentálně platných zásad, pravidel a konvencí, protože se bojí,
aby je kolegové-inkvizitoři při code review nezačali křižovat, místo toho, aby dodali
po všech stránkách originální, problém skutečně řešící a technicky brilantní řešení.
Výklad by ale měl nenásilně sugerovat, že je dobré pravidla perfektně znát, než je
začnu z důvodu vyššího projektového dobra porušovat. Výklad by neměl ukazovat OOP/FP
na místech, kde OOP/FP ničemu neposlouží a jde jen o samoúčelné hrátky typu "júúú
dekorátor a heč, znám i monády a chrstnu ti je do tváře v každé kapitole, i když jsem
jejich princip sám nepochopil".
4) A kdyby v průběhu výkladu autor vytvářel nějakou hru, bylo by to ideální, ale to
už bych chtěl asi moc.
5) Kniha musí být pro novější verzi Pythonu.
V Pythonu nedělám. V ČJ jsem našel jen dvě knihy, které vypadají zajímavě.
Pecinovský,
Rudolf: Začínáme programovat v jazyku Python 2., přepracované a rozšířené vydání.
Grada.
Nejsem úplně nadšený z toho, že jde o Pecinovského, který asi přesedlal z Javy, ale
třeba mám jen (odůvodněné) předsudky.
Summerfield, Mark: Python
3: Výukový kurz. Computer Press 2021.
Bohužel jde o překlad a už jsem zase narazil na to, že tyhle překlady stále dělají
individua, evidentně blbější než DeepL i Google Translate, která přeloží klíčová slova
jazyka ve výpisech zdrojového kódu. A neotřelý český překlad, ve kterém se objevuje
slovo "madlo" a znamená Win handle, mě ve snech straší pořád.
Nemáte někdo tip? Díky.
V animovaném gifu je ukázka z jednoho příkladu, který jsem ukazoval minulý týden.
Předpokládám, že se dá snadno poznat, čeho se příklad týká.
A dávám to sem, protože mám vyřízeny všechny resty, které se týkají inhouse kurzů objednaných v době covidové a přesunutých na lepší časy. Lepší časy sice kvůli válce na Ukrajině nepřišly, ale přesto jsem stihnul za poslední 4 měsíce dokončit více kurzů než za celé předchozí dva roky.
A proto i tady píšu, že jestli jste ode mě poslední rok obdrželi email "inhouse kurzy se prozatím objednat nedají a neřeknu vám přesný termín, kdy je zase bude možné objednat", tak už tato informace neplatí.
Příklad dole je napsán v C++ 20. A jestli jste se zaradovali, že v C++ 20 jsou coroutines, ale pak jste zjistili, že ve standardní knihovně si "co_awaitování" moc neužijete, ukážu vám svou knihovnu, kde jsou všechny typy potřebné pro psaní paralelizovaného a asynchronního kódu.
A jestli jste ještě třeba nepřešli z C++ 98 na C++ 11 (C++ 14, C++ 17) a potřebujete do nové spletité syntaktické džungle průvodce, který vám proseká cestu k jednoduššímu jazyku, který se za tím starým bordelem skrývá, můžeme se také domluvit.
Objednat se dají samozřejmě ale i kurzy, kde hlavní roli hraje C# a třeba .NET 6.
A pokud nechcete řešit nějaké triviality, které si může člověk, který není líný, přečíst a nastudovat v každém druhém tutorialu a přežvýkají vám je na každém školení, určitě se domluvíme.
Jak jsem psal v jednom z předchozích příspěvků v minulém roce, některé posty, které
se dříve objevovaly i na tomto blogu, píšu na jiný blog.
Právě dnes uběhlo 86 let od zavraždění profesora Moritze Schlicka. Když jsem psal
před rokem článek k 85. výročí této smutné události, liboval jsme si, že takové dementní
časy má už Evropa dávno za sebou. Ale není tomu tak. Seriál, ve kterém vražda nevinného
člověka není zločinem, má nekonečné množství epizod.
Celý příběh: https://renesteinposterous.wordpress.com/2021/06/22/85-let-od-zavrazdeni-profesora-moritze-schlicka/
Po nějaké době (psáno původně na FB, na blogu jsem ještě o smart home asi nepsal) zase něco ke "smart home" zařízením.
Neměl byste někdo vyzkoušenou nějakou smart home bránu, která:
1) Dokáže se připojit do WIFI sítě. Ale snesu i RJ45 konektor.
2) Mohou se k ní připojit bluetooth a bluetooth low energy (BLE) zařízení. A BLE má co největší dosah.
3) Podporuje ZigBee. Sice žádné ZigBee zařízení zatím nemám, ale to se asi brzy změní.
4) Podporuje zařízení od různých výrobců.
5) Nabízí nějaké rozumné API - je mi jedno, jestli půjde o REST API nebo o nějaké C/C++ SDK.
Můj původní záměr, že budu pořizovat zařízení jen od jednoho výrobce, vzal už dávno za své. Nedávno jsem si pořídil několik bluetooth teploměrů od XIAOMI (na AliExpressu jsou ještě levnější). Vím, XIAOMI byste doma nechtěli, ale nemusíte se bát, komunikaci teploměrů jsem prozkoumal fakt důkladně, doma nás nešpehují, nic důvěrného nikam neposílají a i když s gustem proklínáte (nejen čínské) komunisty, tak se žádné pekelné cenzorské moduly neaktivují. :) Tyhle teploměry za pár desetikorun (viz odkaz v komentářích) mají v sobě i bluetooth LE.
Sice se mi daří na Raspberry PI 4 odchytávat bluetooth komunikaci mezi dvěma patry (sleduju jen 'advertisements', nepřipojuju se k teploměru, abych nevybíjel baterii), ale spousta paketů se asi na cestě ztratí. Pakety jsou kryptované přes AES CCM, ale stačilo odchytit "bind key", přes který komunikuje aplikace od XIAOMI, podívat se, co XIAOMI aplikace dělá a klíč pro AES CCM byl na světě - pro fajnšmekry dodávám, že auth tag jsou 4 poslední bajty v paketu, AAD je poněkud lamerská fixní hodnota 0x11 a je třeba sestavit nonce.
Prototyp funguje dobře, nepotvrdilo se, že RPI 4 komunikuje s BT se zařízením do maximální vzdálenosti jednoho metru, ale stejně bych raději měl nějakou spolehlivější gateway.
A nějaká "relay" zařízení (ESP32) umístěná blízko teploměru, ve kterých odchytím BT pakety a přes LAN je přepošlu do své aplikace, bych bral jako poslední možnost. Máte někdo třeba XIAOMI BT gateway (3) a mohli byste napsat, jaký je jeji skutečný dosah přes BT?
Tady je vidět, že pakety chytám a můj BT sniffer na RPI 4 funguje.
Veškeré nápady, tipy, triky, zkušenosti jsou vítány. Díky.
Kniha Crafting Interpreters od Roberta Nystroma, kterou jsem o víkendu dočetl, je dílem, které by se mohlo stát klasikou.
Pro koho kniha je? Chtěli jste někdy vytvořit svůj vlastní programovací jazyk, nebo mít jednoduchý "embedovaný" skriptovací jazyk v aplikaci ? Moc ambiciózní a vy jste spokojeni se stávajícími jazyky? Hráli jste si třeba s C# Roslyn SDK, nebo jste použili C# generators a zhrozili jste se, jak amatérsky a nevzhledně vypadá generátor kódu? Samozřejmě ne ten váš generátor, ale generátor kolegy? Tedy generátor zní pořád až příliš vznešeně, co jsem tak různě viděl, spíš spojování stringů na steroidech, u pokročilejších s využitím StringBuilderu?
V knize Crafting Intepreters Robert Nystrom navrhne jazyk Lox. Lox je taková mini-Java (mini-C#, prostě jazyk s C like syntaxí), ale i přes nehezké přízvisko mini, které jsem použil v předchozí větě, LOX podporuje i OOP nebo closures - funkce, které zachytí proměnné ve svém okolí.
V první části knihy autor nejprve napíše jednoduchý parser, lexer a interpreter Loxu v Javě.
V druhé a pro mě zajímavější části autor napíše pro LOX (stack based) virtuální stroj v jazyce C včetně jednoduchého, ale plně funkčního garbage collectoru (jednovláknový, nekonkurenční, "stop the world"). A vytvoříte všechny instrukce pro virtuální stroj včetně vlastního disassembleru. A když když máte VM v C, portování Loxu na další HW platformy je hračka.
Je poněkud tragické vidět vývojáře, kteří třeba intermediate language (IL) a VM v .NET považují za černé skříňky, kterým nemusejí vůbec rozumět. Do určité míry je to pravda, ale u každé netriviální aplikace potřebujete znát trochu více než syntaxi zvoleného programovacího jazyka a pár knihoven. A někdy ani nestačí, že jako firemní vývojářské eso rozpoznáte, kde je vyhledávací pole na StackOverflow, kam posléze vložíte své zoufalé a bezradné skřeky.
Na knize je skvělé, že obsahuje kompletní zdrojový kód. Ne útržky, ne odkazy na github. Veškerý výklad je prokládán kódem a je docela úleva číst knihu, ve které nejsou jen neoptimalizované fragmenty kódu, ale autor si dá práci, aby před vámi neskrýval žádné kroky, svůj kód před vámi vyladil a upozornil na typické chyby, kterých se dopustí asi každý, pokud píše třeba parser poprvé.
Zvláštní cenu autor dostává za to, že nepoužívá trapné věty typu "tuto funkci už psát nebudeme, ponecháme ji jako cvičení pro bystré čtenáře." Moudří vědí, že jako cvičení pro čtenáře se často nechávají úlohy, které autor knihy nezvládne. Tento otravný a trapný trik asi autoři knih převzali od přednášejících mdlého ducha, kteří mají času dost, ale stejně ve stanoveném čase nestihnou vykoktat penzum znalostí, které si sami čerstvě osvojili den před svou přednáškou na konferenci, a s chutí přehazují povinnosti na posluchače.
Také oceňuji, že kniha pro Kindle má všechny výpisy kódu čitelné. Pořád nejde o samozřejmost. Sami jste asi také narazili na odbornou eknihu, která byla formátována tak, že zdrojový kód nebo tabulky nebylo možné přečíst bez opičích chvatů (podržením prstu zvětším grafický objekt a skroluji tam a zpátky).
Za tuhle knihu si autor zaslouží zaplatit, ale kdybyste byli i po mé nadšené anotaci na vážkách, nebo máte zrovna hluboko do kapsy, kniha je na webu zdarma.
Extenze/Analyzér ConfigureAwaitEnforcer , která ohlídá, že jste nezapomněli u ‘await’
výrazu v knihovně použít ConfigureAwait(false), má novou verzi 2.0.0.0.
Změny:
Extenzi lze nainstalovat přímo z Visual Studia. Analyzér můžete stáhnout pomocí NuGetu.
Přímé odkazy:
Extenze pro VS 2022 (Preview) - https://marketplace.visualstudio.com/items?itemName=Rene-Stein.ConfigureAwaitEnforcer2022.
Extenze pro VS 2019 - https://marketplace.visualstudio.com/items?itemName=Rene-Stein.ConfigureAwaitEnforcer
NuGet balíček - https://www.nuget.org/packages/ConfigureAwaitEnforcer/
Zdrojový kód - https://github.com/renestein/ConfigureAwaitEnforcer
Jak asi sami víte a vidíte, tento blog je technicky zaostalá zombie a neměl jsem zatím
čas ani chuť přenést příspěvky na moderní blog engine s https.
Nedávno se ke mně od jednoho starého fanouška donesla stížnost, že na blogu se objevovalo
nejen více technických příspěvků, ale také články s jinými tématy.
Kdyby moje výplody “de profundis” a z ještě temnějších míst chyběly i někomu dalšímu,
kdo sem ještě zabloudí, vězte, že:
Už někdy v roce 2010 jsem netechnické články přenesl na blogovací platformu Posterous.
Psal jsem o Posterous API i tady, dokonce jsem si prozřetelně s využitím Posterous
API napsal nástroj, který mi zazálohoval všechny příspěvky na Posterous blogu. Asi
jsem měl nějaké tušení, jak nablýskaný Posterous dopadne. Posterous totiž po krátké
a těžké nemoci zesnul, budiž mu digitální země lehká. Pokračovatelem mého blogu na
Posterous se stal blog “Život po Posterous” (nemusím vysvětlovat proč) s podtitulem
“Parerga a paralipomena – apage vemena” (nechci
vysvělovat proč, laskavý čtenář pochopí).
https://renesteinposterous.wordpress.com/
RSS: https://renesteinposterous.wordpress.com/feed/
Na blog někdy přidávám delší příspěvky z FB.
https://www.facebook.com/renestein/
Twitter cca od roku 2015 nepoužívám. To, že v panelu vpravo na tomto blogu můžete
vidět vloženou timeline z Twitteru, je jen důkaz, jak dlouho se mi už nechce tento
blog po technické stránce upravovat. Mea culpa, mea maxima culpa, pravidelně si trhám
šat a sypu popel na hlavu, ale co se dá dělat, ani tyhle bohulibé aktivity nepomáhají
a jsou zajímavější činnosti než úklid bordelu na starém DasBlogu.
P. S. Jsem také na Goodreads.
https://www.goodreads.com/user/show/4224377-rene-stein
TL;DR
Jestli někdo chcete/potřebujete pracovat s HDO rozpisem, můžete použít mou novou .NET Standard 2.0 knihovnu pro snadné získání rozpisu HDO (hromadné dálkové ovládání - laicky řečeno, chcete znát a ve svém programu pracovat s časy, kdy je aktivní takzvaný nízký tarif elektřiny).
Nyní se data stahují z ČEZu.
https://github.com/renestein/RStein.HDO
Konec TL;DR
Nedávno jsem psal na FB o chytrých zásuvkách, které bych chtěl automaticky synchronizovat s HDO rozpisem od ČEZu.
Přes Velikonoce jsem pokročil a nyní už mi stačí u "chytré" zásuvky (chytrého zařízení):
1) Po zakoupení a přidání zásuvky nastavit, že se řídí podle HDO rozpisu. Pokud takový příznak nastaven není, v zásuvce můžete mít jakákoli jiná ručně zadaná pravidla pro vypínání a zapínání zařízení a tato pravidla nebudou nikdy přepsána pravidly z HDO rozpisu.
2) Můj nový agent pro Smart Home pravidelně stáhne HDO data z Čezu, porovná stávající pravidla v zásuvkách, u kterých je nastaveno, že se řídí HDO rozpisem, s pravidly v HDO rozpisu u ČEZu, a jestliže se pravidla liší, změní pravidla v zásuvkách tak, aby byla shodná s aktuálním ČEZ HDO rozpisem.
Vedlejším výsledkem je .NET Standard 2.0 knihovna RStein.HDO, kterou jsem oddělil od hlavního a neveřejného projektu, protože jsem si říkal, že knihovnu já a možná i někdo jiný využijeme i pro jiné účely.
Základní funkce:
1) Stáhne data z ČEZu a vytvoří z nich rozpis (scheduli).
2) Schedule může být cachována (doporučuju, aby nás ČEZ neblokl, stahovat data maximálně jednou denně - rozpis HDO se zase tak často nemění).
3) Schedule se snadno dotážete, jestli je HDO v daném čase aktivní.
4) Kdyby vám nestačila vystavená strukturovaná data, dostanete se jednoduše i k nezpracovaným původním JSON datům z ČEZu a k objektovému modelu, který jim odpovídá.
Pár poznámek na závěr.
1) Pull requesty pro jiné distributory elektřiny jsou vítány.
2) Paskvily v enumeraci CezRegion - např. CezRegion.stred (čeština, neidiomatické malé písmeno na začátku názvu) jsou moje - název přesně odpovídá vyžadované reprezentaci hodnoty ve stringu.
3) Česko-anglické patvary v původním modelu (SAZBA, VALID_FROM) jsou dílem vývojářů v ČEZu.
A jeden jeden postřeh nakonec. GitHub actions pro CI/CD jsou mnohem lépe zdokumentovány než Azure pipelines. I když si odmyslím dokumentaci, přijdou mi GitHub actions intuitivnější a logičtější než Azure pipelines. Popularitu YAMLu ale stejně pořád nechápu.
Knihovna RStein.AsyncCpp (Task Parallel Library for C++) je ve verzi 0.0.7 a dá se snadno nainstalovat pomocí Microsoft vcpkg.
vcpkg install rsasynccpp rsasynccpp:x64-Windows
(Včera mi Microsoft udělal radost a mergnul PR do masteru - https://github.com/microsoft/vcpkg/pull/16380)
Detaily k instalaci různých verzí knihovny jsou zde.
https://github.com/renestein/Rstein.AsyncCpp#Build-Library
Jestli někdo používáte UWP, tak vás potěší, že triplet UWP ve vcpkg je také podporován a všechny testy prošly.
Jestli nechcete používat vcpkg, můžete buildovat z příkazové řádky a pořád samozřejmě také i z Visual Studia 2019.
Dále knihovna podporuje coroutines ze standardu C++ 20 a stále podporuje i "legacy" coroutines.(https://devblogs.microsoft.com/.../c-coroutines-in.../)
Kromě kompilátoru MSVC cl knihovna nyní podporuje i Clang.
Třešničkou je, že na konci aplikace už není třeba volat metodu Scheduler::StopDefaultScheduler().
Parsování celého Shakespearova díla a vypsání 50 nejfrekventovanějších slov za cca
1,2 s. (Clang a (neoptimalizovaní) map/reduce aktoři na obyčejném Lenovo ThinkPadu
z roku 2016).
v0.0.7
v0.0.6
https://github.com/renestein/Rstein.AsyncCpp
PR, stars, opinions, issues are more than welcome! Thanks!
Added threadless actors:
Functional style actors* - with state/without state | with reply/without reply | synchronous/asynchronous
processing logic.
Object style actors* - developer inherits his own class from the ActorPolicy class
and delegates the work to the ScheduleFunction method that returns Task<T>.
Simple examples. (extracted from tests).
https://github.com/renestein/Rstein.AsyncCpp#threadless-actors-in-process-agents
Map/Reduce actors - counting word frequency in Shakespeare.
https://github.com/renestein/Rstein.AsyncCpp/tree/master/Samples/MapReduceActors
Planned features:
Dynamic proxy for simplified creation of actors from classes with an interface that contains only void returning or/and Task<T> returning methods. AFAIK C++ does not have support for the "dynamic" proxy. "Classic" smart proxy may be used only for pre-processing and post-processing of the method call in the "real" subject.
Asynchronous logic (support for co_await/co_return) in "OOP style" actors.
The context for messages (a reference to a sender, a reply address, etc.)
FSM actors.
"Supervisors".
More samples.
* What is an actor? https://en.wikipedia.org/wiki/Actor_model
https://github.com/renestein/Rstein.AsyncCpp
Changes:
- Added AsyncMutex synchronization primitive.
https://github.com/renestein/Rstein.AsyncCpp#AsyncMutex
- TaskFactory.Run automatically unwraps nested Task (e.g. scheduled lambda-coroutine returns Task). Very convenient and prevents some hard-to-debug, but easy to introduce bugs in C++ coroutines.
https://github.com/renestein/Rstein.AsyncCpp#TaskFactory-Unwrap-Nested-Task
- Task has the Unwrap method ((Unwrap Task<Task<T> and returns Task<T>) and corresponding Fjoin method.
https://github.com/renestein/Rstein.AsyncCpp#Task-Fjoin
- Added SynchronizationContext - provides a mechanism to queue work to a specialized context. (useful for marshaling calls to UI thread, event loop, etc.)
https://github.com/renestein/Rstein.AsyncCpp#synchronizationcontext
- Added SynchronizationContextScope - RAII class for SynchronizationContext. An instance of this class captures the current synchronization context in the constructor (now 'old' context), installs new synchronization context provided by the user, and restores 'old' synchronization context in the destructor.)
https://github.com/renestein/Rstein.AsyncCpp#SynchronizationContextScope
- Added ConfigureAwait method (for the Task awaiter) - configures if the 'co_await continuation' is resumed in the specific synchronization context.
https://github.com/renestein/Rstein.AsyncCpp#ConfigureAwait
- Added GlobalTaskSettings::UseOnlyConfigureAwaitFalseBehavior configuration key - set the key to true if you want to enforce the equivalent of the 'co_await someTask.ConfigureAwait(false)' for all 'co_await someTask{anything}' expressions in the application - synchronization context is then never used when resuming the 'co_await continuation'.
https://github.com/renestein/Rstein.AsyncCpp#GlobalTaskSettings-UseOnlyConfigureAwaitFalseBehavior
- Task.ContinueWith method has new overloads with CancellationToken argument.
Příspěvek nejen pro ty, kteří se od března do června nedočkají kvůli COVIDu C++ kurzu. Kdyby se někdo nudil, nebo mu lezly na mozek ty neustále se opakující zprávy o Babišovi, rouškách a další variace na mem "všichni tady chcípnem, když ne na COVID, tak na sucho", dovolím si upozornit na jednu poměrně čerstvou (neoptimalizovaná alfa) asynchronní švestičku ze své zahrádky. Švestičky i optimisticky naznačují roční období, kdy se snad uvidíme, jestliže macecha příroda nereleasne implementaci zmutované specifikace COVID++.
RStein.AsyncCpp používající coroutine z C++ 20 je knihovna, ve které se rychle zorientuje
každý, kdo zná Task Parallel Library (.NET, C#).
V knihovně najdete nejen:
Task (tedy něco jako std:future) - tásky jsou narozdíl od knihovny cppcoro, kterou
asi znáte, 'hot' - tedy přes TaskFactory je Task rovnou nastartován a naschedulován
k vyřízení.
Task má API, které čekáte. A narozdíl od std::future má metodu ContinueWith (then).
Task se dá "co_awaitovat", protože podporuje concept "Awaiter". A můžete ho samozřejmě použít jako návratovou hodnotu z coroutine metody ("coroutine promise type").
Dále jsou v knihovně jednoduché metody pro vytvoření dokončeného Tasku z předpřipravené hodnoty (TaskFromResult), z výjimky (TaskFromException), nebo lze vrátit Task ve stavu Canceled (TaskFromCanceled).
Jednoduché DataFlow. ("flat", "fork-join" a a další typy).
Kombinátory pro Task:
WaitAll.
WaitAny.
TaskCompletionSouce - std:: promise bez těch otravných věcí, které určitě znáte sami.
Funkcionální kompozice tasku.
Fbind (alias bind, SelectMany, flatMap, mapMany)
Fmap (map, Select)
Asynchronní primitivy.
AsyncSemaphore.
Kooperativní storno pomocí tříd CancellationTokenSource a a CancellationToken.
AsyncProducerConsumerCollection.
Více zde:
https://github.com/renestein/Rstein.AsyncCpp
-------------------------------------------------------------------------------
Dear friends/followers,
maybe the result of my experimentation with coroutines may be interesting for someone
else.
The RStein.AsyncCpp library (early unoptimized alpha) is a set of types that should
be familiar for anyone who knows the Task Parallel Library (TPL) for .NET (C#). In
addition, this library contains simple DataFlow, functional combinators for the Task
class, useful async primitives (AsyncSemaphore, AsyncProducerConsumerCollection, CancellationToken,
CancellationTokenSource ...).
The library is my playground for testing coroutine support in C++.
The library supports compilation in the VS 2019. Support for other compilers is planned.
More info.
https://github.com/renestein/Rstein.AsyncCpp
I když je tento blog nechutná a technicky zaostalá zombie, která vede k úvahám, jak
konečně tuhle bestii zabít, aby mě už nestrašila, dá se přesto, nebo možná právě proto
:), využít k šíření ConfigureAwait infekce v cizím kódu. I tady by snad ještě
někoho mohla zajímat moje extenze
pro Visual Studio, která zkontroluje:
1) Jestli jste při použití ‘await someTask’ nezapomněli na ConfigureAwait(false).
Když jste tuhle chybu udělali, extenze dotyčný řádek jako prototypická labilní nervní
učitelka červeně podtrhne a:
a) Nabídne úpravu výrazu přidáním ConfigureAwait(false).
b) Nabídne úpravu výrazu přidáním ConfigureAwait(true).
Nejlepší je extenzi vidět v akci.
Ve verzi 1.1 si můžete zvolit i závažnost diagnostiky (Error, Warning, Info, Hidden).
Analyzér je dostupný i na nugetu.
https://www.nuget.org/packages/ConfigureAwaitEnforcer/
Zdrojové kódy.
Bitbucket
https://bitbucket.org/renestein/configureawaitenforcer/src/master/
Github
Rád bych vás pozval na svou přednášku, kterou pořádá WUG.
Název přednášky: TPL - konkurenční, paralelní a asynchronní kód pro náročné.
Místo konání: pobočka: BB centrum, budova Alfa (Aquarius), Vyskočilova 1461/2a, Praha 4
Registrace na přednášku: http://wug.cz/praha/akce/597-TPL-konkurencni-paralelni-a-asynchronni-kod-pro-narocne
Anotace přednášky:
Znáte alespoň trochu Task Parallel Library a přednášek slibujících další nenáročný „úvod do TPL“ jste už viděli dost? Myslíte si, že klíčová slova async/await v C# jsou magií kompilátoru, jejíž kouzlo pro vás už navěky pominulo po zhlédnutí triviálních a donekonečna opisovaných příkladů, jak zavolat asynchronně pár nudných webových služeb?
Na přednášce probereme, jak rozšířit knihovnu TPL o další užitečné konstrukce i jak odstranit některá omezení v současné verzi TPL. Podíváme se na různé způsoby psaní konkurenčního, paralelního a asynchronního kódu. U konkurenčního kódu se zaměříme (nejen) na aktory a porovnáme různé způsoby, jak můžeme aktory psát.
Nezapomeňte s sebou vzít i kolegy, kteří hlásají, že každou nebezpečnou hlavu konkurenčního kódu setne jeden pořádný „lock“, a to nejlépe rekurzivní, aby vás deadlock nebo livelock ve firmě zabavil i o dlouhých zimních večerech.
(Starší verze obnovena ze zálohy 21. 1. 2020.)
V
předchozím díle o coroutines jsme poprvé viděli, jak se dá použít IoServiceScheduler.
V tomto článku uvidíme, že pár metod IoServiceScheduleru
stačí i k napsání jednoduchého threadpoolu. Tento článek i následující článek jsou
oproti předchozím článkům kratší a oddechové, abychom získali důvěrný vztah
ke způsobu práce se schedulery v knihovně RStein.Async,
a nepřekvapil nás v šestém díle StrandScheduler, se kterým se vydáme mezi aktory.
Knihovna RStein.Async je
dostupná na Bitbucketu.
git clone git@bitbucket.org:renestein/rstein.async.git
Seriál Task Parallel Library a RStein.Async (předběžná osnova)
Task Parallel Library a RStein. Async 1 z n – Popis základních tříd a obcházení omezení v TPL.
Task Parallel Library a RStein. Async 2 z n – (boost) ASIO v .Net a IoServiceScheduler.
Task Parallel Library a RStein. Async 3 z n – Ukázky použití IoServiceScheduleru. Coroutines.
Task Parallel Library a RStein. Async 4 z n – ThreadPoolScheduler založený na IoServiceScheduleru.
Task Parallel Library a RStein. Async 5 z n – Hrajeme si s ThreadPoolSchedulerem.
Task Parallel Library a RStein. Async 6 z n – Vytvoření StrandScheduleru.
Task Parallel Library a RStein. Async 7 z n – Náhrada za některé synchronizační promitivy – ConcurrentStrandSchedulerPair.
Task Parallel Library a RStein. Async 8 z n – Jednoduchý “threadless” actor model s využitím StrandScheduleru.
Task Parallel Library a RStein. Async 9 z n – Píšeme aktory I.
Task Parallel Library a RStein. Async 10 z n – Píšeme aktory II.
Task Parallel Library a RStein. Async 11 z n – Píšeme nový synchronizační kontext - IoServiceSynchronizationContext.
Task Parallel Library a RStein. Async 12 z n – Použití IoServiceSynchronizationContextu v konzolové aplikaci a Windows službě.
(bude upřesněno)
ThreadPool z .Net Frameworku nebo threadpool z WIN32 API znáte. ThreadPool není v základu nic jiného než volné sdružení déle žijících threadů, které bylo založeno za účelem rychlého zpracování tásků. ThreadPool se používá hlavně proto, abychom v aplikace nevytvářeli a nelikvidovali thready, jak se nám zlíbí, protože thready nejsou zrovna “laciné” objekty na vytvoření, správu ani likvidaci, Jak jsem již v seriálu zmínil, TaskScheduler.Default využívá k vyřizování tásků standardní .Net ThreadPool.
Náš threadpool bude oproti třídě ThreadPool v .Net Frameworku velmi jednoduchý. Hlavním rozdílem bude to, že nebudeme podporovat “work stealing queue”, i když by nebyl příliš velký problém takovou podporu dopsat.
Dalším podstatným rozdílem oproti threadpoolu v .Net frameworku je to, že náš
threadpool bude k vyřizování tásků od svého vytvoření až do svého zrušení používat fixní
a po celou dobu svého života stejný počet threadů. V .Net
threadpoolu se může počet threadů měnit. .Net
threadpool přidá thread mj. v situaci, kdy předpokládá, že mohlo dojít k deadlocku.
Kdy může v threadpoolu dojít k deadlocku?
Heuristika .Net threadpoolu po nějakém čase iniciuje vytvoření další threadu, protože je zřejmé, že všechny thready v threadpoolu jsou využity, ale žádné tásky nebyly již “delší dobu” dokončeny. Nově vytvořený thread vyřídí tásk s číslem 11, tím se uvolní tásk v threadu 10 a doběhnou i tásky v threadech 1-9. Voilà, deadlock byl odstraněn. Samozřejmě že tohle je jen jedna z variací mnoha zhoubných scénářů, které si asi všichni dokážeme představit. Tásk v threadu 11 by mohl třeba vygenerovat tásky 12-20 a čekat na jejich dokončení a threadpool by chtě nechtě přidával další a další thready.
Já tohle chování threadpoolu, které se na první pohled může zdát jako vstřícné a bezproblémové, nepovažuju za moc vhodné, protože threadpool jím kamufluje po dlouhou dobu některé nepříjemné chyby v logice aplikace a toleruje i velmi těsné a nevhodné vztahy mezi tásky. Náš threadpool nikdy po počáteční inicializaci fixního počtu threadů žádný další thread nepřidá. A to ani tehdy, jestliže je mu předán tásk, u něhož je nastaven příznak LongRunning. Jestliže to někomu vadí, pull request je vítán.
IoServiceThreadPoolScheduler staví na konstrukcích pro schedulery, které jsme si vysvětlili v prvním díle.
Na IoServiceThreadPoolScheduleru je nejzajímavější, že nám k napsání threadpoolu stačí pár řádků. Většinu práce opět odvede IoServiceScheduler. Snad teď už začíná být zřejmé, proč jsem IoServiceScheduleru věnoval tak dlouhý díl.
Příště se podíváme na testy, ze kterých vyplyne, jak má být ThreadPoolScheduler používán, a proč metodu QueueUserWorkItem nepotřebujeme.