Příspěvky

2041

Vývoj / Re:Nechápem tuto Go rutinu

« kdy: 21. 08. 2019, 18:50:09 »

Podle mě to je fakt jen vedlejší efekt, scheduleru prostě dojdou korutiny, což vyhodnotí jako deadlock a chcípne.

Asi mas pravdu. Ale kdyby chteli, tak by scheduler v tehle situaci klidne mohl udelat exit(0), ze

Asi ne, oni mají funkci pro obecnou kontrolu deadlocku, je jedno, jestli je korutin milion nebo nula, deadlock je prostě deadlock (z definice). Mohli by přidat další test na počet korutin, ale spíš nechtějí, aby se to používalo, protože na hlavní vlákno patří synchronizace. Taky by hlavní vlákno mohlo čekat implicitně. Možností (špatných) je jistě bambilion.

2042

Vývoj / Re:Nechápem tuto Go rutinu

« kdy: 21. 08. 2019, 18:46:04 »

BTW jak jde učení závislostních typů?

Precetl jsem asi padesat stranek a pak jsem to musel odlozit kvuli jinym povinnostem a obavam se, ze az se k tomu vratim, tak budu muset zacit zas od zacatku, pac mezi tim detaily zapomenu

Ta knizka je stylove teda hodne zajimava ale nemuzu rict, ze by mi to uplne skvele vyhovovalo. Je to trosku moc rozvlacny na muj vkus. Uprednostnil bych o malicko min taskaric a vic vyklad k veci. Idealni mi prijde uroven taskaric, kterou ma Learn You Some (Erlang|Haskell) for Great Good!

Ten styl je dost stupidní, rozhodně je mnohem lepší přečíst si radši něco o Heytingových algebrách a pak jen “přepnout” do FP.

2043

Vývoj / Re:Nechápem tuto Go rutinu

« kdy: 21. 08. 2019, 18:43:49 »

Aha. Na mě to působí jako vedlejší efekt toho, když to někdo zavolá na hlavním vlákně. Ale pro experimenty asi dobrý, disk to nejspíš nemaže...

Ja kdyz jsem to cetl, tak mi blesklo hlavou, ze to nejspis bude proto, ze by se nevedelo, jakej se ma z programu vratit navratovej kod. Ale to bude asi spis blbost

Podle mě to je fakt jen vedlejší efekt, scheduleru prostě dojdou korutiny, což vyhodnotí jako deadlock a chcípne.

2044

Vývoj / Re:Nechápem tuto Go rutinu

« kdy: 21. 08. 2019, 18:32:27 »

Viz dokumentace z odkazu výše. (“If all other goroutines exit, the program crashes.”)

To jsem pochopil jako "zamer ne neplechu" ("feature not a bug" ).

BTW jak jde učení závislostních typů?

2045

Vývoj / Re:Nechápem tuto Go rutinu

« kdy: 21. 08. 2019, 18:31:31 »

Viz dokumentace z odkazu výše. (“If all other goroutines exit, the program crashes.”)

To jsem pochopil jako "zamer ne neplechu" ("feature not a bug" ).

Aha. Na mě to působí jako vedlejší efekt toho, když to někdo zavolá na hlavním vlákně. Ale pro experimenty asi dobrý, disk to nejspíš nemaže...

2046

Vývoj / Re:Nechápem tuto Go rutinu

« kdy: 21. 08. 2019, 17:59:59 »

Akorát zrovna na hlavním vlákně dělá Goexit neplechu.

Jakou?

Viz dokumentace z odkazu výše. (“If all other goroutines exit, the program crashes.”)

2047

Vývoj / Re:Nechápem tuto Go rutinu

« kdy: 21. 08. 2019, 17:50:27 »

Tak v první řadě si musíš ujasnit, že program nečeká na ukončení všech gorutin - zkus si to:
https://play.golang.org/p/EWb7EBbneQk

na tyhle experimenty se hodí https://golang.org/pkg/runtime/#Goexit
https://play.golang.org/p/sEefsqrZNPR

Akorát zrovna na hlavním vlákně dělá Goexit neplechu.

2048

Vývoj / Re:Použití příkazu GOTO v jazyku C

« kdy: 21. 08. 2019, 09:15:58 »

Problém nevidím, může to ta vrstva poznat? O to v tom příkladu snad nešlo... Určitě by se to pak napsalo úplně jinak, ne?

Já se snažím psát funkce tak, aby když selžou, vrátily stav programu do stavu před svým voláním (tzn. uklidí po sobě).

No to je důvod proč preferuji pure funkce. Protože vím že nemohou ovlivnit okolní stav jinak než je očekáváno (to znamená nijak).

Můžou měnit kontext.

2049

Vývoj / Re:Rozdiely medzi F# a ocaml

« kdy: 20. 08. 2019, 20:47:27 »

akorát detaily asi většinou nebývají v jazyce explicitně.

Takže se asi shodnem, že to, co chce OP, smrdí nějakou chybou v návrhu, ne?

Jestli dobře chápu jeho dotaz, tak to rozhodně smysl má, akorát neznám Ocaml.

2050

Vývoj / Re:Rozdiely medzi F# a ocaml

« kdy: 20. 08. 2019, 20:21:26 »

který tak nějak přirozeně vede k “supertypu” (=any type)

Které jazyky takový typ skutečně mají? (Předtím jsem se asi nevyjádřil úplně přesně - ne že by se taková entita nedala myslet, ale neuvědomuju si, že bych viděl někde s ní v opravdové praxi operovat)

Agda tuším. Už si to pamatuju jen matně, ale je to nutnost, když chci mít topos typů a nad ním dobře definované (a well-behaved) operace. To se zrovna hodí i v praxi, akorát detaily asi většinou nebývají v jazyce explicitně.

2051

Vývoj / Re:Rozdiely medzi F# a ocaml

« kdy: 20. 08. 2019, 19:52:11 »

Ve správném funkcionálním jazyce by ani nic jako "any type" být nemělo

Určitě? Kdo to tvrdí? Pokud vím, ve FP se běžně pracuje se subobject classifier (sorry, českou terminologii v tomto případě neznám), který tak nějak přirozeně vede k “supertypu” (=any type), jenž se v jistém smyslu terminálním objektem příslušné kategorie. To jen tak na okraj, praktického významu to nejspíš nemá 

2052

Vývoj / Re:nechapem tuto go rutinu

« kdy: 20. 08. 2019, 12:17:44 »

Tak odpoved je, ze ten channel mam unbuffered, takze cokolvek tam poslem cez c <- tak to nebude cakat, kym to niekto precita, takze sa stihne poslat John, to sa vypise, posle sa Jim a program skonci bez toho aby to doplavalo k druhemu <- c v greet.

Ked deklarujem channel s kapacitou 1, tak to vypise aj bez sleepu.

Na druhej strane ale nechapem, co s tym ma ten sleep spolocny, ze to zrazu vypise spravne, ked je ten channel unbuffered.

Unbuffered naopak čeká.

2053

Vývoj / Re:Smalltalk, Self a podobne jazyky - mechanizmus posielania sprav

« kdy: 15. 08. 2019, 20:44:35 »

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.

To doesNotUnderstand má i Java, ale ještě jsem to neviděl v praxi.

To není tak úplně pravda, lze obalit volání metody s try/catch a odchytit výjimku NoSuchMethodException, ale to volání musí jít přes reflexi

Nemusí, Java má mechanismus pro proxy.

Budiž, lze použít i proxy, ale libovolnou metodu si takhle potom nezavolám.

Ono jde spíše o odchycení, a právě k tomu slouží InvocationHandler, což je ten ekvivalent doesNotUnderstand.

2054

Vývoj / Re:Smalltalk, Self a podobne jazyky - mechanizmus posielania sprav

« kdy: 15. 08. 2019, 20:06:07 »

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.

To doesNotUnderstand má i Java, ale ještě jsem to neviděl v praxi.

To není tak úplně pravda, lze obalit volání metody s try/catch a odchytit výjimku NoSuchMethodException, ale to volání musí jít přes reflexi

Nemusí, Java má mechanismus pro proxy.

2055

Vývoj / Re:Smalltalk, Self a podobne jazyky - mechanizmus posielania sprav

« kdy: 15. 08. 2019, 16:31:33 »

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.

To doesNotUnderstand má i Java, ale ještě jsem to neviděl v praxi.