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 - Mirek Prýmek

Stran: 1 ... 277 278 [279] 280 281 ... 618
4171
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 04. 06. 2015, 11:14:37 »
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ě.

4172
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 04. 06. 2015, 11:09:54 »
.. a preemptivnost je nutná podmínka asynchronního kódu.
Důkaz prosím.

4173
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 04. 06. 2015, 11:09:26 »
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.

4174
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 04. 06. 2015, 10:54:51 »
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...

4175
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 04. 06. 2015, 10:06:51 »
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í.

4176
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 04. 06. 2015, 10:04:11 »
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 ;)

4177
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 04. 06. 2015, 09:22:19 »
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.

4178
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 04. 06. 2015, 00:14:20 »
Ne že bych tuhle debatu dopodrobna sledoval, ale konfigurace v "normálním" jazyce je dost ošemetná záležitost, protože se dovnitř dá nainjektovat v zásadě cokoliv, pokud tam není nějaký sandbox. V praxi to asi často nevadí, ale ten princip je (opět bez sandboxu) dost šílený.
Není vůbec šílený, pokud se konfigurovaná aplikace spouští s právy toho, kdo ji má právo konfigurovat. Není žádná tragedie, že bys mohl  injektovat kód, který můžeš úplně klidně spustit tak jako tak :) Čili efektivně se nám to prakticky smrskává jenom na to, že by se takhle neměly konfigurovat suid programy, v čemž není sporu ;)

Ale obecně máš samozřejmě pravdu, sandboxing je čistější.

4179
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 03. 06. 2015, 23:25:17 »
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č?

4180
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 03. 06. 2015, 23:23:58 »
Erlang ano, většina ostatních včetně Smalltalk ne.
Uniklo ti
Citace
GNU Smalltalk uses preemptive green (non-native) threads; that is, multiple Smalltalk processes are run by the virtual machine in one operating system thread.
http://smalltalk.gnu.org/faq/35
?

Jinak green threads má (aspoň podle wiki) docela dost jazyků: http://en.wikipedia.org/wiki/Green_threads#Green_threads_in_other_languages

4181
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 03. 06. 2015, 11:29:41 »
Takže místo konfiguráku použiješ externí knihovnu konfiguračních funkcí :D No... možná pro nějaký vývoj se to hodit může, jinak v tom žádný velký výhody nenacházím :D Asi jako když v PHP pro konfiguraci použiju klasický php skript místo nějaké parsované konfigurace, takže místo parametr=hodnota napíšu $parametr="hodnota"; , což v tomhle konkrétním případě zase tak nevadí a není to moc k nepochopení, jenom když si parametry nastavuje uživatel, kterej PHP nezná, tak nesmí udělat syntaktickou chybu, jinak to shodí celý :D
Jakou externí knihovnu? Prostě zavoláš nějakou obdobu eval(...). Výhodu to má v tom, že máš k dispozici mocný jazyk, který spoustu lidí umí, a nemusíš vymýšlet nový jazyk, který se všichni budou muset naučit. Pratktický příklad: awesome WM má konfiguraci v Lua. XMonad ji má, pokud se nepletu, v Haskellu.

4182
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 03. 06. 2015, 11:26:32 »
Doporučuji benchmark třídění 1000000 32-bit int.
K čemu? Nikdo netvrdí, že dynamické, asynchronní, paralelizovatelné systémy jsou dobré na number crunching hrubou silou. To je samozřejmě dobré napsat v něčem jiném a s tím něčím jiným komunikovat vstupy a výstupy. Numpy i R funguje přesně takhle, je to jenom lepidlo a vlastní nuber crunching se dělá maximálně optimalizovaně. Proto je takový rozdíl použít v Rku for a apply :)

To jsem rád že jsme si to konečně ujasnili, tedy původní návrh s KayObject je dodnes z technických důvodů použitelný jen těžce.
To nevím, čím jsme si to ujasnili, ale nemám potřebu se hádat :)

Nutným předpokladem asynchronnosti je na sobě nezávislý paralelní běh asynchronních funkcí.
Zavolání funkce a nečekání na výsledek, s tím že dále to pokračuje přes callback nebo doručení zprávy je stále synchronní záležitost.
Zkusím to ještě jednou: Erlang VM má vlastní scheduler, který přepíná procesy, které běží naprosto nezávisle. Na jednojaderném stroji jsou samozřejmě ty procesy serializované, protože jaksi je tam prostě jenom jedno jádro. Ale "zevnitř" to člověk nepozná, funguje to pořád stejně ať je to jádro jedno nebo je jich 256.

Zjevně volně zaměňujete komunikaci mezi procesy a komunikaci uvnitř procesu. Při práci uvnitř procesu nepotřebuji hledat funkci podle názvu, protože znám její adresu rovnou. Při komunikaci mezi procesy to takhle není dost dobře možné, proto se funkce hledá podle názvu.
Nic nezaměňuju. Mluvím o tom, že existují systémy, které funkce vyhledávají v runtimu i pokud běží v jednom VM. Že to jde i jinak, o tom není sporu. Já jsem říkal, že pokud se to dělá vždy takhle, dá se vždy použít dynamický dispatch. Pokud se volání překládá na CALL, tak to samozřejmě nejde a žádný dynamický dispatch se nekoná, to je přesně ta pointa, nevím, kde je spor.

Tohle přesně uvnitř většího projektu nemá co dělat.
Existují lidi, kteří si myslí, že má. Beru na vědomí, že ty si to nemyslíš a jsem rád, že to vím :)

4183
Server / Re:Výpočet potřebného výkonu stroje pro DB
« kdy: 03. 06. 2015, 11:18:15 »
Ovsem na druhou stranu, pokud jde o data, ktera maji zustat privatni ...
Jde o free mobilni aplikaci, one man show, takže myslím není potřeba si hrát na Pentagon :) Na virtuálech typu Heroku, RackSpace apod. jedou i podstatně citlivější projekty. Možná kdyby to jejich uživatele věděli... :)

4184
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 03. 06. 2015, 09:57:29 »
a ty konfiguráky, moc si to nedokáž představit, ale proč ne :-D
Na tom je právě hezky poznat, jaké krásné možnosti dynamičnost přináší. Spousta softwarů navrhuje nějaký pseudo-programovací-jazyk jenom proto, aby mohly být konfiguráky dostatečně expresivní. Některé zajdou tak daleko, že je ten pseudojazyk dokonce turingovsky úplný. A kdo se má učit nějaký nový složitý formát? Proč, když máme dost programovacích jazyků?

Prostě do konfiguráku dáš úplně normální kód, který se úplně normálně provede a úplně normálně do runtimu zavede nějaké nové třídy/funkce, které pak zavoláš a máš konfigurační parametr. Žádný parser. Žádná nová, supercool syntaxe. Maximální možnosti.

4185
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 03. 06. 2015, 09:53:35 »
Programování se sice už nějakou dobu nevěnuju, ale můžeš mi uvést reálný smysluplný příklad využití téhle fičury?
Už jsem tady asi třikrát zopakoval RPC, mám znovu? :)

Možná při nějakým skriptování dejme tomu, ale pokud tohle chceš přeložit do strojáku, zkus si uvědomit, co to pro překladač znamená.
Pro překladač to znamená buďto to, že umí nějak "inspect" (nevím, jak se to říká česky) objekty - nakouknout do nich za běhu a držet si jejich typové signatury (což dělá Python).

Nebo to pro překladač neznamená vůbec nic a řeší to runtime. V Erlangu je to přesně takhle. Když chci zavolat funkci Mod:fun(1), tak se runtime prostě podívá, jestli má zavedený modul Mod a jestli v něm je funkce fun arity 1. Takže to "Mod" i "fun" může být úplně klidně uložené v proměnné (a tímpádem nakrásně klidně načtené z disku, čili naprosto neznámé v době překladu) a není s tím žádný problém. Samozřejmě je to pak o něco pomalejší než přímé volání pomocí nějakéhotoho CALL nebo JMP nebo jak se to dělá, asm u6 si fakt nepamatuju :)

Stran: 1 ... 277 278 [279] 280 281 ... 618