Použití Objective-C mimo Apple

[Kolemjdoucí]

GNU Smalltalk uses preemptive green (non-native) threads; that is, multiple Smalltalk processes are run by the virtual machine in one operating system thread.

Neuniklo mi nic, zvláště ne "Threads are not preempted after a given amount of time". Slovo preemptive je tam jenom na bulíkování důvěřivých neználků.
Ostatně to je hlavní smysl green threads, eliminace nežádoucího preemptivního přepínání vláken, protože většina jazyků kde se to používá na to není zařízená.
V malé míře se používají také pro minimalizaci přepínání kontextů, ale to není případ bazmeků jako Smalltak.

[Reklama]

[Mirek Prýmek]

Neuniklo mi nic, zvláště ne "Threads are not preempted after a given amount of time". Slovo preemptive je tam jenom na bulíkování důvěřivých neználků.
Ostatně to je hlavní smysl green threads, eliminace nežádoucího preemptivního přepínání vláken, protože většina jazyků kde se to používá na to není zařízená.
V malé míře se používají také pro minimalizaci přepínání kontextů, ale to není případ bazmeků jako Smalltak.

Nějak mi asi uniká, co vlastně chceš tvrdit. Jak je to ve Squeaku máš detailně popsané tady http://wiki.squeak.org/squeak/382 a netuším, v rozporu s čím, co jsem řekl, to má být.

[noef]

Navic je tam primo vazba aplikace v PHP <-> konfigurak v PHP.

Čili používá přesně ten mechanismus, o kterém mluvím? A ptáš se, kdo to používá a proč?

Ne. Zrovna pripad konfigurace WP se mi libi. Konfigurace je opravdu jen vyplneni sablony dodane s WP, ale zaroven pokud je treba neco extra, tak je to mozne dobastlit ve stejnem jazyce jako zbytek applikace.

Jen jsem napsal, ze to neni vselek a pokud se to pouzije spatne (IMO SBT a Gradle, ale mozna jsem zaujaty, protoze jsem byl "nucen" je pouzivat, nezvolil jsem si je), tak je to naopak mnohem horsi, nez tam hodit jednoduchou konfiguraci v YAML nebo JSON. IMO spatne je, kdyz se konfigurace provadi v jinem jazyce, nez ve kterem je psan cely zbytek projektu. Prijde mi divne se ucit dalsi jazyk jen pro zapsani jednoducheho konfiguraku - a uz je celkem jedno, jestli je to nejaky minoritni jazyk jako Haskell (ktery asi moc adminu a uzivatelu nezna), nebo jazyk vytvoreny jen pro konfiguraci jedne aplikace. Treba LUA je natolik jednoducha a dostatecne podobna nejpouzivanejsim jazykum, ze tam chapu tu volbu. Ale konfiguracni soubory v extremne malo pouzivanych jazycich jako Haskell, Scala nebo Lisp? Navic pokud ke skoro neznamemu funkcionalnimu pristupu jeste pridam DSL s hromadou symbolickych neintuitivnich operatoru (v SBT kupr. %, ##, ---, +++, :=, <<=; to je v podstate novy jazyk) ...

[Kolemjdoucí]

Nějak mi asi uniká, co vlastně chceš tvrdit.

Pořád to stejné, jazyky s green threads v jednom OS vlákně nic takového jako asynchronnost podporovat nemohou, nelze napsat asynchronní kód přímo v jazyku. Erlang se zdá být v pořádku, spousta jiných včetně Smalltalku ne, Squeak ještě nevím.

[Mirek Prýmek]

tak je to naopak mnohem horsi, nez tam hodit jednoduchou konfiguraci v YAML nebo JSON.

Má to opodstatnění tam, kde využiješ větší expresivitu než prostou statickou datovou strukturu. Pokud je celá konfigurace jenom klíč-hodnota, tak to samozřejmě nemá smysl. Ale pokud tam máš nějaké části, které by bylo super generovat nějakou funkcí nebo třeba použít sem tam nějaký ten if, tak to význam má. Nevím, jestli znáš konfiguraci Nagiosu a jeho derivátů, ale to je typický příklad, kde by se to hodilo - je tam hromada spousta struktur, které se liší třeba jenom jednou položkou - typický adept na funkci/makro. V Nagiosu se to řeší šablonami a je to takový horor, že se to málo komu chce psát ručně a radši si to něčím vygeneruje. Pokud by konfigurace byla napsaná v nějakém expresivním jazyce, tak bys to generování nějakým třetím nástrojem nepotřeboval, protože by struktury generoval sám zdroják.

Např. v Elixiru vypadá konfigurační soubor projektu takhle: http://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html#project-compilation - a podívej se o kousek níž, jak je tam hezky použité to "deps_path(Mix.env)"

IMO spatne je, kdyz se konfigurace provadi v jinem jazyce, nez ve kterem je psan cely zbytek projektu. Prijde mi divne se ucit dalsi jazyk jen pro zapsani jednoducheho konfiguraku

V tomhle jsem se zjevně vyjádřil nesrozumitelně. Myslel jsem to tak, že je fajn, když je jazyk natolik dynamický, že konfiguraci můžeš zapsat v něm samém a nepotřebuješ další formát (a jeho parser) navíc. Nemyslel jsem to tak, že by bylo super, kdyby projekt v céčku měl embedded haskell kvůli konfiguráku

Navic pokud ke skoro neznamemu funkcionalnimu pristupu jeste pridam DSL s hromadou symbolickych neintuitivnich operatoru (v SBT kupr. %, ##, ---, +++, :=, <<=; to je v podstate novy jazyk) ...

Nadužívání DSLs je zlo, to je jasné. Bohužel to vzniká tak, že když člověk pracuje s jazykem, který DSLs umí dobře, tak je z toho tak nadšený, že to chce mermomoci použít. Znám z vlastní zkušenosti

[Reklama]

[Mirek Prýmek]

Pořád to stejné, jazyky s green threads v jednom OS vlákně nic takového jako asynchronnost podporovat nemohou

To právě nechápu, proč si tohle myslíš. To přece záleží na tom, co umožňuje VM a jak pracuje scheduler. Obecně tahle věta neplatí.

[noef]

tak je to naopak mnohem horsi, nez tam hodit jednoduchou konfiguraci v YAML nebo JSON.

Má to opodstatnění tam, kde využiješ větší expresivitu než prostou statickou datovou strukturu. Pokud je celá konfigurace jenom klíč-hodnota, tak to samozřejmě nemá smysl. Ale pokud tam máš nějaké části, které by bylo super generovat nějakou funkcí nebo třeba použít sem tam nějaký ten if, tak to význam má. Nevím, jestli znáš konfiguraci Nagiosu a jeho derivátů, ale to je typický příklad, kde by se to hodilo - je tam hromada spousta struktur, které se liší třeba jenom jednou položkou - typický adept na funkci/makro. V Nagiosu se to řeší šablonami a je to takový horor, že se to málo komu chce psát ručně a radši si to něčím vygeneruje. Pokud by konfigurace byla napsaná v nějakém expresivním jazyce, tak bys to generování nějakým třetím nástrojem nepotřeboval, protože by struktury generoval sám zdroják.

Jiste, ja nerikam ze to nema svoje misto. A i u pouheho klic-hodnota to muze byt k uzitku, kdyz by bylo v budoucnu potreba neceho pokrocilejsiho. Jen je dulezite, aby pro nastaveni zakladnich vlastnosti to bylo jednoduche a intuitivni a nevyzadovalo to ucit se dalsi jazyk (staci umet prirazeni). Take je nutne odlisit konfiguraci pokrocilych servrovych aplikaci a napr. GUI klikatka, ktere si bude nastavovat "bezny" uzivatel.

Např. v Elixiru vypadá konfigurační soubor projektu takhle: http://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html#project-compilation - a podívej se o kousek níž, jak je tam hezky použité to "deps_path(Mix.env)"

Pokud to chapu dobre, tak konfigurace samotna je v Elixiru. Vypada to jako prave ten dobry priklad pouziti - nenutim programatora se ucit dalsi jazyk jen proto, protoze se mi (jako tvurci nastroje) libil.

IMO spatne je, kdyz se konfigurace provadi v jinem jazyce, nez ve kterem je psan cely zbytek projektu. Prijde mi divne se ucit dalsi jazyk jen pro zapsani jednoducheho konfiguraku

V tomhle jsem se zjevně vyjádřil nesrozumitelně. Myslel jsem to tak, že je fajn, když je jazyk natolik dynamický, že konfiguraci můžeš zapsat v něm samém a nepotřebuješ další formát (a jeho parser) navíc. Nemyslel jsem to tak, že by bylo super, kdyby projekt v céčku měl embedded haskell kvůli konfiguráku

Navic pokud ke skoro neznamemu funkcionalnimu pristupu jeste pridam DSL s hromadou symbolickych neintuitivnich operatoru (v SBT kupr. %, ##, ---, +++, :=, <<=; to je v podstate novy jazyk) ...

Nadužívání DSLs je zlo, to je jasné. Bohužel to vzniká tak, že když člověk pracuje s jazykem, který DSLs umí dobře, tak je z toho tak nadšený, že to chce mermomoci použít. Znám z vlastní zkušenosti

V nekterych pripadech mohou vlastni symbolicke operatory dost pomoci, bohuzel vetsinou je to presne naopak. Jiz zminovane SBT je toho ukazkou - IMO by to melo byt pristupne v podstate vsem, co neco napsali ve Scale. V nekterych specializovanych knihovnach jako Scalaz to chapu - slouzi k zapisu predevsim matematickych operaci, presto mi teda prijdou unicode jmena divna, asi vec zvyku: ∑, ↦, ∅, ⊥. I tak to ale vytvari dojem slozitosti a znesnadnuje tak pochopeni veci novackum.

[Mirek Prýmek]

Pokud to chapu dobre, tak konfigurace samotna je v Elixiru. Vypada to jako prave ten dobry priklad pouziti - nenutim programatora se ucit dalsi jazyk jen proto, protoze se mi (jako tvurci nastroje) libil.

Ano - a přesně tak jsem to myslel. U programátorských projektů je to bez debat v pohodě, trochu míň v pohodě je to u vyloženě uživatelských věcí (např. když používám XMonad, tak nemusím nutně umět Haskell zatímco když dělám projekt v Elixiru, tak Elixir zjevně umím). I tak si ale myslím, že použít existující (a jakž-takž rozšířený) jazyk je pořád lepší než vymyslet si tisícíprvní konfigurační formát s expresivitou přesně naladěnou na to, co potřebuju, který změním vždycky když zjistím, že vlastně teď už potřebuju větší expresivitu...

Ono totiž se řekne "máme konfiguraci v YAML", jenže jakmile tam chceš vyjádřit něco ne-totálně-triviálního, tak už to vlastně není YAML, ale YAML dodává jenom syntaxi a k tomu je nějaká sémantika/ontologie, která může být pěkně přebujelá, v nejhorším případě vlastně postavíš programovací jazyk s YAMLovou syntaxí, abys měl tu potřebnou expresivitu (viz např. konfigurace http://docs.saltstack.com/en/latest/ kde je použití YAMLu imho už za hranou, protože jakmile tam máš X různých šablon s Y parametry pro Z strojů, tak ten YAML prostě přeteče do basketbalu, jak říká klasik a přehlednost deklarativního formátu je v pytli...

Btw, výhoda toho konfiguráku v Elixiru je v tom, že ty hodnoty můžeš brát odkud chceš a máš k dispozici celý jazyk. Je libo načíst dependencies z webu? Není problém. Z webu přes https s kontrolou certifikátů? Ok. Z webu zašifrovaný AES? Ok. Kdybys měl nějaký deklarativní formát, na všechny tyhle možnosti bys musel vymyslet nějakou spešl položku, kterou by se uživatel musel naučit...

[Kolemjdoucí]

To přece záleží na tom, co umožňuje VM a jak pracuje scheduler.

Nechápete ani základy, preemptivnost není vlastnost nějakého algoritmu. Podstatu preemptivnosti podporu násilného přerušení vykonávání vlákna bez jeho součinnosti, si v user-space jen tak nenaprogramujete. Jestliže celé VM běží v jednom vlákně, máte smůlu. Nějaké výjimečné pokusy jak to simulovat jsou, ale není to ono.

[Kolemjdoucí]

.. a preemptivnost je nutná podmínka asynchronního kódu.

[neruda]

a asynchronni kod je nutna podminka existence sveta, jinak bysme se tu vsichni zasekavali.

[Mirek Prýmek]

Nechápete ani základy,

Prosím bez silných slov, nepřispívá to kvalitě diskuse.

preemptivnost není vlastnost nějakého algoritmu. Podstatu preemptivnosti podporu násilného přerušení vykonávání vlákna bez jeho součinnosti, si v user-space jen tak nenaprogramujete. Jestliže celé VM běží v jednom vlákně, máte smůlu. Nějaké výjimečné pokusy jak to simulovat jsou, ale není to ono.

Chápu to správně, že postulujete, že obecně není možné něco, o čem jste sám přiznal, že presně to Erlang dělá? Je potřeba o tom vůbec víc diskutovat?

Jak budou vlákna vykonávána je samozřejmě vlastnost VM a jeho scheduleru. Pokud bude scheduler napsaný tak, že jednotlivá vlákna bude přepínat po vykonání jedné pseudoinstrukce (instrukce VM), tak to tak prostě bude dělat. Nerozumím, co se snažíte tvrdit/dokázat.

[Mirek Prýmek]

.. a preemptivnost je nutná podmínka asynchronního kódu.

Důkaz prosím.

[Mirek Prýmek]

Důkaz prosím.

Možná ho předejdu: mějme VM běžící v jednom vláknu, uvnitř něj jsou VM-vlákna (green threads), která scheduler VM přepíná po vykonání n instrukcí VM. Každé VM-vlákno má svůj mailbox. Instrukční sada VM obsahuje instrukci SEND, která vloží zprávu X do mailboxu procesu Y, a instrukci RECV, která vezme zprávu z vrcholu mailboxu.

Teď bych rád viděl ten důkaz, že takové procesy spolu nemůžou komunikovat asynchronně.

[v]

Důkaz prosím.

Možná ho předejdu: mějme VM běžící v jednom vláknu, uvnitř něj jsou VM-vlákna (green threads), která scheduler VM přepíná po vykonání n instrukcí VM. Každé VM-vlákno má svůj mailbox. Instrukční sada VM obsahuje instrukci SEND, která vloží zprávu X do mailboxu procesu Y, a instrukci RECV, která vezme zprávu z vrcholu mailboxu.

Teď bych rád viděl ten důkaz, že takové procesy spolu nemůžou komunikovat asynchronně.

nejdřív přesně definujte asynchronnost