Node.js a multiplexed IO obecně

[gll]

Je dobře, že se v JS dobře orientujete, protože nám můžete vysvětlit podstatu onoho výsledku

> new Boolean(true) == new Boolean(true)
false

Porovnáváte reference dvou různých objektů. Je to stejná záludnost jako porovnávání stringů v Javě.

Měl jsem za to, že identity (reference) se srovnávají s ===, == je ekvivalence (obdoba), kterou má Boolean (logicky) překrytou. Opět mi něco ušlo?

== nejde překrýt. Kdyby to šlo, tak byste to považovali za magii a nadávali na to, protože je v módě kopnout si do javascriptu a skriptovacích jazyků obecně.

Mno je to rekneme nestastne a ze to je podobne nestastne v Jave moc dobra omluva neni...

https://www.w3schools.com/js/js_booleans.asp

tady se jasně píše, že se boolean objekt nemá používat.

používejte Boolean(val) bez new.

[Reklama]

[Inkvizitor]

Jasne, ze unboxuje. Z objektu udela primitivni typ s opacnou hodnotou. To je na tebe ale asi moc slozite pochopit, kdyz se to nepoda polopate, co?

negace objektu je false. Nic to neunboxuje.

OK, uznavam chybu. Je to tak.

[Mirek Prýmek]

tady se jasně píše, že se boolean objekt nemá používat.

...a jsme opět u toho...

A pokud chci ... tak musím ... . Ale je potřeba vědět, že ... a ... . Pochopitelně jenom v případě že ... . Což ví všichni, kdo nejsou ignoranti.

[gll]

Což ví všichni, kdo nejsou ignoranti.

přesně tak.

[SB]

Děkuji, už jsem to pochopil. == není obvyklá ekvivalence a === identita. Dle definice ECMA jsou to prostě jakési vlastní, komplikované operátory, které se snaží pracovat s primitivy i objekty zároveň. Skutečnou ekvivalenci objektů je třeba řešit extra.

[Reklama]

[čumil]

Tady je někdo kreten.
Jazyk to nebude.

Víš, je rozdíl mezi false a new Boolean(false).
To první je unboxed primitive value a to druhé je boxed primtive value.
To boxed znamená že je to objekt s vlastním prototypem.
Což znamená že == a === porovnává reference nikoli primitivní hodnoty.
Když na boxed boolean aplikuješ negaci, vyjde ti vždycky false protože negace objektu je vždycky false (protože každý objekt mimo null je přetypovatelný na true).

Kód: [Vybrat]

!new Boolean(true) === !new Boolean(false)ti vyjde jako true.

A opět, neni to divnost jazyka, je to jenom kompletní ignorace se ho alespoň v mezích naučit.
TEČKA.

Máte recht, už jsem si to ověřil a je to tak - negace neprování nejprve unboxing (jak bych čekal, když se javaskriptaři tolik prsí transparentností boxingu/unboxingu), ale bere to přednostně jako onu "negaci" objektu. Moje nepozornost. Otázkou zůstává, zda je nutno takovýmto věcem věnovat energii. Asi to není jazyk pro mě.

Váš popis == a === nechápu, jejich funkčnost jsme tu rozebrali pár příspěvků zpět.

Je dobře, že se v JS dobře orientujete, protože nám můžete vysvětlit podstatu onoho výsledku

> new Boolean(true) == new Boolean(true)
false


A příště to zkuste slušněji.

ok pardon, má chyba

[čumil]

(x == x) !=  (!x == !x)

je nade vší pochybnost blb.

Nejlepsi je, ze tyhle prasarny (a ano, vim, proc to tak asi je - unboxing boolu operatorem "not"), ale je to jasna prasarna) se budou ted decka ucit na skolach. Takze uz jim to bude pripadat normalni.

Not nic neunboxuje omg.
Boxed boolean je objekt dozadeke uz.
Jak mezi idiotama...

Jasne, ze unboxuje. Z objektu udela primitivni typ s opacnou hodnotou. To je na tebe ale asi moc slozite pochopit, kdyz se to nepoda polopate, co?

ale piča, skus to nacpat do REPLu a uvidíš že to cos napsal je pičovina.

[otp]

Divím se, že tu ještě nikdo nezmínil Erlang... kdo ví, jak to ten starej lišák dělá...

[Mirek Prýmek]

Divím se, že tu ještě nikdo nezmínil Erlang... kdo ví, jak to ten starej lišák dělá...

Co? Porovnání? V tom Erlang není zajímavý - má taky dva operátory, taky jeden pro porovnání "nezávisle na typu" (1.0==1 -> true) a jeden "přesný" (1.0 =:= 1 -> false), ale oba jsou definované rozumně a předvídatelně, oba jsou použitelné a používané.

Navíc, Erlang má jednodušší situaci, protože má jenom immutable struktury, takže tam moc nedává smysl porovnávat identitu. Porovnávají se jenom hodnoty.

Možná by nás tady leda mohlo zajímat tohle:

When comparing an integer to a float, the term with the lesser precision is converted into the type of the other term, unless the operator is one of =:= or =/=. A float is more precise than an integer until all significant figures of the float are to the left of the decimal point. This happens when the float is larger/smaller than +/-9007199254740992.0. The conversion strategy is changed depending on the size of the float because otherwise comparison of large floats and integers would lose their transitivity.

http://erlang.org/doc/reference_manual/expressions.html

[SB]

...Navíc, Erlang má jednodušší situaci, protože má jenom immutable struktury, takže tam moc nedává smysl porovnávat identitu. Porovnávají se jenom hodnoty...

Dovolím si nesouhlasit - to, že je něco immutable, neznamená, že se to nemůže objevit někde jinde a není třeba ověřit identitu, jinak řečeno s nemutovatelností to nemá co dělat. Jediným problémem je, zda v Erlangu existují struktury s identitou (Erlang neznám).

[Mirek Prýmek]

Dovolím si nesouhlasit - to, že je něco immutable, neznamená, že se to nemůže objevit někde jinde a není třeba ověřit identitu, jinak řečeno s nemutovatelností to nemá co dělat. Jediným problémem je, zda v Erlangu existují struktury s identitou (Erlang neznám).

Proto jsem nenapsal, že to "nejde" (ani teoreticky), ale že to "moc [resp. vůbec] nedává smysl". Erlang má (narozdíl od Scaly např.) data opravdu striktně imutabilní (nelze je změnit žádným způsobem, ani nějak výjimečně) a tímpádem tam žádné kopírování dat ani nikde neexistuje (není jak ho provést), čili není co ověřovat - "kopie dat někam jinam" se dělá tak, že se tam ta data prostě předají. Jestli je runtime fyzicky zkopíruje nebo jenom předá odkaz, programátor vůbec neví a neřeší, protože na sémantiku programu to nemá žádný vliv.

Jediná situace, kde bych si to se všema očima zavřenýma uměl představit, by byly mapy:

Kód: [Vybrat]

iex(1)> a = %{a: 1}
%{a: 1}
iex(2)> b = %{a: 1}
%{a: 1}
iex(3)> a = a |> Map.put(:b,2)
%{a: 1, b: 2}
iex(4)> b = b |> Map.put(:b,2)
%{a: 1, b: 2}
iex(5)> a =?= b
???
Takový operátor ale neexistuje, protože ho nikdo k ničemu nepotřebuje

[otp]

Divím se, že tu ještě nikdo nezmínil Erlang... kdo ví, jak to ten starej lišák dělá...

Co? Porovnání? V tom Erlang není zajímavý - má taky dva operátory, taky jeden pro porovnání "nezávisle na typu" (1.0==1 -> true) a jeden "přesný" (1.0 =:= 1 -> false), ale oba jsou definované rozumně a předvídatelně, oba jsou použitelné a používané.

Navíc, Erlang má jednodušší situaci, protože má jenom immutable struktury, takže tam moc nedává smysl porovnávat identitu. Porovnávají se jenom hodnoty.

Možná by nás tady leda mohlo zajímat tohle:

When comparing an integer to a float, the term with the lesser precision is converted into the type of the other term, unless the operator is one of =:= or =/=. A float is more precise than an integer until all significant figures of the float are to the left of the decimal point. This happens when the float is larger/smaller than +/-9007199254740992.0. The conversion strategy is changed depending on the size of the float because otherwise comparison of large floats and integers would lose their transitivity.

http://erlang.org/doc/reference_manual/expressions.html

Myslel jsem: vlákna a IO... vždyť to má být soft real time...

[Mirek Prýmek]

Myslel jsem: vlákna a IO... vždyť to má být soft real time...

Ajo

U Erlangu jsou to čtyři koncepty: 1. leightweight procesy (uvnitř VM, s vlastním user-space plánovačem) 2. žádný sdílený stav mezi nimi (kromě databáze) 3. striktně imutabilní struktury 4. komunikace mezi procesy je striktně asynchronní (pokud chci synchronní, zařídím si to protokolem nad tím)

Teprve tohle všechno dohromady dělá to, že je obsluha událostí v Erlangu taková pohoda. Nemusíš totiž řešit žádné zámky, nemusíš řešit, jaká data můžeš předat komu atd. Obvykle můžeš klidně pro vyřízení každého requestu spustit samostatný proces, v něm si všechno pořešíš v klidu synchronně, aniž by tě jiný vlákna jakkoli rušily, a výsledek pošleš kamkoli (klidně na víc míst) formou imutabilních dat. Díky těmhle vlastnostem může být i daleko jednodušší GC - nemůžou tam z principu vzniknout kruhové odkazy a spousta dat je jenom na stacku procesu, který se se skončením procesu prostě zahodí, GC se moc nemusí šťourat někde uvnitř a řešit nějaké složitosti.

Mapování interních procesů na vlákna OS se pak dělá stejně jako v jakémkoli jiném moderním runtimu - spustí se tolik vláken, kolik je (virtuálních) jader a procesy se na ně mapují podle toho, kdo má zrovna čas. Žádná velká věda Z pohledu programátora tak vznikne plně konkurentní systém se slušnou latencí (sice probabilistickou, ale slušnou).

[Mirek Prýmek]

Ještě malá poznámka, jestli to z výš napsanýho nebylo jasný:

Díky těmhle vlastnostem může být i daleko jednodušší GC - nemůžou tam z principu vzniknout kruhové odkazy

...čímžpádem v Erlangu není ani žádný "stop the world", což taky soft-realtimovosti pomáhá.

[David]

Hodim sem takovou otázku ohledně Node.JS. Pokud vim, zpracovávaj se všechny požadavky v jednom vlákně. Co se tedy stane, když najednou server dostane obrovský množství požadavků. Moje představa je taková, že u prvního požadavku zpracuje např. jeden příkaz, pak jde k druhýmu.. a postupně je všechny obejde a jde zpracovávat druhej příkaz u všech. když bude takhle obsluhovat třeba X požadavků - OK, ale až jich bude 100× víc, v tu chvíli se to musí všechny požadavky zpracovávat pomalejš, ne? Nebo se to prostě řeší limitem, kolik se jich může zpracovávat současně?