Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Mirek Prýmek 14. 03. 2021, 23:36:08

Název: CSP v embedded světě
Přispěvatel: Mirek Prýmek 14. 03. 2021, 23:36:08
Čau,

snad nevadí, když nepoložím dotaz, ale (zne|vy)užiju fóra k neformálnímu brainstormingu.

V sousedním vlákně jsme s Idrisem narazili na myšlenku [1], která mi nedá spát.

V krátkosti shrnu:

Aniž bych si udělal nějaký větší research, zkusil jsem si představit, jestli by se dalo pro zábavu naprogramovat v C aspoň malé demo/technology preview takové knihovny. Komunikační primitiva, scheduling nejsou problém, nějaký jednoduchý virtuální stroj si případně taky umím představit. Co mi ale dělá vrásky, jsou procesy. Ty totiž musí být vytvořitelné dynamicky a knihovna jich musí zvládat potenciálně "velké" množství (definici "velké" zatím nechme být, řekněme třeba desítky?) A pokud se chceme bavit o konkurentnosti, každý proces musí mít vlastní stack. Alespoň v nějaké standardní, přímočaré implementaci.

A to už začíná být v embedded problém. Stacky musí být vyhrazené, dostatečně velké a naplno se zaplní jenom občas, navíc typicky ne naráz. Takže dost neefektivní využití paměti. A co je horší - člověk těžko získá nějakou jistou garanci, že stack bude vždy stačit. Pokud vím, obvykle se prostě nastaví "dostatečně velký", což se ale dá udělat třeba u FreeRTOSu s pár statickými tasky ručně, ale ne u předpokládaného hodně dynamického systému se spoustou procesů.

Takže otázka je, jestli vás nenapadá, čím by se daly klasické stacky nahradit, případě jestli by se nedala konkurentnost implementovat nějakým způsobem, který by problémem řídce využité a přesto potenciálně příliš malé paměti netrpěl.

Berte to prosím fakt jako brainstorming, takže žádná myšlenka není příliš pitomá nebo sci-fi, aby nemohla zaznít ;) Jde o srandu a mentální cvičení, raketu tím řídit nehodlám, takže žádná křeč ;)

[1] https://forum.root.cz/index.php?topic=24381.msg346418#msg346418
[2] https://en.wikipedia.org/wiki/Communicating_sequential_processes - tj. program je rozdělený na konkurentní procesy komunikující pomocí kanálů
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 14. 03. 2021, 23:48:37
Vykopnu jeden nápad:

Jenom tak intuitivne, bez jakyhokoli researche si rikam, jestli by se nedal udelat nejaky jakoby "sdileny stack" - ze by se pouzily treba kontinuace bez moznosti returnu, takze by se nemusel udrzovat stack a kazda kontinuace by dostala cely potrebny kontext (stav) a pak by existovala treba nejaka globalni tabulka vsech kontinuaci, ze ktere by se pri kazdem kroku jenom vybrala nahodne kontinuace, ktera ja pripravena bezet. Cili misto spousty individualnich stacku by byla jedna globalni tabulka, ktera by pamet vyuzila lip a stacilo by kontrolovat, ze nepretece ona. Stav by mohl byt bud alokovany na halde, nebo by byla treba svrchu omezena jeho maximalni velikost, aby polozky v tabulce mely fixni velikost.

Prakticky by se teda program musel rozdělit na části, které by vždycky začínaly nějaký čekáním na něco - typicky na zprávu v kanálu. Z každé části by se pak udělaly funkce (callbacky). Každý callback by musel všechna data, která potřebuje, dostávat jako argumenty. "Globální stack" by potom spočíval v seznamu callbacků spolu s jejich argumenty a podmínkami, za kterých můžou běžet. Scheduler by pak prostě jenom z tabulky náhodně vybral callback, u nehož jsou podmínky splněné, a spustil ho.

Prostě princip podobný futures, resp. async/await, ale s jinou motivací a ruční implementací.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 00:05:35
každý proces musí mít vlastní stack
Proč?
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 00:13:10
Proč?
Přijde mi to samozřejmý, ale tak asi tou otázkou někam míříš...

Protože každý task se může v danou chvíli nacházet v libovolném místě programu a potřebuje teda mít někde uložený kontext volání?

viz obrázek "Memory layout of a multi-threaded program" tady: https://ferrous-systems.com/blog/embedded-concurrency-patterns/

P.S. Posílal jsem ti tohle i jako SZ, ale jsou tady blbě viditelný, asi jsi to nepostřehl.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 00:14:23
Takže otázka je, jestli vás nenapadá, čím by se daly klasické stacky nahradit, případě jestli by se nedala konkurentnost implementovat nějakým způsobem
Nejjednodušší je mít normální zásobníky a v případě potřeby je zvětšovat. Takhle to má Go a šlape to skvěle. Na MCU by mohla každá korutina začít třeba s 512B paměti (nebo i méně) a v případě potřeby růst. Není to žádná věda.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 00:16:57
Proč?
Přijde mi to samozřejmý, ale tak asi tou otázkou někam míříš...

Protože každý task se může v danou chvíli nacházet v libovolném místě programu a potřebuje teda mít někde uložený kontext volání?

viz obrázek "Memory layout of a multi-threaded program" tady: https://ferrous-systems.com/blog/embedded-concurrency-patterns/

P.S. Posílal jsem ti tohle i jako SZ, ale jsou tady blbě viditelný, asi jsi to nepostřehl.
Ne, SZ jsem si všiml až teď, po upozornění :)

Samozřejmé to není, asi se shodneme na použití kooperativního multitaskingu, což implikuje použití korutin. A ty můžou být bezzásobníkové. Nicméně viz mou předchozí odpověď.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 00:27:51
Nejjednodušší je mít normální zásobníky a v případě potřeby je zvětšovat. Takhle to má Go a šlape to skvěle. Na MCU by mohla každá korutina začít třeba s 512B paměti (nebo i méně) a v případě potřeby růst. Není to žádná věda.
Jo, to by asi šlo. Zvlášť pokud by procesy byly short-lived jako v Erlangu, mohlo by to být dost dobrý řešení, paměť by se často uvolňovala. Zároveň by se musela sem tam kopírovat, ale na to asi sere pes ;)

Samozřejmé to není, asi se shodneme na použití kooperativního multitaskingu, což implikuje použití korutin. A ty můžou být bezzásobníkové.
Aha! Klíčové slovo teda "stackless coroutine". Co na to zatím z rychlíku dívám, přijde mi to dost podobné té má intuitivní představě.

Ok, dík, ještě na to víc kouknu, vypadá to zajímavě.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 00:36:18
Posílal jsem ti tohle i jako SZ
S dovolením odpovím tady, ať to je na očích. Jo, je to zajímavé, sám si pohrávám s myšlenkou napsat překladač (podmnožiny) Go pro MCU. Osobně bych z několika důvodů upřednostnil ty už zmíněné nafukovací zásobníky. Ten tvůj "divoký" :) nápad má v sobě rysy bezzásobníkových korutin (stackless), ale to by asi bylo na MCU zbytečně komplikované. Implicitně toho jde dosáhnout přes bloky, tak jak je má Apple v C (viz Wikipedie: https://en.wikipedia.org/wiki/Blocks_(C_language_extension) (https://en.wikipedia.org/wiki/Blocks_(C_language_extension))). Překladač kopíruje proměnné v případě potřeby naprosto transparentně na haldu (schválně si zkus udělat lokální int p a zírej, jak se po přesunu bloku na haldu změní &p). Tohle je alternativní cesta (výzvou pak je napsat překladač, který by to zautomatizoval).
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 00:39:08
Ten tvůj "divoký" :) nápad
Nepopírám, že divoký. Nikdy jsem se tímhle nezabýval, překladače nikdy nebyly moje hobby :) Dík za nasměrování.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 00:39:33
Nejjednodušší je mít normální zásobníky a v případě potřeby je zvětšovat. Takhle to má Go a šlape to skvěle. Na MCU by mohla každá korutina začít třeba s 512B paměti (nebo i méně) a v případě potřeby růst. Není to žádná věda.
Jo, to by asi šlo. Zvlášť pokud by procesy byly short-lived jako v Erlangu, mohlo by to být dost dobrý řešení, paměť by se často uvolňovala. Zároveň by se musela sem tam kopírovat, ale na to asi sere pes ;)
Jo, občas se kopíruje paměť (při nafukování zásobníku), proto se ti občas pod rukama změní ukazatel na instanci objektu (to může být zábavné, když v Go předáš ukazatel přes cgo někam ven a runtime ho při nafukování aktualizuje) :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 00:40:47
Samozřejmé to není, asi se shodneme na použití kooperativního multitaskingu, což implikuje použití korutin. A ty můžou být bezzásobníkové.
Aha! Klíčové slovo teda "stackless coroutine". Co na to zatím z rychlíku dívám, přijde mi to dost podobné té má intuitivní představě.
Ano, je tam jistá neinfinitezimální podobnost ;)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 00:41:21
Jo, občas se kopíruje paměť (při nafukování zásobníku), proto se ti občas pod rukama změní ukazatel na instanci objektu (to může být zábavné, když v Go předáš ukazatel přes cgo někam ven a runtime ho při nafukování aktualizuje) :)
To mi neva, můj quick&dirty pokus, jesti se k němu někdy dostanu, rozhodně ukazatele podporovat nebude :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 00:43:22
Ten tvůj "divoký" :) nápad
Nepopírám, že divoký. Nikdy jsem se tímhle nezabýval, překladače nikdy nebyly moje hobby
V jádru není divoký, jen prostě brainstormingově napsaný ;) Glad to be of help
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 00:44:36
Jo, občas se kopíruje paměť (při nafukování zásobníku), proto se ti občas pod rukama změní ukazatel na instanci objektu (to může být zábavné, když v Go předáš ukazatel přes cgo někam ven a runtime ho při nafukování aktualizuje) :)
To mi neva, můj quick&dirty pokus, jesti se k němu někdy dostanu, rozhodně ukazatele podporovat nebude :)
A co to bude za jazyk?
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 00:48:04
A co to bude za jazyk?
Tak především nevím, jestli bude, TODO list rozhodně nemám prázdný :) Ale jestli si budu chtít někdy od všeho odpočinout, představoval bych si fakt jenom úplně nejjednodušší možné demo spousty tasků na malém MCU. Naprostý minimalismus ve stylu původního Hoareho článku nebo Occamu.

Samozřejmě se nebudu babrat s překladačem, na to fakt čas nemám, jde mi jenom o naimplementování těch primitv v C.
Název: Re:CSP v embedded světě
Přispěvatel: Křišťan Surname 15. 03. 2021, 00:49:35
Co se inspirovat RTC (Run To Completion) plánovači? Tj. každý task může být kdykoliv spuštěn, ale musí potom doběhnout (nebo spustit další task). Stack je potom jenom jeden. Dělali jsme tak poměrně brutální automaty v hardwaru úrovni ATTiny... někdy i s luxusními stovkami B RAM.

https://www.embedded.com/build-a-super-simple-tasker/
https://github.com/KnightSch/sst (opravdu vintage :-) ale je to čitelné)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 00:50:43
Tj. každý task může být kdykoliv spuštěn, ale musí potom doběhnout (nebo spustit další task).
No, to je v podstatě ta stejná myšlenka jako ta moje.
Název: Re:CSP v embedded světě
Přispěvatel: Křišťan Surname 15. 03. 2021, 00:55:26
Ten plánovač se pak v podstatě vejde do ISR, jen vybere z poolu task nejvyšší priority, vezme na něj function pointer a zavolá ho. Odpadá všechna ta makro magie která u RTOSů v tomhle obvykle dominuje. Kanály jsou pak taky celkem snadný (globální tabulka někde, a scheduler zohlední pending message v rozhodování).
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 00:56:38
Samozřejmě se nebudu babrat s překladačem, na to fakt čas nemám, jde mi jenom o naimplementování těch primitv v C.
V C? To asi nebude problém. Já kdysi napsal korutiny pro C na AMD64 a pak se mi to nějak povedlo přepsat i pro ARM (je to kupa let zpátky, tak asi ARM32, ale už si to nepamatuju, jen že to běhalo na iPhonu). Kanály tam nějak byly taky, ale ty nejsou problém. Zkusím to najít, co si tak pamutuju, největší opruz byl scheduler. Sranda taky bude rozběhat to na více jádrech (třeba Zobák má dvě).
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 01:02:31
V C? To asi nebude problém.
Nechci, aby to byl problém. Implementaci chci věnovat tak jedno odpoledne, kdyby mě to extra bavilo, tak možná víkend ;)

Já kdysi napsal korutiny pro C na AMD64 a pak se mi to nějak povedlo přepsat i pro ARM (je to kupa let zpátky, tak asi ARM32, ale už si to nepamatuju, jen že to běhalo na iPhonu). Kanály tam nějak byly taky, ale ty nejsou problém. Zkusím to najít, co si tak pamutuju, největší opruz byl scheduler. Sranda taky bude rozběhat to na více jádrech (třeba Zobák má dvě).
Záměrně to nechci vidět, to bych přišel o všechnu zábavu :)

Představuju si to jako punkovou srandu, implementovanou cestou nejmenšího odporu, v tom stylu, jak píše Křišťan. Když to bude blikat deseti LEDkama s tím, že třeba jenom dvě bliknutí zařídí jeden task a pak nějaký "supervisor" spustí automaticky další, bude to v mých očích mission accomplished :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 01:14:50
Představuju si to jako punkovou srandu, implementovanou cestou nejmenšího odporu, v tom stylu, jak píše Křišťan. Když to bude blikat deseti LEDkama s tím, že třeba jenom dvě bliknutí zařídí jeden task a pak nějaký "supervisor" spustí automaticky další, bude to v mých očích mission accomplished :)
Tak se pak pochlub ;)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 01:15:48
Tak se pak pochlub ;)
Jj, určitě, za tu spolupráci si to zasloužíte :)
Název: Re:CSP v embedded světě
Přispěvatel: RDa 15. 03. 2021, 01:18:06
Snazit se o multi-processing v systemu, ktery nema MMU je ponekud marne.
Takze polozim velice jednoduchou otazku:

Co prinese vas odlisny a pre-komplikovany system oproti obycejnemu main-loop cyklu, kde se kazdy "proces" projevuji svym loop-handlerem?

To, aby kazdy loop nebyl stejny, resi bool bitmapa "scheduled", nebo alternativni pristup k predavani tokenu, kdy se nejaky proces (event handler) muze pre-emptnout.

Protoze na MCU typicky nemate fork, bezi tam to, co tam bezet ma, v 0 az 1 instanci. Vse, nebo nic.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 01:32:40
Snazit se o multi-processing v systemu, ktery nema MMU je ponekud marne.
Myslim, ze se trochu mijime. To, co mam na mysli, je spis Erlang, nez Linux kernel.

Takze polozim velice jednoduchou otazku:

Co prinese vas odlisny a pre-komplikovany system oproti obycejnemu main-loop cyklu, kde se kazdy "proces" projevuji svym loop-handlerem?
Za prve: urcite ne pre-komplikovany. Jde mi prave o co nejvetsi jednoduchost.

Pak by se na to dalo odpovedet snadno: srandu, o nic jinyho nejde. Rict: "hele, tady mas Hoareho priklady implementovany na Atmeze v 1000 radcich cecka". To by bylo cool, nestaci to? ;)

A taky by se to dalo vzit seriozne a diskutovat o tom, 1. co to je "obycejny main-loop cyklus" (umoznuje za behu vytvaret nove tasky?) 2. cim se principielne lisi od jakehokoli jineho scheduleru 3. ze moje predstava neni jenom o scheduleru, ale o tom celkovem systemu CSP, ktery prave jenom dohromady dava smysl.

...ale do toho se asi poustet nebudu. Urcite ne ted, je pokrocila hodina a zitra musime roztacet kola kapitalismu, chlapi :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 01:35:01
moje predstava neni jenom o scheduleru, ale o tom celkovem systemu CSP, ktery prave jenom dohromady dava smysl.
To CSP je to zajímavé, scheduler je tam prostě z nutnosti :)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 01:36:23
To CSP je to zajímavé, scheduler je tam prostě z nutnosti :)
Presne! Scheduler je tam jenom technikalie, kterou je proste potreba nejak vyresit, aby to "svítilo a hřálo", jak říká klasik :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 01:46:58
To CSP je to zajímavé, scheduler je tam prostě z nutnosti :)
Presne! Scheduler je tam jenom technikalie, kterou je proste potreba nejak vyresit, aby to "svítilo a hřálo", jak říká klasik :)
Nádhera, nad CSP se pak dají udělat semafory, generátory, promises apod. Třešničkou by byly kanály mezi dvěma MCU (něco jako netchan v Go).
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 01:53:48
Nádhera, nad CSP se pak dají udělat semafory, generátory, promises apod. Třešničkou by byly kanály mezi dvěma MCU (něco jako netchan v Go).
Bingo! To jsem právě naťukl v tom původním vláknu s tím PRU na Beaglebone. To jsou dva oddělený procesory. A jakmile by bylo CSP rozchozený, je to už jenom kousek k dalším srandám.

Takže co třeba dvě Blue Pills za padesátikorunu jedno, propojené přes CAN bus a tasky migrují z jednoho na druhý podle zatížení CPU? Proč ne :) A když jsme u toho CAN busu, co třeba deset propojených Blue Pills a jeden blink task migruje z jednoho na druhý, takže každou chvilku blikne s LEDkou jinde? To jako motivace nestačí? Tak to už fakt nevím co teda ;)
Název: Re:CSP v embedded světě
Přispěvatel: RDa 15. 03. 2021, 02:43:22
Takže co třeba dvě Blue Pills za padesátikorunu jedno, propojené přes CAN bus a tasky migrují z jednoho na druhý podle zatížení CPU? Proč ne :) A když jsme u toho CAN busu, co třeba deset propojených Blue Pills a jeden blink task migruje z jednoho na druhý, takže každou chvilku blikne s LEDkou jinde? To jako motivace nestačí? Tak to už fakt nevím co teda ;)

Na cem jedete, ja chci taky takovej caj :P
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 10:32:47
Na cem jedete, ja chci taky takovej caj :P
Tyhle látky začne mozek produkovat přirozeně sám, stačí par let programovat v Elixiru :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 11:05:54
Na cem jedete, ja chci taky takovej caj :P
Tyhle látky začne mozek produkovat přirozeně sám, stačí par let programovat v Elixiru :)
Nejen Elixiru. Spíš stačí v praxi narazit na zajímavé problémy a po letech pokusů a omylů dokonvergovat k best practices (např. CSP).
Název: Re:CSP v embedded světě
Přispěvatel: Ondrej Nemecek 15. 03. 2021, 15:16:14
Nádhera, nad CSP se pak dají udělat semafory, generátory, promises apod. Třešničkou by byly kanály mezi dvěma MCU (něco jako netchan v Go).
Bingo! To jsem právě naťukl v tom původním vláknu s tím PRU na Beaglebone. To jsou dva oddělený procesory. A jakmile by bylo CSP rozchozený, je to už jenom kousek k dalším srandám.

Takže co třeba dvě Blue Pills za padesátikorunu jedno, propojené přes CAN bus a tasky migrují z jednoho na druhý podle zatížení CPU? Proč ne :) A když jsme u toho CAN busu, co třeba deset propojených Blue Pills a jeden blink task migruje z jednoho na druhý, takže každou chvilku blikne s LEDkou jinde? To jako motivace nestačí? Tak to už fakt nevím co teda ;)

Tento příklad mne motivoval se zapojit do diskuze  ;D

Představujete si to tak, že ten task nasadím jen na jednom node a on se sám distribuuje (tedy musí se přenést spustitelná podoba) anebo tak, že jsou nasazené na všech nodech (už tam je spustitelná podoba) a distribuuje se jen to vykonání? A zrovna u toho blikání jak synchronizovat čas (asi bychom chtěli, aby to blikalo alespoň přibližně ve správném itervalu)?

Přiznám se, že CSP neznám, ale podle popisu na wikipedii je to přesně to, co by se mi líbilo. IMHO divné že to už neexistuje (nebo existuje?).
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 15:25:11
Nádhera, nad CSP se pak dají udělat semafory, generátory, promises apod. Třešničkou by byly kanály mezi dvěma MCU (něco jako netchan v Go).
Bingo! To jsem právě naťukl v tom původním vláknu s tím PRU na Beaglebone. To jsou dva oddělený procesory. A jakmile by bylo CSP rozchozený, je to už jenom kousek k dalším srandám.

Takže co třeba dvě Blue Pills za padesátikorunu jedno, propojené přes CAN bus a tasky migrují z jednoho na druhý podle zatížení CPU? Proč ne :) A když jsme u toho CAN busu, co třeba deset propojených Blue Pills a jeden blink task migruje z jednoho na druhý, takže každou chvilku blikne s LEDkou jinde? To jako motivace nestačí? Tak to už fakt nevím co teda ;)

Tento příklad mne motivoval se zapojit do diskuze  ;D

Představujete si to tak, že ten task nasadím jen na jednom node a on se sám distribuuje (tedy musí se přenést spustitelná podoba) anebo tak, že jsou nasazené na všech nodech (už tam je spustitelná podoba) a distribuuje se jen to vykonání? A zrovna u toho blikání jak synchronizovat čas (asi bychom chtěli, aby to blikalo alespoň přibližně ve správném itervalu)?

Přiznám se, že CSP neznám, ale podle popisu na wikipedii je to přesně to, co by se mi líbilo. IMHO divné že to už neexistuje (nebo existuje?).
To druhé, ale přenášet přes kanály spustitelný kód by bylo taky zajímavé (zvlášť na MCU) :)

CSP existuje v mnoha podobách, jen na MCU moc ne. Třeba Pico má kanály pro komunikaci mezi vlákny (je dvoujádrové), tady se ale bavíme spíše o "userspacu" (kooperativní scheduler s podporou kanálů). Ve skutečnosti se vlastně bavíme o Go v pár kilobajtech paměti...
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 17:21:26
Představujete si to tak, že ten task nasadím jen na jednom node a on se sám distribuuje (tedy musí se přenést spustitelná podoba) anebo tak, že jsou nasazené na všech nodech (už tam je spustitelná podoba) a distribuuje se jen to vykonání?
Tak predstavit si umim ledasco :)

Postavil jsem robota nad ESP32 a stvalo me, jak dlouho trva OTA uprage firmwaru. Tak jsem tam udelal uplne jednoduchoucky virtualni stroj s par instrukcemi a upgrade timpadem prenasel jenom par desitek bytu. Tady by se to dalo udelat stejne, kdyby clovek chtel. Minimalisticka implementace CSP by vyzadovala jenom par instrukci, takze "virtualni stroj" by byl jeden switch s nekolika malo kejsy :)

A zrovna u toho blikání jak synchronizovat čas (asi bychom chtěli, aby to blikalo alespoň přibližně ve správném itervalu)?
Tak pokud mam vyreseny komunikacni kanal, je synchronizace casu (s nejakou rozumnou presnosti) uz jenom snadna skolni uloha :)

Přiznám se, že CSP neznám, ale podle popisu na wikipedii je to přesně to, co by se mi líbilo. IMHO divné že to už neexistuje (nebo existuje?).
Tak on ma RDa v principu pravdu, ze to striktne vzato neni potreba. Synchronizaci blikani po CAN busu si muzu napsat i natvrdo v C a bude to efektivnejsi, zejo...

Mne to prijde zajimavy ciste z "vyzkumnych", sebevzdelavacich a sebe-potesujicich duvodu :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 15. 03. 2021, 21:56:17
To CSP je to zajímavé, scheduler je tam prostě z nutnosti :)
Presne! Scheduler je tam jenom technikalie, kterou je proste potreba nejak vyresit, aby to "svítilo a hřálo", jak říká klasik :)
Tak mě napadá, jak tam hodláš řešit select?
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 15. 03. 2021, 23:15:04
Tak mě napadá, jak tam hodláš řešit select?
Takhle nízko ještě nejsem, zatím mám jenom mlhavou, high-level představu.

Nad tímhle jsou ještě jiná zajímavá rozhodnutí - jestli pojmenovávat kanály nebo procesy, jestli si vystačit s nebufferovanými kanály nebo přidat nějakou kapacitu, jestli kanál pojmout jako frontu nebo mailbox, jestli umožnit selektivní výběr zpráv...

Jestli má jít o srandu na jedno dvě odpoledne, tak to vidím na pojmenované kanály bez kapacity a tímpádem bez selektivního výběru. V takovým jednoduchým případě by select neměl být nic, nad čím by bylo potřeba dumat (?). Prostě z množiny kanálu náhodně vybereš jeden připravený ke čtení. Pokud by tam byl ten run to complete scheduler, tak by select vůbec nemusel být potřeba se mi intuitivně zdá.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 00:02:14
Tak mě napadá, jak tam hodláš řešit select?
Takhle nízko ještě nejsem, zatím mám jenom mlhavou, high-level představu.

Nad tímhle jsou ještě jiná zajímavá rozhodnutí - jestli pojmenovávat kanály nebo procesy, jestli si vystačit s nebufferovanými kanály nebo přidat nějakou kapacitu, jestli kanál pojmout jako frontu nebo mailbox, jestli umožnit selektivní výběr zpráv...

Jestli má jít o srandu na jedno dvě odpoledne, tak to vidím na pojmenované kanály bez kapacity a tímpádem bez selektivního výběru. V takovým jednoduchým případě by select neměl být nic, nad čím by bylo potřeba dumat (?). Prostě z množiny kanálu náhodně vybereš jeden připravený ke čtení. Pokud by tam byl ten run to complete scheduler, tak by select vůbec nemusel být potřeba se mi intuitivně zdá.
Nad tím bufferem jsem taky přemýšlel a klidně bych to vypustil, tj. mít jen blokující kanály na zápis i čtení. Co je důležité (aby to k něčemu bylo) je zavírání kanálů, ani ne tak kvůli čtení ve smyčce, jako spíš signalizaci v kontextu (korutina, která čeká na čtení, se probudí, když se příslušný kanál zavře).
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 16. 03. 2021, 07:24:38
Nad tím bufferem jsem taky přemýšlel a klidně bych to vypustil, tj. mít jen blokující kanály na zápis i čtení. Co je důležité (aby to k něčemu bylo) je zavírání kanálů, ani ne tak kvůli čtení ve smyčce, jako spíš signalizaci v kontextu (korutina, která čeká na čtení, se probudí, když se příslušný kanál zavře).
Já si (po zkušenosti s Elixirem) pořád myslím, že mailbox se selektivním výběrem je daleko mocnější nástroj, ale pro jednoduchou implementaci by nebufferované kanály imho měly stačit.

Bufferovaný kanál by se z nebufferovaného dal udělat, pokud by byla k dispozici operace testu, jestli je kanál prázdný. Pak můžu v případě potřeby ukládat do lokálního bufferu. Nenapadá mě teď případ, ve kterém by to nebylo funkčně ekvivalentní k "nativnímu" bufferu.

Kromě toho, nevybavuju si, že bych se někdy setkal se situací, kde by buffer na kanálu byl nutně potřeba pro korektnost algoritmu a nedalo by se to napsat jinak.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 10:15:00
Nad tím bufferem jsem taky přemýšlel a klidně bych to vypustil, tj. mít jen blokující kanály na zápis i čtení. Co je důležité (aby to k něčemu bylo) je zavírání kanálů, ani ne tak kvůli čtení ve smyčce, jako spíš signalizaci v kontextu (korutina, která čeká na čtení, se probudí, když se příslušný kanál zavře).
Já si (po zkušenosti s Elixirem) pořád myslím, že mailbox se selektivním výběrem je daleko mocnější nástroj, ale pro jednoduchou implementaci by nebufferované kanály imho měly stačit.

Bufferovaný kanál by se z nebufferovaného dal udělat, pokud by byla k dispozici operace testu, jestli je kanál prázdný. Pak můžu v případě potřeby ukládat do lokálního bufferu. Nenapadá mě teď případ, ve kterém by to nebylo funkčně ekvivalentní k "nativnímu" bufferu.

Kromě toho, nevybavuju si, že bych se někdy setkal se situací, kde by buffer na kanálu byl nutně potřeba pro korektnost algoritmu a nedalo by se to napsat jinak.
Mocnější to bude, ale já na to právě koukám stylem “jak mít za málo peněz hodně muziky,” tj. použít nejméně mocné (nejjednodušší) prostředky k dosazení cíle.

Ten “lokální buffer” mě napadl včera, když jsem psal předchozí příspěvek, ale IMHO žádný buffer není vůbec potřeba. Spíš se zaměřuju na zdánlivě nepodstatné, ale veledůležité detaily, třeba to zavírání kanálů, aby šel udělat fan in/out s kontextem apod.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 16. 03. 2021, 13:27:15
Ten “lokální buffer” mě napadl včera, když jsem psal předchozí příspěvek, ale IMHO žádný buffer není vůbec potřeba.
Prisne vzato neni, protoze kanal s konecnou kapacitou ma stejny potencialni dusledky jako kanal s kapacitou 1. Nekdy se proste muze zablokovat. A to je asi tak vsechno :) Jiny by to bylo s kanalem s neohranicenou kapacitou, ale nad tim predpokladam nepremyslis.

Spíš se zaměřuju na zdánlivě nepodstatné, ale veledůležité detaily, třeba to zavírání kanálů, aby šel udělat fan in/out s kontextem apod.
Nejsem si uplne stoprocentne jistej, jestli je zavirani kanalu nutny. Muzes zkusit trochu detailneji popsat, proc si pripadne myslis, ze jo?

Idealni by byl nejakej protipriklad - priklad konkretni situace, ktera bez zavirani kanalu nepujde vyresit.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 13:36:42
Ten “lokální buffer” mě napadl včera, když jsem psal předchozí příspěvek, ale IMHO žádný buffer není vůbec potřeba.
Prisne vzato neni, protoze kanal s konecnou kapacitou ma stejny potencialni dusledky jako kanal s kapacitou 1. Nekdy se proste muze zablokovat. A to je asi tak vsechno :) Jiny by to bylo s kanalem s neohranicenou kapacitou, ale nad tim predpokladam nepremyslis.
Ne, to dost dobře nejde a ani mě teď nenapadá, k čemu by to bylo.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 13:49:10
Nejsem si uplne stoprocentne jistej, jestli je zavirani kanalu nutny. Muzes zkusit trochu detailneji popsat, proc si pripadne myslis, ze jo?

Idealni by byl nejakej protipriklad - priklad konkretni situace, ktera bez zavirani kanalu nepujde vyresit.
Je nutné (pro obecné praktické CSP). Představ se, že chci mít kanál pro rušení operací čtení z nějakého datového kanálu. Tento kanál (říkejme mu třeba “dropdead”) může být použit v mnoha selectech zároveň. Když chci všechny tyto selecty přerušit naráz, nemůžu jen poslat hodnotu, protože tu přečte jen jeden (náhodně vybraný), to je ostatně princip použití kanálů pro load balancing. Proto se to řeší tak, že se tento kanál zavře, pročež se všechny příslušné selecty odblokují a vyskočí se z nich. Všechny implementace CSP, co znám, to takto mají. Nejspíš to ani jinak (bez nárůstu složitosti) nejde. A je to elegantní.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 16. 03. 2021, 14:06:43
Je nutné (pro obecné praktické CSP). Představ se, že chci mít kanál pro rušení operací čtení z nějakého datového kanálu. Tento kanál (říkejme mu třeba “dropdead”) může být použit v mnoha selectech zároveň. Když chci všechny tyto selecty přerušit naráz, nemůžu jen poslat hodnotu, protože tu přečte jen jeden (náhodně vybraný), to je ostatně princip použití kanálů pro load balancing. Proto se to řeší tak, že se tento kanál zavře, pročež se všechny příslušné selecty odblokují a vyskočí se z nich. Všechny implementace CSP, co znám, to takto mají. Nejspíš to ani jinak (bez nárůstu složitosti) nejde. A je to elegantní.
Jasný, prostě context.Context. Nutný to není, dá se to udělat jinak. A dokonce i elegantněji :) V Erlangu jsou to linky (viz spawn_link). To je daleko robustnější řešení, protože nezávisí na kooperaci konsumenta. Mně tohle zavírání kanálů přijde spíš jako jejich zneužití. Z jistého pohledu to elegantní je, z jiného nikoli :)

Shodou okolností jsem přesně na tohle právě teď pěkně nasranej, protože píšu server, který musí obsluhovat net.Conn a zároveň kanály. Právě proto (!), že context.Context funguje přes kanály, není s net.Conn.Read kompatibilní a musí se kolem toho dělat opičky. Nevede to k elegantnímu kódu, ale přesně naopak...
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 14:10:18
Je nutné (pro obecné praktické CSP). Představ se, že chci mít kanál pro rušení operací čtení z nějakého datového kanálu. Tento kanál (říkejme mu třeba “dropdead”) může být použit v mnoha selectech zároveň. Když chci všechny tyto selecty přerušit naráz, nemůžu jen poslat hodnotu, protože tu přečte jen jeden (náhodně vybraný), to je ostatně princip použití kanálů pro load balancing. Proto se to řeší tak, že se tento kanál zavře, pročež se všechny příslušné selecty odblokují a vyskočí se z nich. Všechny implementace CSP, co znám, to takto mají. Nejspíš to ani jinak (bez nárůstu složitosti) nejde. A je to elegantní.
Jasný, prostě context.Context. Nutný to není, dá se to udělat jinak. A dokonce i elegantněji :) V Erlangu jsou to linky (viz spawn_link). To je daleko robustnější řešení, protože nezávisí na kooperaci konsumenta. Mně tohle zavírání kanálů přijde spíš jako jejich zneužití. Z jistého pohledu to elegantní je, z jiného nikoli :)

Shodou okolností jsem přesně na tohle právě teď pěkně nasranej, protože píšu server, který musí obsluhovat net.Conn a zároveň kanály. Právě proto (!), že context.Context funguje přes kanály, není s net.Conn.Read kompatibilní a musí se kolem toho dělat opičky. Nevede to k elegantnímu kódu, ale přesně naopak...
Context není dělaný pro net.Conn. Jistě by to šlo přes síťové kanály, které ovšem zatím nikdo nenapsal (vlastně napsal a pak zahodil, to vyjde nastejno).
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 14:13:18
Mně tohle zavírání kanálů přijde spíš jako jejich zneužití.
Je to využití scheduleru. Pro embedded se mi to nezdá špatné, můžeš si tam sice přidat linky, ale proč, když už to scheduler umí jinak a šetříš každý bajt.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 16. 03. 2021, 14:19:09
Context není dělaný pro net.Conn. Jistě by to šlo přes síťové kanály, které ovšem zatím nikdo nenapsal (vlastně napsal a pak zahodil, to vyjde nastejno).
No prave. To reseni se zaviranim kanalu je elegantni jenom v pripade, ze komunikujes vyhradne pomoci kanalu. Jakmile mas i jiny komunikacni prostredky, tak to neni elegantni, ale haze ti to jenom klacky pod nohy.

Je to využití scheduleru. Pro embedded se mi to nezdá špatné, můžeš si tam sice přidat linky, ale proč, když už to scheduler umí jinak a šetříš každý bajt.
Jasne. Jak rikam, pokud budes mit jenom kanaly a nic jinyho, bude to super.

Anebo by se jeste dalo uvazovat nad tim, ze by kanaly byly zaroven linky. To by asi taky slo, ale bylo by narocnejsi promyslet, jestli by to bylo rozumny za vsech situaci.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 14:29:09
Context není dělaný pro net.Conn. Jistě by to šlo přes síťové kanály, které ovšem zatím nikdo nenapsal (vlastně napsal a pak zahodil, to vyjde nastejno).
No prave. To reseni se zaviranim kanalu je elegantni jenom v pripade, ze komunikujes vyhradne pomoci kanalu. Jakmile mas i jiny komunikacni prostredky, tak to neni elegantni, ale haze ti to jenom klacky pod nohy.

Je to využití scheduleru. Pro embedded se mi to nezdá špatné, můžeš si tam sice přidat linky, ale proč, když už to scheduler umí jinak a šetříš každý bajt.
Jasne. Jak rikam, pokud budes mit jenom kanaly a nic jinyho, bude to super.

Anebo by se jeste dalo uvazovat nad tim, ze by kanaly byly zaroven linky. To by asi taky slo, ale bylo by narocnejsi promyslet, jestli by to bylo rozumny za vsech situaci.
To není o kanálech, ale o tom, že komunikace přelézá určité hranice (síť). V embedded by to taky nešlo použít třeba pro I2C, to bych CSP nezazlíval, prostě se musí použít jiný mechanismus. Musím kouknout, jak to má Rust, tam bývají zajímavá řešení.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 16. 03. 2021, 14:31:41
To není o kanálech, ale o tom, že komunikace přelézá určité hranice (síť). V embedded by to taky nešlo použít třeba pro I2C, to bych CSP nezazlíval, prostě se musí použít jiný mechanismus. Musím kouknout, jak to má Rust, tam bývají zajímavá řešení.
Mozna z hlediska implementace. Ale z hlediska koncepcniho to s tim nema co delat.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 14:44:08
To není o kanálech, ale o tom, že komunikace přelézá určité hranice (síť). V embedded by to taky nešlo použít třeba pro I2C, to bych CSP nezazlíval, prostě se musí použít jiný mechanismus. Musím kouknout, jak to má Rust, tam bývají zajímavá řešení.
Mozna z hlediska implementace. Ale z hlediska koncepcniho to s tim nema co delat.
Tak si to představ tak, že kanály jsou jednoduše základní stavební prvky (něco jako asembler) a nad nimi si můžeš postavit linky. Udělat síťové kanály není tak těžké, když budou mít stejnou sémantiku, můžeš skrýt zavírání kanálů pod vlastní vrstvou vyšší úrovně. Takhle se dříve řešily i jiné věci (distribuované objekty, proxy) a byly s tím problémy (třeba se správou paměti) právě proto, že chtěli udržet jednotnou koncepci nezávislou na implementaci. Je to tradeoff. Osobně upřednostňuju jednodušší věci, žádné rádobyužitečné peudovýmysly v runtimu nechci, složitost patří do compile timu (hezký příklad je Rust, velesložitý překladač s borrow checkerem a výsledný kód je pak triviální). Ale určitě se rád inspiruju tvou inovativní implementací, až ji napíšeš ;)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 15:12:48
aby to "svítilo a hřálo", jak říká klasik :)
Dnes mi dorazilo Pico, hřát asi nebude, ale svítit určitě :) Jdu oprášit ARM32 asembler :)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 16. 03. 2021, 15:41:12
Je to tradeoff.
No dyť. To jsem právě říkal: k tomu net.Conn jsou možná implementační důvody, ale z koncepčního hlediska je ta dvojkolejnost otrava jako prase. A ani z hlediska výkonu to pak není příjemný, když u serveru musíš mít extra goroutinu pro každý spojení jenom proto, aby z net.Conn četla a posílala ti to kanálem. Nebo nemusíš, ale zas to má jiné otravné důsledky...

Dnes mi dorazilo Pico, hřát asi nebude, ale svítit určitě :) Jdu oprášit ARM32 asembler :)
Mně dorazilo v pátek :) Původně jsem ho ani kupovat nechtěl, ale pak jsem podlehl, že si ho aspoň zkusím. Aspoň to PIO bude zajímavý vyzkoušet.

První extra nemilý překvapení bylo, že se to nedá programovat pomocí ST-Linku. Takže doporučuju kupovat nejmíň po dvou kusech a z jednoho si udělat programátor.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 15:49:16
Je to tradeoff.
No dyť. To jsem právě říkal: k tomu net.Conn jsou možná implementační důvody, ale z koncepčního hlediska je ta dvojkolejnost otrava jako prase. A ani z hlediska výkonu to pak není příjemný, když u serveru musíš mít extra goroutinu pro každý spojení jenom proto, aby z net.Conn četla a posílala ti to kanálem. Nebo nemusíš, ale zas to má jiné otravné důsledky...
Tohle neovlivňuje negativně výkon, gorutiny jsou v poolu a hodně levné. A i kdyby ne, u síťové komunikace bys to nepoznal. Jen musíš mít pro ni zásobník, což na serveru nevadí, ale na embedded by mohlo, i když bude malinký.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 15:52:00
Mně dorazilo v pátek :) Původně jsem ho ani kupovat nechtěl, ale pak jsem podlehl, že si ho aspoň zkusím. Aspoň to PIO bude zajímavý vyzkoušet.

První extra nemilý překvapení bylo, že se to nedá programovat pomocí ST-Linku. Takže doporučuju kupovat nejmíň po dvou kusech a z jednoho si udělat programátor.
Jo, mám dvě. Teď nemám moc čas, ale po večerech si budu hrát. Viva assembly :)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 16. 03. 2021, 16:12:25
Tohle neovlivňuje negativně výkon, gorutiny jsou v poolu a hodně levné. A i kdyby ne, u síťové komunikace bys to nepoznal.
No tak pokud by to tak bylo, tak to ma knihovna udelat sama a neprezentovat mi nejaky ujety bufferovy API s ujetym nastavovanim timeoutu :)

https://www.embedded.com/build-a-super-simple-tasker/
Ten clanek je pekne napsany, diky! Akorat teda nevim, proc je ten konec tak ukousnuty :)

Název: Re:CSP v embedded světě
Přispěvatel: Idris 16. 03. 2021, 16:29:35
Tohle neovlivňuje negativně výkon, gorutiny jsou v poolu a hodně levné. A i kdyby ne, u síťové komunikace bys to nepoznal.
No tak pokud by to tak bylo, tak to ma knihovna udelat sama a neprezentovat mi nejaky ujety bufferovy API s ujetym nastavovanim timeoutu :)

https://www.embedded.com/build-a-super-simple-tasker/
Ten clanek je pekne napsany, diky! Akorat teda nevim, proc je ten konec tak ukousnuty :)
To mě vede k dotazu: Preemptivní přepínání tam neplánuješ?
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 16. 03. 2021, 16:45:29
To mě vede k dotazu: Preemptivní přepínání tam neplánuješ?
Ze zacatku urcite nebude potreba, ale jestli pouziju ten nejjednodussi moznej RTC scheduler, tak u nej by to bylo skoro zadarmo, takze kdo vi :)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 17. 03. 2021, 00:33:00
Takze jo, dneska byl pernej den, odreagovat jsem se potreboval, prvni trivialni verze je na svete :) 20B na task a 8B na kanal (to jenom kvuli zarovnani). Takze neco lehce pod tisic tasku na BluePillu :)

Implementaci si zatim necham pro sebe, podelim se jenom o main.

https://gist.github.com/mprymek/d1176be039c8f58e7d3ba4b3b7358e51

Stupidni, ale sviti to a hreje. A vo to go! :)

EDIT: P.S. cely to ma 282 radku :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 17. 03. 2021, 15:35:59
Takze jo, dneska byl pernej den, odreagovat jsem se potreboval, prvni trivialni verze je na svete :) 20B na task a 8B na kanal (to jenom kvuli zarovnani). Takze neco lehce pod tisic tasku na BluePillu :)

Implementaci si zatim necham pro sebe, podelim se jenom o main.

https://gist.github.com/mprymek/d1176be039c8f58e7d3ba4b3b7358e51

Stupidni, ale sviti to a hreje. A vo to go! :)

EDIT: P.S. cely to ma 282 radku :)
Stylem to připomíná GCD.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 17. 03. 2021, 21:10:26
Stylem to připomíná GCD.
:) Vykládám si to jako poctu :)

Nicméně co mi ještě vrtá hlavou, je, jaký datový typ přes ty kanály přenášet. Tady mám (void *), což je docela praktický, páč se tam dá protlačit v případě potřeby integer a za cenu pohlídání si případné alokace i cokoli přes pointer a velikost je předem známá, dá se alokovat staticky.

FreeRTOS má fronty udělaný přes makra tak, že se dá při vytvoření nastavit velikost přenášených dat, což je fajn, ale zas to kód znepřehledňuje. Implicitní kopírování by se mi líbilo víc než přenášení pointerů, ale nevím, jestli to za tu šarádu kolem stojí... Navíc chci kanály vytvářet dynamicky, což by to ještě komplikovalo... Nevím. Asi to nechám tak, jak to je, a doplním to nějakým hezkým alokátorem. Třeba https://github.com/pavel-kirienko/o1heap
Název: Re:CSP v embedded světě
Přispěvatel: Idris 17. 03. 2021, 21:50:08
Stylem to připomíná GCD.
:) Vykládám si to jako poctu :)

Nicméně co mi ještě vrtá hlavou, je, jaký datový typ přes ty kanály přenášet. Tady mám (void *), což je docela praktický, páč se tam dá protlačit v případě potřeby integer a za cenu pohlídání si případné alokace i cokoli přes pointer a velikost je předem známá, dá se alokovat staticky.

FreeRTOS má fronty udělaný přes makra tak, že se dá při vytvoření nastavit velikost přenášených dat, což je fajn, ale zas to kód znepřehledňuje. Implicitní kopírování by se mi líbilo víc než přenášení pointerů, ale nevím, jestli to za tu šarádu kolem stojí... Navíc chci kanály vytvářet dynamicky, což by to ještě komplikovalo... Nevím. Asi to nechám tak, jak to je, a doplním to nějakým hezkým alokátorem. Třeba https://github.com/pavel-kirienko/o1heap
Doporučuju používat objekty jako v CoreFoundation, bude to bezpečnější.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 17. 03. 2021, 22:40:46
Doporučuju používat objekty jako v CoreFoundation, bude to bezpečnější.
Objekty mi do domu nesmí :)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 23. 03. 2021, 23:37:23
Na cem jedete, ja chci taky takovej caj :P
A ještě mi pořád nedošel!

"Migrující tasky" (kind of...) jsou na světě :)

https://youtu.be/GMtUod8J4GA

Zdroják: https://gist.github.com/mprymek/1b93972b71b8d3a59e143819356ea605
Název: Re:CSP v embedded světě
Přispěvatel: Idris 24. 03. 2021, 00:10:41
Na cem jedete, ja chci taky takovej caj :P
A ještě mi pořád nedošel!

"Migrující tasky" (kind of...) jsou na světě :)

https://youtu.be/GMtUod8J4GA

Zdroják: https://gist.github.com/mprymek/1b93972b71b8d3a59e143819356ea605
Hm, tak teď už to GCD nepřipomíná...
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 24. 03. 2021, 00:13:15
Hm, tak teď už to GCD nepřipomíná...
Na API CSP se nic nezměnilo :)

A je tam ten select, co ses na něj ptal. Nakonec jsem ho implementoval jednoduše jako skupinu tasků. Spustí se jenom jeden, ale vymažou se z tabulky všechny.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 24. 03. 2021, 00:52:52
Hm, tak teď už to GCD nepřipomíná...
Na API CSP se nic nezměnilo :)

A je tam ten select, co ses na něj ptal. Nakonec jsem ho implementoval jednoduše jako skupinu tasků. Spustí se jenom jeden, ale vymažou se z tabulky všechny.
Taky správa paměti by šla řešit elegantně, když už tam je tolik struktur, klidně by mohla alokace být transparentní.

Jak se přepíná kontext?
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 24. 03. 2021, 00:58:01
Taky správa paměti by šla řešit elegantně, když už tam je tolik struktur, klidně by mohla alokace být transparentní.
Co je transparentní alokace?

Jak se přepíná kontext?
Je to ten RTC scheduler, tj. kontext se přepne tím, že funkce doběhne. Např. can_blinker_send se spustí po tom, co jsou na kanálu k dispozici data (dostane je v chan_data_t data). Pomocí csp_send() na konci vytváří nový task, který scheduler spustí "někdy příště".
Název: Re:CSP v embedded světě
Přispěvatel: Idris 24. 03. 2021, 22:35:51
Taky správa paměti by šla řešit elegantně, když už tam je tolik struktur, klidně by mohla alokace být transparentní.
Co je transparentní alokace?
Bez explicitního free.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 24. 03. 2021, 22:37:09
Bez explicitního free.
A jak bys to delal v cistym C?
Název: Re:CSP v embedded světě
Přispěvatel: Idris 24. 03. 2021, 22:41:35
Hm, tak teď už to GCD nepřipomíná...
A je tam ten select, co ses na něj ptal.
Jak na to tak koukám, tak pro čisté C by se na embedded hodilo něco jako kqueue — kanály vyžadují extra syntax (nebo hnusné workaroundy).
Název: Re:CSP v embedded světě
Přispěvatel: Idris 24. 03. 2021, 22:45:31
Bez explicitního free.
A jak bys to delal v cistym C?
Jako jiné knihovny v čistém C, použít cleanup a někde bokem si držet informace o strukturách (to kvůli polymorfismu při úklidu). Na embedded bych tedy především nealokoval nic na haldě, ale obecně se používají v sofistikovaných knihovnách právě ukazatele na “typy”. Je to taková vyšší dívčí céčka, třeba CoreFoundation je dobrý příklad.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 24. 03. 2021, 23:07:22
Bez explicitního free.
A jak bys to delal v cistym C?
Už nemůžu upravit tu předchozí odpověď, tak tady jako příklad:
Kód: [Vybrat]
// nějaký kód (vytvoř třeba RSA klíče)
{
autofreed ch = channel_create();
// dej někomu kanál
// hoď klíče do kanálu
}
// kanál byl uvolněn
Takhle se dá psát v čistém C bez explicitních alokací, zrovna na embedded, kde typicky není nějaká velká standardní knihovna, to je dobrý fit. Stačí jedno makro s jedním atributem. Dost teda v GCC chybí bloky (aka uzávěry), ale ty stejně vyžadují runtime, což zabírá místo, což v embedded nemáme rádi :)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 24. 03. 2021, 23:21:10
Tohle ale nejde pouzit (pokud ti spravne rozumim). Alokuje se v jine funkci nez dealokuje.

Kanaly se nealokuji dynamicky, to neni potreba, ty jsou alokovane staticky. Dynamicky se alokuji zpravy - prave proto, ze je potreba je na jednom miste vytvorit a na jinem pouzit. Pokud bych se moc chtel te dynamicke alokaci vyhnout, stacilo by pouzit doublebuffer (protoze kanal ma kapacitu 1). Neudelal jsem to zamerne, protoze jsem chtel, aby informace proudily striktne ve smeru channelu, ne nejakym postrannim "neviditelnym" kanalem opacne.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 24. 03. 2021, 23:23:43
Tohle ale nejde pouzit (pokud ti spravne rozumim). Alokuje se v jine funkci nez dealokuje.
Jde to použít, když si někde držíš RC (jako třeba Rust). Případně si můžeš implementovat move, ale to už je vyšší vyšší dívčí.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 24. 03. 2021, 23:28:04
Kanaly se nealokuji dynamicky, to neni potreba, ty jsou alokovane staticky. Dynamicky se alokuji zpravy - prave proto, ze je potreba je na jednom miste vytvorit a na jinem pouzit. Pokud bych se moc chtel te dynamicke alokaci vyhnout, stacilo by pouzit doublebuffer (protoze kanal ma kapacitu 1). Neudelal jsem to zamerne, protoze jsem chtel, aby informace proudily striktne ve smeru channelu, ne nejakym postrannim "neviditelnym" kanalem opacne.
To byl jen příklad. Zrovna u těch zpráv to dává ještě větší smysl. Teď už se bavíme o detailech, ale pro někoho, kdo si s Picem jen hraje a jinak moc vývojář není, to může být docela velký rozdíl. A v produkci je to bezpečnější.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 24. 03. 2021, 23:34:04
ale pro někoho, kdo si s Picem jen hraje a jinak moc vývojář není, to může být docela velký rozdíl
Abysme si rozumeli: nesnazim se udelat to "Arduino done right". Chci udelat demo CSP na MCU. Neni to urceno lamam a jelikoz se alokuje na jednom jasne danem miste, dealokuje na jinem jasne danem miste a oboje je z definice synchronizovany, nedava mi smysl tam vymyslet jekykoli vyfikundance, ktery by kod jenom nesmyslne komplikovaly.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 24. 03. 2021, 23:53:43
Neni to urceno lamam
To je důležitá informace ;D A co alpaky?
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 25. 03. 2021, 00:09:17
To je důležitá informace ;D A co alpaky?
Zadne z techto: https://www.youtube.com/watch?v=Fx4eqvMGv0U :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 25. 03. 2021, 00:33:34
To je důležitá informace ;D A co alpaky?
Zadne z techto: https://www.youtube.com/watch?v=Fx4eqvMGv0U :)
Vikuně jsou pěkný potvory, se nedá spočítat, kolikrát jsem kvůli nim na Altiplanu brzdil. Guanako je o dost inteligentnější a pod kola neskáče.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 09:51:27
Implementoval jsem na Picu obecné korutiny (fibers), kdyby to někoho zajímalo, můžu ukázat kód (jádro je z nutnosti v asembleru) a vysvětlit. Nad tím už je jednoduché implementovat kanály a podobné zajímavé věci.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 09:52:25
Super! Kód určitě ukaž.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 11:05:33

Ještě mi bude chvilku trvat, než doplním chybějící věci, ale přepínání kontextu už šlape, to je ostatně to nejhorší (protože asm). Korutina:
Kód: [Vybrat]
struct fibre_info {
    void* stack;
    void* stackpos;
    void* retaddr;
};
Spuštění korutiny:
Kód: [Vybrat]
__attribute__((naked)) void detach_fibre_asm(struct fibre_info*, void(*)(void*), void* stack, void* arg) {
    asm(
    "push {r4,r5,r6,r7}\n\t"
    "mov r4, r8\n\t"
    "mov r5, r9\n\t"
    "mov r6, r10\n\t"
    "mov r7, r11\n\t"
    "push {r4,r5,r6,r7}\n\t"
    "mov r4, sp\n\t"
    "str r4, [r0, #4]\n\t"
    "mov r4, lr\n\t"
    "str r4, [r0, #8]\n\t"
    "mov sp, r2\n\t"
    "mov r0, r3\n\t"
    "bx r1"
    );
}
Celkem primitivní, prostě se uloží kontext a přepne stav. Aby to jelo na Cortex-M0 (Pico), musí se šaškovat s registry od r8 nahoru, ale to jsou detaily. Scheduler už naštěstí bude v céčku. Použití:
Kód: [Vybrat]
void fibre(pico_channel_t ch) {
  pico_sleep_ms(1000);
  pico_send(ch, pico_create_string("Bonjour, monde!"));
}

void main() {
  auto ch = pico_create_channel();
  pico_detach(&fibre, ch);
  auto str = pico_receive(ch);
  // do something with str
}
Funkce sleep, send a receive přepínají korutiny, tj. neblokují, ale prostě vrátí řízení scheduleru.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 11:51:32
Ta francouzština je tam příšerná, ten kód ani nemá cenu číst ;)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 12:01:47
Ta francouzština je tam příšerná, ten kód ani nemá cenu číst ;)
Jaká? Předpokládám, že ti zcela uniká rozdíl mezi britskou a americkou angličtinou. Udělals ze sebe debila ;) Au revoir.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 12:08:02
Jaká? Předpokládám, že ti zcela uniká rozdíl mezi britskou a americkou angličtinou. Udělals ze sebe debila ;) Au revoir.
"Bonjour, monde!" je britska nebo americka anglictina?

--
Hele, ale vazne: jakej smysl ma implementovat stackful coroutiny? To uz muzu rovnou pouzit FreeRTOS a budu mit batteries included, ne?
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 12:08:49
"Bonjour, monde!" je britska nebo americka anglictina?
Kanadská  :P
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 12:13:48
Kanadská  :P
V Kanadě se nepoužívají členy?
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 12:15:21
Hele, ale vazne: jakej smysl ma implementovat stackful coroutiny? To uz muzu rovnou pouzit FreeRTOS a budu mit batteries included, ne?
Kolik místa zabere FreeRTOS? Když chci jen CSP a nic dalšího, tak to IMHO smysl má, ale záleží případ od případu. Navíc to je spíš jen for fun (aby to bylo aspoň trochu reálně použitelné, muselo by se pár věcí dopsat/přepsat), na malinkých MCU už jen malloc je na pováženou. Největší smysl je asi didaktický, jak se dělají korutiny (stejné by to bylo i na jiných procesorech) a jak CSP a podobné divnosti.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 12:18:21
Kanadská  :P
V Kanadě se nepoužívají členy?
Imigranti z východní Evropy cpou členy všude a říkají "le bonjour, le monde", proto se na ně všichni koukají spatra.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 12:23:26
Kolik místa zabere FreeRTOS? Když chci jen CSP a nic dalšího, tak to IMHO smysl má, ale záleží případ od případu.
Tak FreeRTOS není nic jinýho než funkce, takže záleží, co všechno používáš. Myslím, že když to naimplementuješ rozumně, tak se dostaneš na velmi podobnej objem jako má FreeRTOS, není tam myslím žádnej zásadní důvod, proč by FreeRTOS (nebo jakejkoliv jinej RTOS) měl být třeba řádově větší. Něco samozřejmě s tím RTOSem sežerou abstrakce, ale neočekával bych, že to bude nějak zásadně moc. Ale je to jenom odhad, muselo by se to zkusit (pro Pico myslím ještě FreeRTOS není, ale můžeš si to zkusit třeba pro ten Blue Pill).
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 12:24:16
Imigranti z východní Evropy cpou členy všude a říkají "le bonjour, le monde", proto se na ně všichni koukají spatra.
To jsem nevěděl, že deník Le Monde vedou imigranti z východní Evropy :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 12:27:34
Imigranti z východní Evropy cpou členy všude a říkají "le bonjour, le monde", proto se na ně všichni koukají spatra.
To jsem nevěděl, že deník Le Monde vedou imigranti z východní Evropy :)
Nevíš, co je vokativ? Píšeš v kódu "hello, the world"? Už se neztrapňuj.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 12:32:25
Nevíš, co je vokativ? Píšeš v kódu "hello, the world"? Už se neztrapňuj.
Francouzsky neumím, ale stačí mi tu frázi zadat do googlu s a bez členu :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 12:35:18
pro Pico myslím ještě FreeRTOS není
To brzo doženou. Jak píšu, je to prostě for fun, nicméně ta nadstavba nad tím (CSP, (polo)automatická správa paměti apod.) může mít i praktický význam. Momentálně se věnuju úplně jiným věcem, které by byly na Rootu off topic (nebo off scale). Jak už bylo řečeno, scheduler a korutiny jsou technikálie, jde o CSP. Zrovna to "síťové" (tady spíš přes I2C/UART) by ještě stálo za to.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 12:43:32
To brzo doženou.
Urcite, bude to jenom lehky poladeni nejakyho jinyho portu.

nicméně ta nadstavba nad tím (CSP, (polo)automatická správa paměti apod.) může mít i praktický význam.
CSP na FreeRTOSu implicitne je, protoze jsou tam fronty.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 12:57:04
To brzo doženou.
Urcite, bude to jenom lehky poladeni nejakyho jinyho portu.

nicméně ta nadstavba nad tím (CSP, (polo)automatická správa paměti apod.) může mít i praktický význam.
CSP na FreeRTOSu implicitne je, protoze jsou tam fronty.
Jediná věc, co mě teď napadá, že by byla přínosná, je zprovoznění bloků na MCU (a udělání nějakého GCD light).
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 13:06:47
Jediná věc, co mě teď napadá, že by byla přínosná, je zprovoznění bloků na MCU (a udělání nějakého GCD light).
To by možná pro nováčky nějakej smysl mít mohlo, ale mě to vůbec nezajímá.

Mně šlo o tohle:

Zprovoznit stackless tasky (protože na malých MCUs můžeš mít stackful tasků jenom pár) => demonstrovat stovky tasků i na malým MCU => ukázat, že "CSP stylem" se dají věci řešit úplně jinak a že to je možný použít i na malým MCU

Tohle podle mě má smysl, protože mám dojem, že když se v embedded světě mluví o tascích, myslí se tím automaticky stackful tasky a RTOS. A na opačné straně jsou lightweight tasky ala https://github.com/joysfera/arduino-tasker který ale imho nikdo nebere moc vážně. Takže mým cílem bylo střelit doprostřed mezi tyhle dvě věci a ukázat, že stackless tasky + kanály přináší zajímavé nové možnosti přístupu ke strukturování kódu.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 13:15:57
Jediná věc, co mě teď napadá, že by byla přínosná, je zprovoznění bloků na MCU (a udělání nějakého GCD light).
To by možná pro nováčky nějakej smysl mít mohlo, ale mě to vůbec nezajímá.
Proč pro nováčky? To by naopak byla hodně užitečná věc i v profi oblasti, tím spíš, že příslušný kód je dokonale odladěný a vyzkoušený. Co si pamatuju, runtime je hodně malý, ale na současný stav se musím podívat. GCD je právě stackless (BTW stackless není lepší než stackful, GCD jen prostě funguje úplně jinak).
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 13:32:49
Proč pro nováčky? To by naopak byla hodně užitečná věc i v profi oblasti, tím spíš, že příslušný kód je dokonale odladěný a vyzkoušený. Co si pamatuju, runtime je hodně malý, ale na současný stav se musím podívat. GCD je právě stackless (BTW stackless není lepší než stackful, GCD jen prostě funguje úplně jinak).
Reagoval jsem na ty bloky, ne na GCD.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 13:38:40
Proč pro nováčky? To by naopak byla hodně užitečná věc i v profi oblasti, tím spíš, že příslušný kód je dokonale odladěný a vyzkoušený. Co si pamatuju, runtime je hodně malý, ale na současný stav se musím podívat. GCD je právě stackless (BTW stackless není lepší než stackful, GCD jen prostě funguje úplně jinak).
Reagoval jsem na ty bloky, ne na GCD.
Ty bloky je nedílnou součástí GCD (téměř nedílnou, nepodstatné detaily vynechme).
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 14:14:28
Zprovoznit stackless tasky [...] demonstrovat stovky tasků i na malým MCU
To je fajn, a už jsem zprovoznil blocksruntime pro Pico, čili proof of concept je hotov (a co si budeme povídat, použití bloků je bezpečnější a čitelnější).
Název: Re:CSP v embedded světě
Přispěvatel: BoneFlute 26. 03. 2021, 15:01:56
Imigranti z východní Evropy cpou členy všude a říkají "le bonjour, le monde", proto se na ně všichni koukají spatra.
To jsem nevěděl, že deník Le Monde vedou imigranti z východní Evropy :)
Nevíš, co je vokativ? Píšeš v kódu "hello, the world"? Už se neztrapňuj.
Ve francouzštině fungují členy jinak než v angličtině. Zdravíš tento svět, ne nějaký libovolný, takže tam ten člen bude. Členy se nedávají u speciálů jako profese a tak.

Každopádně je úsměvný, jak se tu schizofreně až sprostě častujete a zároveň se věcně bavíte o technice :-)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 15:09:03
Ve francouzštině fungují členy jinak než v angličtině. Zdravíš tento svět, ne nějaký libovolný, takže tam ten člen bude. Členy se nedávají u speciálů jako profese a tak.
Ano, fungují jinak, ale v tomto případě tam člen nemusí být. André Geerts, rodilý mluvčí, tak nazval svou knihu a ani na svou mateřštinu extrémně hákliví Francouzi mu ji o hlavu neomlátili. Napadá tě jiné vysvětlení, než že to je prostě gramaticky správně?

P.S. Něco k tématu by nebylo?
Název: Re:CSP v embedded světě
Přispěvatel: BoneFlute 26. 03. 2021, 15:31:02
Ve francouzštině fungují členy jinak než v angličtině. Zdravíš tento svět, ne nějaký libovolný, takže tam ten člen bude. Členy se nedávají u speciálů jako profese a tak.
Ano, fungují jinak, ale v tomto případě tam člen nemusí být. André Geerts, rodilý mluvčí, tak nazval svou knihu a ani na svou mateřštinu extrémně hákliví Francouzi mu ji o hlavu neomlátili. Napadá tě jiné vysvětlení, než že to je prostě gramaticky správně?
Napadá mě jedině to, že budeš mít asi pravdu. Každopádně díky za příklad.

P.S. Něco k tématu by nebylo?
Za mě ne. Já embedded nedělám, horko těžko se chytám, ale je to inspirativní čtení. Díky.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 15:36:30
Napadá tě jiné vysvětlení, než že to je prostě gramaticky správně?
Napadá mě jedině to, že budeš mít asi pravdu. Každopádně díky za příklad.
Není zač. Moje francouzština je, na rozdíl od angličtiny, dost bídná (pod dvaceti letech nepoužívání), takže se nemůžu moc vyjadřovat k nuancím, ale když to rodilí mluvčí používají, tak bych jim věřil. Ale je fajn, že si aspoň nepleteš vokativ a použití jmenné fráze v názvu periodika jako MP :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 15:39:12
Za mě ne. Já embedded nedělám, horko těžko se chytám, ale je to inspirativní čtení. Díky.
Ono to už sklouzlo k obecnému CSP a věcem kolem (korutiny, GCD). Drž mi palce, ať konečně zvítězím na clangem ;)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 16:24:52
Clang si (oproti očekávání) s Picem celkem rozumí, takže kdo nechce stackful korutiny, stejně elegantně může mít kanály takto:
Kód: [Vybrat]
auto ch = channel_create();
dispatch_async(^{
  sleep_ms(1000);
  channel_send(ch, ...);
});
auto x = channel_receive(ch);
Vyjde to skoro nastejno, ale bez zbytečného zásobníku.
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 17:09:33
Napadá mě jedině to, že budeš mít asi pravdu. Každopádně díky za příklad.
Mě teda napadá

1. že ji tak NEnazval :) Pokud je teda řeč o "Monde cruel"

2. že jedno album od Plastiků se jmenuje Vožralej jak slíva a nijak z toho neplyne, že "vožralej" je spisovně česky správně a kdybych to napsal do zdrojáku, neznělo by to jako špatná čeština

Každopádně je úsměvný, jak se tu schizofreně až sprostě častujete a zároveň se věcně bavíte o technice :-)
Nevím, jak to má Idris, ale z mé strany je to popichování s úsměvem, mám z toho prču, není v tom sebemenší zlej úmysl :)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 17:12:52
Ale je fajn, že si aspoň nepleteš vokativ a použití jmenné fráze v názvu periodika jako MP :)
Ale pane kolego, zase argumentační klam?! Nikdo si tady přece tohle nepletl :)

Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 17:26:20
Nikdo si tady přece tohle nepletl :)
Neříkej si “nikdo”, na to má copyright Terence Hill od raných 70. let (podle tebe “ranných”) :)

A teď k tématu?
Název: Re:CSP v embedded světě
Přispěvatel: Idris 26. 03. 2021, 18:10:58
BTW co ta intuicionistická logika, nějaký pokrok? Jsem si teď vzpomněl :)
Název: Re:CSP v embedded světě
Přispěvatel: Mirek Prýmek 26. 03. 2021, 18:55:04
Neříkej si “nikdo”
Úroveň vtipů silně upadá, tohle je tak čtvrtá třída ZŠ :)
Název: Re:CSP v embedded světě
Přispěvatel: BoneFlute 27. 03. 2021, 15:15:10
BTW co ta intuicionistická logika, nějaký pokrok? Jsem si teď vzpomněl :)

Zatím u ledu. V knihovně to neměli a pak jsem byl převálcován prioritami :-)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 27. 03. 2021, 17:44:20
BTW co ta intuicionistická logika, nějaký pokrok? Jsem si teď vzpomněl :)
Zatím u ledu. V knihovně to neměli a pak jsem byl převálcován prioritami :-)
To znám :) BTW ta kniha od Sitnikovského je zdá se ke stažení zdarma (zahlédl jsem ji někde na Research gate), kdyby tě to zajímalo.
Název: Re:CSP v embedded světě
Přispěvatel: BoneFlute 27. 03. 2021, 22:33:15
BTW co ta intuicionistická logika, nějaký pokrok? Jsem si teď vzpomněl :)
Zatím u ledu. V knihovně to neměli a pak jsem byl převálcován prioritami :-)
To znám :) BTW ta kniha od Sitnikovského je zdá se ke stažení zdarma (zahlédl jsem ji někde na Research gate), kdyby tě to zajímalo.
Tenhle https://bor0.wordpress.com/ ?
Název: Re:CSP v embedded světě
Přispěvatel: Idris 27. 03. 2021, 23:09:04
BTW co ta intuicionistická logika, nějaký pokrok? Jsem si teď vzpomněl :)
Zatím u ledu. V knihovně to neměli a pak jsem byl převálcován prioritami :-)
To znám :) BTW ta kniha od Sitnikovského je zdá se ke stažení zdarma (zahlédl jsem ji někde na Research gate), kdyby tě to zajímalo.
Tenhle https://bor0.wordpress.com/ ?
Ano. Ta kniha o "dependent types" byla na Leanpubu za nějaké drobné, ale teď se dá legálně stáhnout. Je dost stručná, ale základní věci tam vysvětluje celkem pěkně.
Název: Re:CSP v embedded světě
Přispěvatel: BoneFlute 27. 03. 2021, 23:14:52
BTW co ta intuicionistická logika, nějaký pokrok? Jsem si teď vzpomněl :)
Zatím u ledu. V knihovně to neměli a pak jsem byl převálcován prioritami :-)
To znám :) BTW ta kniha od Sitnikovského je zdá se ke stažení zdarma (zahlédl jsem ji někde na Research gate), kdyby tě to zajímalo.
Tenhle https://bor0.wordpress.com/ ?
Ano. Ta kniha o "dependent types" byla na Leanpubu za nějaké drobné, ale teď se dá legálně stáhnout. Je dost stručná, ale základní věci tam vysvětluje celkem pěkně.

https://github.com/bor0/gidti

Jsi pěknej prevít ti povím. Pochop. Nemám čas, jasný? Musím taky někdy spát.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 27. 03. 2021, 23:17:01
BTW co ta intuicionistická logika, nějaký pokrok? Jsem si teď vzpomněl :)
Zatím u ledu. V knihovně to neměli a pak jsem byl převálcován prioritami :-)
To znám :) BTW ta kniha od Sitnikovského je zdá se ke stažení zdarma (zahlédl jsem ji někde na Research gate), kdyby tě to zajímalo.
Tenhle https://bor0.wordpress.com/ ?
Ano. Ta kniha o "dependent types" byla na Leanpubu za nějaké drobné, ale teď se dá legálně stáhnout. Je dost stručná, ale základní věci tam vysvětluje celkem pěkně.

https://github.com/bor0/gidti

Jsi pěknej prevít ti povím. Pochop. Nemám čas, jasný? Musím taky někdy spát.
Kdo ti brání? :)
Název: Re:CSP v embedded světě
Přispěvatel: Idris 30. 03. 2021, 01:07:21
Jestli si chceš trochu pohrát s prapůvodní teorií typů, tady je zdá se implementace: https://simpl-eval.netlify.app
Příslušný článek je nějakým nedopatřením taky volně ke stažení: https://www.semanticscholar.org/paper/A-Formulation-of-the-Simple-Theory-of-Types-Church/28bf123690205ae5bbd9f8c84b1330025e8476e4
Tohle není přímo intuicionistická logika, ale "simple type theory, also known as higher-order logic".
Název: Re:CSP v embedded světě
Přispěvatel: BoneFlute 30. 03. 2021, 23:33:42
Jestli si chceš trochu pohrát s prapůvodní teorií typů, tady je zdá se implementace: https://simpl-eval.netlify.app
Příslušný článek je nějakým nedopatřením taky volně ke stažení: https://www.semanticscholar.org/paper/A-Formulation-of-the-Simple-Theory-of-Types-Church/28bf123690205ae5bbd9f8c84b1330025e8476e4
Tohle není přímo intuicionistická logika, ale "simple type theory, also known as higher-order logic".

Díky za zdroje. Ještě jsem ani nezpracoval ta původní.

Každopádně můj fokus je momentálně na tomto: https://amulet.works/

Slibuje to hodně. A já si od toho slibuju, kromě praktického užití (mám projekt v lue, lua mi vyhovuje svou minimaličností a rychlostí, nevyhovuje mi tím, že nemá typy), taky to, že si v praxi ošahám, k čemu jsou konkrétní koncepty. Například tomu forall jsem ještě furt nepřišel nachuť (ne že bych se tak moc snažil).

Když by si se nudil a napadl tě nějaký pěkný demonstrativní příkládek, zlobit se nebudu.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 31. 03. 2021, 00:07:04
Každopádně můj fokus je momentálně na tomto: https://amulet.works/
To vypadá celkem zajímavě.
Když by si se nudil a napadl tě nějaký pěkný demonstrativní příkládek, zlobit se nebudu.
Příklad čeho? Určitě není problém, jen to pls upřesni.
Název: Re:CSP v embedded světě
Přispěvatel: BoneFlute 31. 03. 2021, 01:28:23
Každopádně můj fokus je momentálně na tomto: https://amulet.works/
To vypadá celkem zajímavě.
Když by si se nudil a napadl tě nějaký pěkný demonstrativní příkládek, zlobit se nebudu.
Příklad čeho? Určitě není problém, jen to pls upřesni.
forall patří do skupiny kvantifikačních typů. Takové to každý, žádný. Potuď mi teorie ok. Ale zatím mi nedochází, k čemu v praxi to může být dobré? Myslím tím nějaký vulgární praktický příklad.

Příklad s monádama: Monáda Maybe je dobrá k tomu, když chceš vrátit hodnotu nebo chybu. Užitek: Maybe je generická. Tudíž nemusíš řešit NullObject pro každý svůj vlastní typ. Díky tomu, že je to generické, můžeš udělat takovou tu věc (neznám názvosloví), kdy řadíš Maybe za sebou a nemusíš řešit rozbalení, zabalení. Máš to otypováné, tudíž se ti nemůže stát, že ti uteče nějaká větev programu, protože ty nemůžeš hned pracovat s tou hodnotou, ale musíš ji nejdřív vybalit... A podle signatury hned poznám, zda mi to vrací číslo, či číslo nebo chybu. A tak.

Jiný příklad s třídama. Třídy nedefinují typ, ale povinnost mít správnou funkci, funkce. A tím mi to rozvazuje ruce, že já nemusím řešit co je to za objekt, jeho strukturu, nedejbože jméno, ale má implementované ty funkce? To mi stačí, stejně víc nepotřebuju.

A prostě by se mi líbil nějaký příkládek pro forall. Abych věděl, že "jo ahaá, takže já si tenhle kousek kódu můžu zjednodušit na..."
Název: Re:CSP v embedded světě
Přispěvatel: Idris 31. 03. 2021, 02:19:51
Každopádně můj fokus je momentálně na tomto: https://amulet.works/
To vypadá celkem zajímavě.
Když by si se nudil a napadl tě nějaký pěkný demonstrativní příkládek, zlobit se nebudu.
Příklad čeho? Určitě není problém, jen to pls upřesni.
forall patří do skupiny kvantifikačních typů. Takové to každý, žádný. Potuď mi teorie ok. Ale zatím mi nedochází, k čemu v praxi to může být dobré? Myslím tím nějaký vulgární praktický příklad.

Příklad s monádama: Monáda Maybe je dobrá k tomu, když chceš vrátit hodnotu nebo chybu. Užitek: Maybe je generická. Tudíž nemusíš řešit NullObject pro každý svůj vlastní typ. Díky tomu, že je to generické, můžeš udělat takovou tu věc (neznám názvosloví), kdy řadíš Maybe za sebou a nemusíš řešit rozbalení, zabalení. Máš to otypováné, tudíž se ti nemůže stát, že ti uteče nějaká větev programu, protože ty nemůžeš hned pracovat s tou hodnotou, ale musíš ji nejdřív vybalit... A podle signatury hned poznám, zda mi to vrací číslo, či číslo nebo chybu. A tak.

Jiný příklad s třídama. Třídy nedefinují typ, ale povinnost mít správnou funkci, funkce. A tím mi to rozvazuje ruce, že já nemusím řešit co je to za objekt, jeho strukturu, nedejbože jméno, ale má implementované ty funkce? To mi stačí, stejně víc nepotřebuju.

A prostě by se mi líbil nějaký příkládek pro forall. Abych věděl, že "jo ahaá, takže já si tenhle kousek kódu můžu zjednodušit na..."
Haskell má několik rozšíření, přičemž v každém znamená forall něco trochu jiného. IMHO nejpraktičtější je jeho použití v existenčních typech, například:
Kód: [Vybrat]
data Explosive = forall x. Exploder x => Expl xTímto způsobem se dá zbavit explicitního typového parametru, takže pak můžu mít seznam typu [Explosive], třeba [Expl Landmine, Expl Torpedo, Expl Turkey].
Název: Re:CSP v embedded světě
Přispěvatel: BoneFlute 31. 03. 2021, 02:37:29
Každopádně můj fokus je momentálně na tomto: https://amulet.works/
To vypadá celkem zajímavě.
Když by si se nudil a napadl tě nějaký pěkný demonstrativní příkládek, zlobit se nebudu.
Příklad čeho? Určitě není problém, jen to pls upřesni.
forall patří do skupiny kvantifikačních typů. Takové to každý, žádný. Potuď mi teorie ok. Ale zatím mi nedochází, k čemu v praxi to může být dobré? Myslím tím nějaký vulgární praktický příklad.

Příklad s monádama: Monáda Maybe je dobrá k tomu, když chceš vrátit hodnotu nebo chybu. Užitek: Maybe je generická. Tudíž nemusíš řešit NullObject pro každý svůj vlastní typ. Díky tomu, že je to generické, můžeš udělat takovou tu věc (neznám názvosloví), kdy řadíš Maybe za sebou a nemusíš řešit rozbalení, zabalení. Máš to otypováné, tudíž se ti nemůže stát, že ti uteče nějaká větev programu, protože ty nemůžeš hned pracovat s tou hodnotou, ale musíš ji nejdřív vybalit... A podle signatury hned poznám, zda mi to vrací číslo, či číslo nebo chybu. A tak.

Jiný příklad s třídama. Třídy nedefinují typ, ale povinnost mít správnou funkci, funkce. A tím mi to rozvazuje ruce, že já nemusím řešit co je to za objekt, jeho strukturu, nedejbože jméno, ale má implementované ty funkce? To mi stačí, stejně víc nepotřebuju.

A prostě by se mi líbil nějaký příkládek pro forall. Abych věděl, že "jo ahaá, takže já si tenhle kousek kódu můžu zjednodušit na..."
Haskell má několik rozšíření, přičemž v každém znamená forall něco trochu jiného. IMHO nejpraktičtější je jeho použití v existenčních typech, například:
Kód: [Vybrat]
data Explosive = forall x. Exploder x => Expl xTímto způsobem se dá zbavit explicitního typového parametru, takže pak můžu mít seznam typu [Explosive], třeba [Expl Landmine, Expl Torpedo, Expl Turkey].

Co značí to Exploder?

Takže analogicky:
Kód: [Vybrat]
data Err = forall x. Maybe x => Just x
apply :: [Err] -> String
apply xs = ...
apply [Just "text", Just 42, Just True]
?

Přidám otázku: Dokážeš popsat tu ideu existenčních typů?
Název: Re:CSP v embedded světě
Přispěvatel: Idris 31. 03. 2021, 11:09:05
Každopádně můj fokus je momentálně na tomto: https://amulet.works/
To vypadá celkem zajímavě.
Když by si se nudil a napadl tě nějaký pěkný demonstrativní příkládek, zlobit se nebudu.
Příklad čeho? Určitě není problém, jen to pls upřesni.
forall patří do skupiny kvantifikačních typů. Takové to každý, žádný. Potuď mi teorie ok. Ale zatím mi nedochází, k čemu v praxi to může být dobré? Myslím tím nějaký vulgární praktický příklad.

Příklad s monádama: Monáda Maybe je dobrá k tomu, když chceš vrátit hodnotu nebo chybu. Užitek: Maybe je generická. Tudíž nemusíš řešit NullObject pro každý svůj vlastní typ. Díky tomu, že je to generické, můžeš udělat takovou tu věc (neznám názvosloví), kdy řadíš Maybe za sebou a nemusíš řešit rozbalení, zabalení. Máš to otypováné, tudíž se ti nemůže stát, že ti uteče nějaká větev programu, protože ty nemůžeš hned pracovat s tou hodnotou, ale musíš ji nejdřív vybalit... A podle signatury hned poznám, zda mi to vrací číslo, či číslo nebo chybu. A tak.

Jiný příklad s třídama. Třídy nedefinují typ, ale povinnost mít správnou funkci, funkce. A tím mi to rozvazuje ruce, že já nemusím řešit co je to za objekt, jeho strukturu, nedejbože jméno, ale má implementované ty funkce? To mi stačí, stejně víc nepotřebuju.

A prostě by se mi líbil nějaký příkládek pro forall. Abych věděl, že "jo ahaá, takže já si tenhle kousek kódu můžu zjednodušit na..."
Haskell má několik rozšíření, přičemž v každém znamená forall něco trochu jiného. IMHO nejpraktičtější je jeho použití v existenčních typech, například:
Kód: [Vybrat]
data Explosive = forall x. Exploder x => Expl xTímto způsobem se dá zbavit explicitního typového parametru, takže pak můžu mít seznam typu [Explosive], třeba [Expl Landmine, Expl Torpedo, Expl Turkey].
Co značí to Exploder?

Takže analogicky:
Kód: [Vybrat]
data Err = forall x. Maybe x => Just x
apply :: [Err] -> String
apply xs = ...
apply [Just "text", Just 42, Just True]
?

Přidám otázku: Dokážeš popsat tu ideu existenčních typů?
Exploder je nějaká třída, třeba s funkcemi explode a defuse. Ve svém příkladu akorát dosaď za Maybe nějakou třídu (a Just bych přejmenoval na nějaký unikátní konstruktor hodnot), pak to bude přesně ono.

Když máš v definici typu na pravé straně proměnnou, musí se vyskytovat i na levé straně (tím se deklaruje). Myšlenka ex. typů je, že se typová proměnná vyskytuje pouze napravo. Proto se někdy operátoru forall říká "type hider". Není třeba v tom hledat nic složitého, je to jednoduchý koncept, jen asi neintuitivně nazvaný.
Název: Re:CSP v embedded světě
Přispěvatel: okalousek 31. 03. 2021, 11:39:08
Jestli si chceš trochu pohrát s prapůvodní teorií typů, tady je zdá se implementace: https://simpl-eval.netlify.app
Příslušný článek je nějakým nedopatřením taky volně ke stažení: https://www.semanticscholar.org/paper/A-Formulation-of-the-Simple-Theory-of-Types-Church/28bf123690205ae5bbd9f8c84b1330025e8476e4
Tohle není přímo intuicionistická logika, ale "simple type theory, also known as higher-order logic".

Díky za zdroje. Ještě jsem ani nezpracoval ta původní.

Každopádně můj fokus je momentálně na tomto: https://amulet.works/

Slibuje to hodně. A já si od toho slibuju, kromě praktického užití (mám projekt v lue, lua mi vyhovuje svou minimaličností a rychlostí, nevyhovuje mi tím, že nemá typy), taky to, že si v praxi ošahám, k čemu jsou konkrétní koncepty. Například tomu forall jsem ještě furt nepřišel nachuť (ne že bych se tak moc snažil).

Když by si se nudil a napadl tě nějaký pěkný demonstrativní příkládek, zlobit se nebudu.
Tak z ML světa bych vzal Rust, díky jeho praktičnosti a k tématu - hodí se na embedded.
Název: Re:CSP v embedded světě
Přispěvatel: Idris 01. 04. 2021, 11:31:08
Jestli si chceš trochu pohrát s prapůvodní teorií typů, tady je zdá se implementace: https://simpl-eval.netlify.app
Příslušný článek je nějakým nedopatřením taky volně ke stažení: https://www.semanticscholar.org/paper/A-Formulation-of-the-Simple-Theory-of-Types-Church/28bf123690205ae5bbd9f8c84b1330025e8476e4
Tohle není přímo intuicionistická logika, ale "simple type theory, also known as higher-order logic".

Díky za zdroje. Ještě jsem ani nezpracoval ta původní.

Každopádně můj fokus je momentálně na tomto: https://amulet.works/

Slibuje to hodně. A já si od toho slibuju, kromě praktického užití (mám projekt v lue, lua mi vyhovuje svou minimaličností a rychlostí, nevyhovuje mi tím, že nemá typy), taky to, že si v praxi ošahám, k čemu jsou konkrétní koncepty. Například tomu forall jsem ještě furt nepřišel nachuť (ne že bych se tak moc snažil).

Když by si se nudil a napadl tě nějaký pěkný demonstrativní příkládek, zlobit se nebudu.
Tak z ML světa bych vzal Rust, díky jeho praktičnosti a k tématu - hodí se na embedded.
Rust má forall?