781
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
782
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 16:01:56 »konkrétně u téhle věci prostě nechápu, proč šli touhle cestou.
Bylo by možné, mě by to moc zajímalo, nějak pěkně rozvést výhody a nevýhody await/async?
(Jako Haskellista nemám problém s Promise. Ale jako začínající C#pista, jsem se této syntax zatím úspěšně vyhejbal - ačkoliv věřím, že to nebude nic složitého.)
783
/dev/null / Re:Těžké OOP problémy
« kdy: 07. 11. 2019, 00:39:41 »No jo, jenže jak bys to konrétně v nějakém mainstreamovém "OOP jazyce" implementoval? Dáš na každou metodu mutex a každá metoda bude mít možnost buď vyhodit výjimku nebo vracet speciální chybový stav "teď nemůžu"? Podle mě tam na to prostě není žádný nástroj, který by 1. z kódu neudělal totálně nečitelnou zhovadilost nebo 2. by kód nedegradoval na normální strukturovaný kód s nějakými podivnými strukturami "class", které s původní myšlenkou OOP nemají nic společného.Co třeba Pony ?
IMHO pokud se má OOP spojit s konkurentností a zároveň se nemá jedno nebo druhý totálně zhovadit, jediný řešení je to, které má Erlang (nepřekvapivě) - co objekt (actor), to vlákno. Protože "actor" je od slova "act". A vlákno je od slova "act". Vlastně není, ale to neva.
784
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 07. 11. 2019, 00:27:48 »
Nevykašlal. Jen moc práce.
Mohl by si se prosím trochu rozkecat ohledně jedné věci, která mi není tak úplně jasná?
(Omlouvám se, ten Elixír je na mě zatím příliš velké sousto.)
Mě tak nějak furt nedochází, proč bych měl těm aktorům dávat volnost, když je pak tak snadné to evidentně napsat špatně. Snad je z mého úvodního příspěvku jasné, že mi jde o to, aby to pokud možno nešlo napsat špatně. Proč nevytvořit specializované třídy aktorů, kterým engine dodá co potřebují, a ony se soustředí na svou práci?
Já ti to věřím, že je to špatně. Ale rád bych pochopil proč, nějaký příklad, ukázku, a tak.
Mohl by si se prosím trochu rozkecat ohledně jedné věci, která mi není tak úplně jasná?
(Omlouvám se, ten Elixír je na mě zatím příliš velké sousto.)
...
Tohle je úplně chybná implementace, která nepočítá s více klienty a proto zhavaruje:
...
Tahle je o trošičku lepší - vybírá zprávy selektivně, takže protokol zpracuje správně, ale pořád je chybná, protože neumí rozlišit sessions (nezajímá ji, od koho která zpráva je, takže klienti by klidně mohli posílat zprávy na střídačku a server by si toho nevšiml):
...
Mě tak nějak furt nedochází, proč bych měl těm aktorům dávat volnost, když je pak tak snadné to evidentně napsat špatně. Snad je z mého úvodního příspěvku jasné, že mi jde o to, aby to pokud možno nešlo napsat špatně. Proč nevytvořit specializované třídy aktorů, kterým engine dodá co potřebují, a ony se soustředí na svou práci?
Já ti to věřím, že je to špatně. Ale rád bych pochopil proč, nějaký příklad, ukázku, a tak.
785
Vývoj / Re:Jak vytvořit vlastní debugger?
« kdy: 03. 11. 2019, 23:05:32 »Velmi zajímavé! Jak byste na to šli?
Upřímně, já jsem na to šel cestou transpileru. Vezmu zdroják, zpracuju do tokenů, a pak ho vybuldím do cílové platformy. Osobně se domnívám, že v době Lui prostě nemá smysl dělat vlastní interpret. Jako bonus pak mám možnost buildit do javascriptu pro potřeby webu. Získaný čas a energii soustředím na blbosti kolem (typy, knihovny, ...).
Pokud opravdu to musí být čistokrevný interpret, co třeba toto?
Proměnné nejsou problém. To si prostě na to vytvoříš objekt řešící scope, uchovávající lokální proměnné (v případě neexistence dohledáváš v nadřazeném, etc). Mnohem větší pruda speciální formy IF, FOR, WHILE...
K seznámením s problématikou extrémně doporučuji přečíst toto. Dozvíš se i co nechceš. Ale popisujou tam všechny podrazy (interpretu).
Ale stejně bych šel spíš do transpileru :-)
786
Vývoj / Re:Jak vytvořit vlastní debugger?
« kdy: 02. 11. 2019, 15:22:01 »
Neřešil. Ale je to zajímavé téma.
Co třeba umožnit registrovat pozorovatele ve stylu AOP. Tedy můžeš si zaregistrovat jednu nebo více funkcí na místo určené selektorem. Něco jako breakpoint. Když kód přijde na to místo, tak té funkci předá aktuální stav (nutné deepclone). To by nešlo?
Samozřejmě když by si chtěl sledovat všechno, tedy plnohodnotný debuger, tak by se dal selektor na hvězdičku.
Co třeba umožnit registrovat pozorovatele ve stylu AOP. Tedy můžeš si zaregistrovat jednu nebo více funkcí na místo určené selektorem. Něco jako breakpoint. Když kód přijde na to místo, tak té funkci předá aktuální stav (nutné deepclone). To by nešlo?
Samozřejmě když by si chtěl sledovat všechno, tedy plnohodnotný debuger, tak by se dal selektor na hvězdičku.
787
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 23. 10. 2019, 13:51:39 »Představoval jsem si, že by bylo vhodnější, když by toto řešil systémově runtime, a nikoliv když by si to každý aktor dělal po svém. Ale promyslím si tvé výhrady.Proč myslíš, že je to vhodnější, a co očekáváš, že tím získáš? Actor sám má nejlepší informace o tom, v jaké fázi komunikace je, a taky vytváří ty data. Pokud použiješ tu session, tak oboje budeš muset předat někam jinam a při každém requestu si to zase brát zpátky. Není lepší si to prostě nechat u sebe?
Očekáváš, že když to budeš mít v runtimu na jednom místě, tak se ti to bude líp persistovat? Nebo?
Co to znamená "nechat u sebe"?
Očekávám, že získám
1. věci se budou dělat jedním způsobem
2. aktor bude bezstavovej, to znamená, že mohu zavolat toho samého aktora vícekrát
3. ano, můžu to líp persistovat, i třeba napříč stroji.
Hlavně mám ideu, že mám imutable aktora, který má závislosti na mutable službách.
Když si to bude ten aktor dělat sám, tak
1. bude muset mít stav - jak to budu řešit? Myšlenky mi stále sklouzávají do nějakého toho stavu, který budu muset někam dát.
2. Asi tedy nebudu moct zavolat aktor vícekrát.
3. Aktor si sám bude vyzobávat zprávy které chce. Bude si to sám nějak prioritizovat. Což se mi moc nechce mu tuto svobodu dopřát. Jaké to má výhody?
4. Aby si aktor uchoval stav, tak si zavolá jinej aktor?
788
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 23. 10. 2019, 02:06:35 »A v případě aktorů by do té session přistupoval aktor nebo systém? Session může sloužit pro uložení ledasčeho, nejen autorizace. Ten storage na data bys řešil jak?Já bych hlavně session v tomhle smyslu nepoužil. To byl BoneFlutuv napad.
Možná je zavádějící výraz Session. Co třeba Stav? Vlákno konverzace?
Ten Session/Stav byl myšlen, že mezi aktorem A a B vznikne komunikace, která pokračuje. Aktor si tam může uložit co chce, a pokud bude pokračovat ve stejném vláknu konverzace, tak to tam zase najde. Neslouží to k předání dat někomu jinému. Jakmile konverzaci ukončí, tak tato data zaniknou. Pokud začne novou konverzaci, tak tam také nejsou.
Představoval jsem si, že by bylo vhodnější, když by toto řešil systémově runtime, a nikoliv když by si to každý aktor dělal po svém. Ale promyslím si tvé výhrady.
789
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 22. 10. 2019, 02:02:51 »Jak to myslíš víc jak jednoho klienta?
Ten systém by mohl třeba umožňovat to, aby se - pokud jde např. o výpočetní úlohy - do systému registroval nějaký další aktor, který bude odebírat zprávy „výpočet hotov“ a bude z výsledku výpočtu dělat třeba grafy, statistiky nebo notifikace. Takový aktor by šel zaregistrovat ad-hoc, tj. by nebylo potřeba ostatní aktory pro tento případ upravovat, stačilo by napsat toho nového aktora a zaregistrovat ho, klidně za běhu systému. Nakonec by to mohlo vést na distribuovaný systém přes více počítačů.
Ano, tak nějak si to představuju. Zřejmě jsem jenom nepochopil jak to myslí s těmi klienty. Pochopitelně že ti aktoři jsou prostě v roli klient server.
To co popisuješ by ale vyžadovalo, aby ty data byly někde uschovány. Takže nějaký aktor "databázista/knihovník" který výsledky bude uchovávat. Nebo se k tomu poslednímu aktoru přihlásit jako subscriber, aby mi taky poslal výsledek. Ano, tyto vlastnosti a důsledky si uvědomuji.
790
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 22. 10. 2019, 01:55:04 »Já to mám vymyšlený tak, že runtime vyzvedává zprávy a ty potom prochází “volá” aktor s tou zprávou.Při téhle implementaci pravděpodobně narazíš, protože ti tam chybí právě ta možnost, aby si sám aktor určil, kterou zprávu chce zpracovat. Jestli teda dobře rozumím tomu, jak to myslíš.
Můžeš to okomentovat v čem je to řešení výhodnější/zajímavější.Jak to myslíš víc jak jednoho klienta?Actor poskytuje nějakou službu a ostatní actory tu službu využívají - v té chvíli se jim dá říkat "klient", protože to de facto není v tu chvíli nic jinýho než starej dobrej klient-server.
Pokud ten protokol je stavový (tj. jeden akt/session/... se skládá z víc než jedné zprávy a mezi zprávama je potřeba si pamatovat stav), tak se to může (ale nemusí) implementovat tak, že se vyřídí jeden "akt" (několik zpráv) v celku a až pak se jde na druhej. Jenže pokud je víc klientů, tak se ty zprávy můžou prolínat - a ty si potřebuješ vybrat tu, kterou teď zrovna chceš zpracovat.
Příklad:
Máš protokol:
A -- hi --> B
A <-- welcome -- B
A -- bye --> B
[konec]
Aktora B chceš z nějakýho důvodu napsat tak, aby tohle celý zpracoval naráz (nepřeskakoval mezi klienty). Zprávy mu ale můžou přijít pomíchaný:
1. A -- hi --> B
2. A <-- welcome -- B
3. C -- hi --> B
4. A -- bye --> B
- potřebuješ nutně možnost vybrat si selektivně zprávu 4. a teprve potom 3.
Možná se ti zdá, že tohle dělat nemusíš a dá se to obejít (třeba spawnutím spešl aktoru pro každou session). Stoprocentně ale narazíš na situaci, kdy to budeš potřebovat. Minimálně pro tu prioritizaci, která se (AFAIK) jinak než selektivním vybíráním zpráv řešit nedá.
U tohoto se prosím ještě zastavme. Já bych to řešil právě tou session. Přijde mi to takové intuitivnější. Aktor A + Zpráva + Session komunikace (kterou dodá obsluha). Tedy to, zda je ta zpráva od aktora B, nebo C(, nebo dokonce B jiná session) řeší runtime, a nikoliv vlastní Aktor. Aktor je jen a pouze vlastní logika. Takto si to představuju. V čem bych mohl narazit?
Proč bych měl chtít, pokud jsem tě pochopil dobře, aby aktor nepřeskakoval mezi klienty?
Já bych si přestavoval, že ten aktor je do značné míry bezestavový. Respektive ten stav je uložen mimo, ve službách a v session. Ale samozřejmě si rád vyslechnu proč je to blbej nápad :-)
791
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 21. 10. 2019, 18:09:46 »2. Každý proces (aktor) má mailbox. Zprávy se doručují striktně do mailboxu. Vždy přes něj projdou, nikdy se nekomunikuje "napřímo".
Já to mám vymyšlený tak, že runtime vyzvedává zprávy a ty potom prochází “volá” aktor s tou zprávou.
Můžeš to okomentovat v čem je to řešení výhodnější/zajímavější.
3. Zprávy je možné z mailboxu vybírat selektivně (ideální je na to pattern matching). To je potřeba nejenom kvůli prioritizaci, ale i kvůli tomu, abys mohl mít stavový protokol a zároveň víc než jednoho klienta.Jak to myslíš víc jak jednoho klienta?
1. Neexistuje sdílená paměť mezi actory. (Pokud bys chtěl dodržet čistý actor model, tak by tohle patřilo mezi must have, já to tam nedávám, protože i se sdílenou pamětí by to šlo implementovat - akorát si tím způsobíš víc problémů než užitku...)Moje představa je, že se všechny data, úplně všechna posílají přes zprávy. Sdílená paměť by byl jakoze side-effect. Ale k tomu jsem se ještě nedopracoval.
792
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 21. 10. 2019, 09:00:08 »Žádná předběžná analýza kódu se v tomhle případě prostě nedělá.Ehm, já žádnou předběžnou analýzu dělat nechtěl. Alespoň ne nutně.
No já si to představoval tak, že ti dva aktoři se zaciklí tak, že mi to shodí/extrémně vytíží ten runtime ve kterém to běží.V případě Aktorového systému jsem na tom podobně. Vzhledem k tomu, že to může být třeba přes vícero počítačů, tak když tam někdo zanese nějakou chybu, tak já nechci aby mi to všechno lehlo popelem. Zajímalo by mě to něco. Zajímalo by mě, jestli tomu můžu nějak zabránit. Ne absolutně, ne úplně. Ale alespoň trochu.Tady mě zaujalo to slovo "všechno". Actor systém musí být udělaný tak, že jednotlivé actory jsou opravdu nezávislé. Takže nejhorší, co se ti může stát, je, že jeden actor (A) přestane fungovat. A případně ta jeho nefunkčnost způsobí nefunkčnost aktorů, které na něm závisí (B,C). V žádném případě by se ale nemělo stát, že přestane fungovat "všechno", zejména ne actor D, který s A ani B a C vůbec nekomunikuje.
Ale to by se dalo řešit nějakým timeoutem, prioritizací, nebo tak něco.
P.S. Jak jsem tohle psal, tak mě napadlo, jestli náhodou se na tohle všechno neptáš proto, že zkoušíš napsat ten vlastní actorový systém (tj. tu vlastní infrastrukturu si píšeš sám). Pokud je to ten případ (nepoužíváš Erlang, Akka, ...), tak to určitě řekni, protože to by dost měnilo situaci. V tom vlastním systému je totiž potřeba dodržet pár věcí, které nejsou moc intuitivně zjevné a pokud je nedodržíš, nebude ti to fungovat. Těch věcí je jenom pár a můžu ti je vyjmenovat, pokud to potřebuješ.
Je to tak. Píšu si vlastní systém/runtime.
Napiš cokoliv ti přijde že by se mohlo hodit. Budu rád.
794
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 20. 10. 2019, 23:16:35 »
Díky za příspěvek.
Ano, takhle se klidně můžem bavit.
Když napíšu takovýto kód v Cčku, co se stane. Spustím to, a process bude vesele vyžírat prostředky, dokavad ho něco nezabije. Domnívám se, že nemůže nastat situace, že jsem si tím zasekl počítač, a můžu ho vyhodit.
V případě Aktorového systému jsem na tom podobně. Vzhledem k tomu, že to může být třeba přes vícero počítačů, tak když tam někdo zanese nějakou chybu, tak já nechci aby mi to všechno lehlo popelem. Zajímalo by mě to něco. Zajímalo by mě, jestli tomu můžu nějak zabránit. Ne absolutně, ne úplně. Ale alespoň trochu.
(Přičemž beru v potaz, co jsi k tomu už napsal. Jen se snažím vysvětlit svůj dotaz, když se evidentně tak blbě vyjadřuju.)
1. Velice pravděpodobně řešíš pseudoproblém. Zapomeň úplně na aktory a převeď si to na tenhle dotaz:
Učím se céčko a není mi jasný, jak zamezit tomuhle:Kód: [Vybrat]Nechce se mi spoléhat na to, že ty funkce budou napsány správně.int f() {
return g();
}
int g() {
return f();
}
Odpověď je stejná jako tvůj dotaz k Erlangu/Akka/... - nezaručuje se to obvykle nijak (v přísném, matematickém smyslu).
Ano, takhle se klidně můžem bavit.
Když napíšu takovýto kód v Cčku, co se stane. Spustím to, a process bude vesele vyžírat prostředky, dokavad ho něco nezabije. Domnívám se, že nemůže nastat situace, že jsem si tím zasekl počítač, a můžu ho vyhodit.
V případě Aktorového systému jsem na tom podobně. Vzhledem k tomu, že to může být třeba přes vícero počítačů, tak když tam někdo zanese nějakou chybu, tak já nechci aby mi to všechno lehlo popelem. Zajímalo by mě to něco. Zajímalo by mě, jestli tomu můžu nějak zabránit. Ne absolutně, ne úplně. Ale alespoň trochu.
(Přičemž beru v potaz, co jsi k tomu už napsal. Jen se snažím vysvětlit svůj dotaz, když se evidentně tak blbě vyjadřuju.)
795
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 20. 10. 2019, 14:19:39 »...
...
Díky za cenný příspěvek.
