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.


Příspěvky - registrovany_ava

Stran: 1 ... 6 7 [8]
106
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 17. 10. 2019, 20:35:42 »
Naopak. Jsem v okamžiku návrhu. Všechnu je zelené a krásné. Ale ty aktory může (bude moct) napsat kdokoliv.

Hmm, a máš k tomu nějaké zadání? Třeba bychom se nad tím návrhem, vzory co omezí uváznutí atp. mohli zamyslet kolektivně..

107
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 16. 10. 2019, 16:57:29 »
I tak ale nevidím problém v tom napsat alespoň test, který spawne dva aktory, nechá jednoho poslat druhému zprávu ok, a zkontroluje, že zpátky přišla právě jedna odpověď ok, pokud je to zamýšlené chování. Bohužel díky tomu skrytému mutable stavu není zaručené, že když to tak dopadlo jednou, dopadne to tak i podruhé.

OK, ale tady se obávám, že neřešíš problém na který se ptám.

Jak otestovat aktor? To bych si snad i poradil.

Já se ale ptám na to, jak zjistit, případně otestovat, že v komunikaci mezi dvěmi aktory, které nemám pod kontrolou, nedojde k uváznutí. Přičemž samozřejmě se může jednat i o různé komunikace. Jednou je to ok -> ok, jindy done -> ok -> ok -> done... etc.

No, nejprve asi musíš definovat uváznutí. Jak poznáš, že nekonečná sekvence zpráv mezi aktory není korektní chování? Vždyť na tom, že si aktory posílají zprávy tam a zpátky není nic neobvyklého. Navíc právě díky tomu mutable stavu uvnitř nikdy nevíš, že je ta série zpráv skutečně nekonečná, můžeš mít uvnitř nějaký counter, který po tisíci iteracích přestane ok posílat, a zas to může být očekávané chování. Takhle asi narazíš buď na vágní definici uváznutí, nebo na Halting problem, jak zmiňoval někdo výše.

108
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 16. 10. 2019, 16:40:59 »
Ti aktoři jsou špatně napsaní. Když dostane správu "OK" tak na ni odpoví taky "OK". Prostě chyba.

Kacirska myslenka... :-)
Co na to napsat testy?

Úplně nevím, jak by to mohlo pomoct, ale nebráním se tomu. Jak?

Je fakt, že aktory se testují blbě, protože aktor je vlastně izolovaná jednotka se skrytým mutable stavem a funkcí receive s typem Any => Unit (čti jako "spolknu cokoliv a možná udělám nějaký sideeffect"). Takže se při práci s aktory musíš prát s mutable stavem a navíc přicházíš o všechny kontroly, které normálně poskytuje statický typový systém. Možná proto taky např. Erlang statický typový systém nemá.

I tak ale nevidím problém v tom napsat alespoň test, který spawne dva aktory, nechá jednoho poslat druhému zprávu ok, a zkontroluje, že zpátky přišla právě jedna odpověď ok, pokud je to zamýšlené chování. Bohužel díky tomu skrytému mutable stavu není zaručené, že když to tak dopadlo jednou, dopadne to tak i podruhé.

Jen pro zajímavost, je dost problémů, které někdo řeší aktory, ale lépe se na ně hodí FRP. Tam naopak funguje statický typový systém bezvadně, obejde se to bez mutable stavu, takže se nad tím daleko líp uvažuje, je to víc komponovatelné. Nějaké shrnutí pro a proti jsem našel tady: https://cs.stackexchange.com/a/9042

Ale samozřejmě záleží na konkrétním problému, na spoustu věcí aktory jsou ideální řešení.

109
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 16. 10. 2019, 14:40:17 »
No a jak vůbec víš, že to chování je špatně? Když si tu zprávu "ok" přejmenuješ třeba na "heartbeat", klidně by se to dalo považovat za pro některé scénáře korektní chování, např. testování živosti toho druhého aktora.

Souhlasím s příspěvkem dříve - napsat si na to testy.

Zdravím.

Zkouším si jednoduchý Aktor systém. Celkem mi to jakože pěkně funguje, ale trošku jsem se zasekl na uváznutí.

Předpokládejme dva aktory A a B.
A -> B: kolik je hodin
B -> A: 19:41
A -> B: supr, díky
B -> A: není zač
A -> B: ok
B -> A: ok
A -> B: ok
B -> A: ok
A -> B: ok
B -> A: ok
A -> B: ok
...

Mohl by mi tu někodo poradit, jak se něco takového řeší? Třeba v Erlangu, systému Akka, nebo dalších?

Nechce se mi spoléhat na to, že ten aktor bude napsán správně. Rád bych tomu dodal alespoň základní ochranu. V "normálním" kódu se to dá trochu statistickou analízou podchytit. Na druhou stranu mé znalosti problematiky jsou omezené, a tak třeba existuje nějaké jednoduché řešení které dokáže víc.

Předem dík.

110
Vývoj / Re:Naučení se asynchronnímu programování
« kdy: 10. 10. 2019, 20:11:13 »
Coz mi pripomina, jak asi vypada stacktrace v pripade Coroutin s await async. Zda-li je zmrsena, nebo zda-li vypada stejne jako kdybych asynchronni cast kodu provedl v samostatnem vlakne, tedy ze ta odvetvena cast kodu ma svou vlastni peknou stacktrace.

Tohle je dobrá otázka. Krátká odpověď (nejsem expert) je, že záleží na konkrétní implementaci v konkrétním jazyce. Tady je pěkný blogpost, který porovnává jak je to s stacktracem v JavaScriptu a v Rustu: https://fitzgeraldnick.com/2019/08/27/async-stacks-in-rust.html

111
Vývoj / Re:C++ no default constructor exists for class
« kdy: 26. 09. 2019, 20:32:58 »
Ďakujem Vám všetkým a hlavne Františkovi (ale aj ostatným).

Ospravedlňujem sa že som skôr nereagoval ale kým o tom nemám dostatok informácií tak nechcem vyzerať ako úplný analfabet. Už začínam chápať kde bol problém preto sa teraz študujem pointery a referencie aby som mal istotu čo kedy a kde použiť (A hlavne sa hráme s shared_ptr a unique_ptr) Teda viem ako tie pointery fungujú ale dosť často napriek tomu tápem či mám ten objekt alokovať na stacku alebo heape.

Hmm, možná už je pozdě, ale neuvažoval jsi, že by ses místo C++ začal učit Rust? Jestli to máš na vlastní projekty, myslím, že by se ti mohl líbit víc, obzvlášť pokud píšeš že jsi programoval funkcionálně tě oproti C++ potěší ADT přímo v jazyce, absence NULL a výjimek, nemožnost data races nebo neplatného přístupu do paměti (double free, use after free, leaky).. Cílová skupina je asi ta samá, systémové programování. Ale jestli to hledáš kvůli komerčnímu uplatnění, tak toho je v C++ samozřejmě víc..

112
C# ekvivalent tveho prikladu by vypadal

Kód: [Vybrat]
(a > 5).EvalCondition(
    ifTrue: () => MessageBox.Show("a je vacsie ako 5"),
    ifFalse: () => MessageBox.Show("a je mensie ako 5")
)

Z typu by melo byt jasne jak to funguje.

smalltalkovske zpravy a volani metod v jinych jazycich je v zasade to same, jen je
 
 - jina terminologie (zaslani zpravy vs volani metody)
 - jina syntaxe (smalltalkovske nullarni/binarni/keyword zpravy)
 - ve smalltalku je mozne poslat zpravu (volat metodu), kterou receiver (objekt na kterem ji volam) neimplementuje (neni staticke typovani). V takovem pripade se na receiveru zavola metoda #doesNotUnderstand: (volana zprava), ktera by default vyhodi vyjimku, ale je mozne ji pretizit a zpracovat specialne (napr. se takto daji implementovat ruzne genericke proxy objekty).
 - volana zprava (tj. selektor aka "nazev metody" v novem OOP + argumenty) je zapouzdrena (smalltalkar by asi rekl reifikovana) do objektu Message, dostat se k ni lze napr. prave treba v #doesNotUnderstand:. Nebo je mozne ji programove vytvorit, treba na zaklade uzivatelskeho vstupu, a poslat nejakemu objektu

Vetsinou to jsou veci, ktere jdou napr. i v pythonu apod., ale v smalltalku je to vsechno tak nejak prirozene, od zacatku se s tim pocita v syntaxi jazyka, standardni knihovne, i vyvojovem prostredi, takze se to snadno a prijemne pouziva. Treba #doesNotUnderstand neni vec, kterou by clovek pretezoval kazdy den (nebo mesic), ale kdyz je to nahodou potreba, je prijemne ze to je k dispozici.

113
možná by to prohlížítko mohlo podporovat řazení a stránkování.
Řazení dělat asi nebudu, to mi nedává moc smysl (usecase?), stránkování je tam v TODO :-)

114
Používám http://glogg.bonnefon.org/
Hmm, to není blbý. Je zajímavý jak se autoři soustředili na jiný featury než já. Ten nápad se dvěma oknama je asi docela šikovnej. Díky za tip.

115
Zdar všem,

Občas se dostávám do situace, že potřebuju najít chybu v aplikaci, která komunikuje s různými přístroji, a občas se někde něco nepovede. Tak pozapínám na různých místech Debug a Trace levely a pak dlouho hloubám nad logy. Zatím jsem hloubal s pomocí grepu a vim-u, ale už mě to otravovalo, zkoušel jsem najít nějakou aplikaci která by mi to usnadnila, ale nic funkčního jsem nenašel. Nakonec jsem si malou věc napsal, měl jsem trochu volného času a aspoň to byla pěkná příležitost vyzkoušet si jazyk Elm (spokojenost).

Otázky mám dvě:
 - Máte nějaký tip na aplikaci pro takovéhle situace? Aby to nebyla cloudová služba ale aplikace, ideálně přenosná (Linux, Windows), umělo to základní filtrování, zvýrazňování nalezených řetězců. Stačí pro menší logy, nechci Kibanu nebo Logstash.
 - Co si případně myslíte o mém pidivýtvoru: K vyzkoušení zde, https://dvtomas.github.io/portable-log-viewer/ , github: https://github.com/dvtomas/portable-log-viewer/ .

Je mi jasné že je to nehotové a aktuálně užitečné tak sotva pro mě, spíš mě zajímá jestli je tu někdo, komu podobná aplikace chybí a tohle by mu přišlo fajn..

116
Odkladiště / Re:Nový OS
« kdy: 07. 08. 2019, 09:42:21 »
Když tu tak padá ten Rust, divím se že ještě nikdo nezmínil https://www.redox-os.org/

Stran: 1 ... 6 7 [8]