トップページ⇒tech
1002コメント339KB

【node.js】サーバサイドjavascript 3【io.js】©5ch.net

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん 転載ダメ©2ch.net2014/12/27(土) 18:40:07.70ID:MwQYLNUR
pythonやrubyやPHPと同じ土俵でjavascriptが使えるようになりました。
サーバサイドjavascriptについて語りましょう。

node.js - googleが開発したV8エンジン上で実行できる処理系
http://nodejs.org/
io.js - node.js 互換で Joyent の影響からの脱却を目指す処理系
http://iojs.org/
Rhino - JVM上で実行できる処理系
https://developer.mozilla.org/ja/Rhino

io.js の経緯
http://stackoverflow.com/questions/27309412/what-is-the-difference-between-node-js-and-io-js
javascriptはrubyと比較してもかなり速い
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&;lang=v8&lang2=yarv
基礎から学ぶNode.js
http://gihyo.jp/dev/serial/01/nodejs
node.jsの概要とアプリケーション開発の準備
http://gihyo.jp/dev/serial/01/realtimeweb/0002

前スレ
【node.js】サーバサイドjavascript 2【Rhino】
http://peace.2ch.net/test/read.cgi/tech/1358937029/
【node.js】サーバサイドjavascript【Rhino】
http://toro.2ch.net/test/read.cgi/tech/1310087535/
0045デフォルトの名無しさん2015/01/04(日) 19:14:35.42ID:w9Cj0tkO
JavascriptとPHPでだいたいのことはカバー可能という認識でおｋでしょうか？
0046デフォルトの名無しさん2015/01/04(日) 19:32:10.48ID:zyY9pL0A
MySQLかSQLiteも欲しい
0047デフォルトの名無しさん2015/01/04(日) 20:18:20.57ID:w9Cj0tkO
やはりMySQLがないと片手落ちなのですね
どうもありがとうございます
0048232015/01/04(日) 20:31:31.22ID:LcMrfHes
>>34,43
>Schedules to run handler immediately after user agent events have been flushed.
>user agent eventsってなんだ？
ここで言っているuser agent eventsはHTML要素のon〜属性に指定したイベントハンドラ関数みたいだね。
1章のIntroductionで「user agent eventsの中で画面を書き換えるような処理を書いて、
その後の処理を行う前にその変更を画面に反映させたいときに、今まではsetTimeout(fn,0)を
使ってただろうけど、それだと遅延が発生するからsetImmediateてメソッドを定義するよ」
ってな感じのことが書いてある。

>> そこはこのNotesに書いてある"platform code"から好きなものに置き換えてくれ
>置き換えて何だよ？
Notes の記述に、
This can be implemented with either a "macro-task" mechanism such as setTimeout or setImmediate,
or with a "micro-task" mechanism such as MutationObserver or process.nextTick.
「これは、setTimeout,やsetImmediate (”マクロタスク”機構）、またはMutationObserverやprocess.nextTick
（"マイクロタスク"機構）を使っても実装できるよ」
って書いてあるね。この中のどれを使って置き換えても実現できるということだね。

例外処理についても>>44の通りで、それ以上に言うべきことはないかな。
ただデバッガとかブレークポイントとかの言葉が出ていたから、
必要以上に難しく考えていたんじゃないかという気がしないでもない。
0049232015/01/04(日) 20:43:54.20ID:LcMrfHes
>>43
>たとえばQはこの辺で"platform code"を呼び分けてる (モダンブラウザだとpostMessage()が使われてるな)
MessageChannel 知らんかった。。。
node.js では process.nextTick、ブラウザでは setTimeout と使い分けるだけだったよ。
勉強になった、サンクス。
0050デフォルトの名無しさん2015/01/04(日) 20:59:25.50ID:CtgO5+tK
>>44
> Promiseを使わない場合でもnodeの流儀ならコールバックの第1引数で通知する
通知しても呼び出し側がハンドリングしてなきゃ意味ないだろ
別にハンドリングしたきゃrejectjをハンドリングすりゃいいんだよ、アホか

まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが
気を効かせて例外を通知してくれるって事を言ってんのに
お前はなんで分かんないんだよマジで無能だな
0051デフォルトの名無しさん2015/01/04(日) 21:02:03.05ID:CtgO5+tK
>>44
お前がPromise使ってプログラムなんかした事ないド素人なのは分かったよ
じゃなきゃ、そんな事言う訳ないし
普通はそうだね、で終わる話しを、ドアホのお前がバカみたいに突っこんでるだけなのを
オレが暇だから相手してるだけだよ
0052デフォルトの名無しさん2015/01/04(日) 22:08:03.31ID:NffMCEWR
暇ならもう少し相手してもらおうか
まず

> ・渡されたコールバックを確実に非同期で実行する

これがJSで実装できないって主張は間違いだったということでいいのか？
次に

> ・飲み込まれた例外をデバッグ出来る

「まったくハンドリングしてない予期しない例外」をデバッグできるのは内蔵Promise関係なく
JS処理系(Chromeならv8)のデバッガの機能だろ
nodeでもv8のデバッガは有効だからnode debug x.jsで実行してbreakOnExceptionしておけば
「まったくハンドリングしてない予期しない例外」でブレークする
nodeはprocess.on('uncaughtException')があるからそれでデバッガ使う機会は少ないけどな
だがこの話マジでPromise関係なくね？

つか「ハンドリングしてない例外」でなく「ハンドリングしてないreject (uncaught promise rejections)」
のデバッグを言ってるのか？
だとすると全然話が違うが、debugger文を使えば内蔵Promiseじゃなくても実装はできるな

> お前はなんで分かんないんだよマジで無能だな

お前以外誰もお前の言ってることを理解できてないんじゃないか？w
できてる人がいるならマジで翻訳してくれ

あと俺はECMA入り前を含めると2012年頃からPromise使ってる
ただしnodeでの話だからブラウザ固有の話は知らない可能性は高い
ここはサーバサイドJSスレなんだからその辺はお前の方が考慮してくれ
0053デフォルトの名無しさん2015/01/04(日) 22:36:38.77ID:NffMCEWR
せっかくなので具体的に
こういうコード(x.js)があるとするじゃろ

process.nextTick(function() {
　throw new Error('unhandle');
});

こうやって実行するじゃろ

$ node debug x.js
< Debugger listening on port 5858
connecting to port 5858... ok
break in x.js:1
> 1 process.nextTick(function() {
　2 throw new Error('unhandle');
　3 });

1行目で止まってるからおまじないを唱えるじゃろ

debug> breakOnException

実行再開するじゃろ

debug> c
exception in x.js:2
Error: unhandle
　1 process.nextTick(function() {
> 2 throw new Error('unhandle');
　3 });
debug>

ハンドルされてない例外のせいで2行目で止まったじゃろ
0054デフォルトの名無しさん2015/01/04(日) 23:45:19.91ID:NffMCEWR
ところで「ハンドリングしてないreject」のデバッグって
最新のブラウザではサポートされてるのか？
たとえば

Promise.resolve(true).then(function(v) {
　throw new Error('then');
}).catch(function(e) {
　console.log(e);
});

と最後にcatch()すべきところを忘れてしまって

Promise.resolve(true).then(function(v) {
　throw new Error('then');
});

とした場合、これをChrome安定版(39)で実行してもブレークしない
スローした例外は内蔵Promiseの実装でcatchしてるからv8から見ると
ハンドルされてるって扱いなんだろう
Chrome開発版や他のブラウザだとブレークするのか？
0055デフォルトの名無しさん2015/01/05(月) 09:46:01.36ID:mZODWVt6
>>50
横から失礼、俺も読んでて意味わからないから質問させてくれ

＞まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが
＞気を効かせて例外を通知してくれるって事を言ってんのに
＞お前はなんで分かんないんだよマジで無能だな
内臓Promiseの利点はデバッガが気を利かせて例外通知をしてくれる、と読めるんだけど、つまり製品に使うと勝手にデバッガが動いてる状態になるから開発時以外は使っちゃいけないって事でOK？
それともPromiseには何らかのデバッガが内臓されている感じなのかな？もしそうだとして、デバッガが動作してることを前提でコードを組むのがPromiseの使い方って事？

もし前者なら(特に将来的に)仕様がどうなるかは環境依存って事になるから、Promiseは使ってはいけないんじゃないだろうか？
0056デフォルトの名無しさん2015/01/05(月) 12:38:50.48ID:A9O4oHD7
面倒だがこうなったらしょうがない少し付き合ってやる

>>52
> > ・渡されたコールバックを確実に非同期で実行する
>
> これがJSで実装できないって主張は間違いだったということでいいのか？
setImmediate()の仕様は、渡されたコールバックを次のJavaScriptの命令が確実に実行された後に
実行するとは読めなかったが、もし内部の実装がそうなってるのであれば、setImmediate()で
実装できるよ
ただし、本当に内部の実装がそうなってるかどうかはお前が確認して報告しろ

> Chrome開発版や他のブラウザだとブレークするのか？
通常のChromeとFirefoxでブレークするのを確認した

>>55
> つまり製品に使うと勝手にデバッガが動いてる状態になるから開発時以外は使っちゃいけないって事でOK？
デバッガは普通のブラウジング時には有効になってないよ
有効にするにはブラウザごとにやり方が違うから自分で調べてくれ
0057デフォルトの名無しさん2015/01/05(月) 20:40:46.70ID:xBMPeqox
>56
> ただし、本当に内部の実装がそうなってるかどうかはお前が確認して報告しろ

process.nextTick()もsetImmediate()もsetTimeout()もそうなってるよ
どの関数もreturnして後続のコードが実行されてイベントループに戻るより前に
コールバックが呼ばれることはない

> > Chrome開発版や他のブラウザだとブレークするのか？
> 通常のChromeとFirefoxでブレークするのを確認した

>>54が引用されてるが、それはお前の言う「ハンドリングしてない予期しない例外」
とは別の「ハンドリングしてないreject」の話だぞ
>>54の一行目にそう書いてあるだろ

それより

> まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが
> 気を効かせて例外を通知してくれるって事を言ってんのに

について具体的にコードでも書いて説明してくれよ
日本語じゃまともに通じてないんだからその方がお互い手っ取り早いだろ？
0058デフォルトの名無しさん2015/01/05(月) 20:47:12.39ID:xBMPeqox
これは「ハンドリングしてないreject」としてのレス

>>56
> 通常のChromeとFirefoxでブレークするのを確認した

まずは確認だが、Chromeで"Pause On Caught Exceptions"は外してるよな？
あれはハンドリング「してる」例外でもブレークするからここでは邪魔になる
その上で、rejectをハンドリングしている

Promise.resolve(true).then(function(v) {
　throw new Error('then');
}).catch(function(e) {
　console.log(e);
});

はブレークしないが、rejectをハンドリングしていない

Promise.resolve(true).then(function(v) {
　throw new Error('then');
});

はブレークするのを確認した、ということで間違いないか？

俺のChrome 39ではどちらもブレークしない
(通常の「ハンドリングしてない例外」はもちろんブレークする)
もしChromeの設定が必要なら教えて欲しい
0059デフォルトの名無しさん2015/01/05(月) 20:56:09.22ID:xBMPeqox
これも「ハンドリングしてないreject」としてのレス
例外ではなくrejectの話ということがより明確になるようにコードを修正した

rejectをハンドリングしている

Promise.resolve(true).then(function(v) {
　return Promise.reject(new Error('then'));
}).catch(function(e) {
　console.log(e);
});

はブレークしないが、rejectをハンドリングしていない

Promise.resolve(true).then(function(v) {
　return Promise.reject(new Error('then'));
});

はブレークするのか？

ちなみにQを使う場合はQ.getUnhandledReasons()で
「ハンドリングしてないreject」の一覧を取得できる
nodeではsetInterval()で定期的にログ出力すればデバッガの必要性は低い
0060デフォルトの名無しさん2015/01/05(月) 22:13:35.53ID:gHiAPMtv
>>57
> process.nextTick()もsetImmediate()もsetTimeout()もそうなってるよ
調べもせずに適当な事言うなよ
少なくともsetTimeout()は絶対違う

他は日本語が意味不明
Promise.resolve(true).then(function(v) {
　throw new Error('then'); ← ここでデバッガがブレークする
});
アホなお前はこれでも理解出来ないと思うが、俺はこれ以上説明しない

> nodeではsetInterval()で定期的にログ出力すればデバッガの必要性は低い
糞みたいな負け惜しみすんなよw
0061デフォルトの名無しさん2015/01/05(月) 22:22:33.23ID:gHiAPMtv
> 少なくともsetTimeout()は絶対違う
捕捉するがタイムアウト時間を1msとかにすれば、99.9%実用上問題無いだろう
だが「確実」に非同期にするという事とは全く意味が違う

>>58
> もしChromeの設定が必要なら教えて欲しい
デバッガのデフォ設定では飲み込まれて無反応だ
さんざんケチつけてる割にはそんな簡単な設定も分からんか
ただ、激しくスレチな事なんで無理もないからそろそろ黙ってくれ
0062デフォルトの名無しさん2015/01/05(月) 23:31:48.05ID:xBMPeqox
>>60
> 調べもせずに適当な事言うなよ

調べて言ってるけど？
まずは仕様

https://html.spec.whatwg.org/multipage/webappapis.html#timers

"timer initialisation steps"の10で"Return handle, and then continue running this algorithm in parallel."
となっていて、コールバックが呼び出されるのは14の"Queue the task task."によってだ
そしてNodeの実装

https://github.com/joyent/node/blob/v0.10/lib/timers.js#L194

203行目でTimeoutオブジェクトを作って225行目でactive()に渡してる
175行目からのactive()はリストにTimeoutオブジェクトを追加してるだけ
どうやってもsetTimeout()がreturnする前にコールバックが呼ばれることはない

> 少なくともsetTimeout()は絶対違う

その根拠は？ お前は主張するばっかで根拠は何も示さないのな

>>61
> 捕捉するがタイムアウト時間を1msとかにすれば、99.9%実用上問題無いだろう
> だが「確実」に非同期にするという事とは全く意味が違う

お前「非同期」の意味わかってる？ タイムアウト時間は非同期とは一切関係ないぞ
setTimeout()は常にコールバックを非同期に実行する
ただしコールバックが実行されるまでの時間は指定したとおりになるとは限らないだけだ
特にネストした呼び出しでは0〜3msを指定しても最低4msは待たされる(上の仕様に書いてある)
だが常に非同期だ
0063デフォルトの名無しさん2015/01/05(月) 23:36:20.18ID:xBMPeqox
>>60
> 他は日本語が意味不明

お互いになw でもJSのコードは分かっただろ？
だからお前が言いたいこともコードで示してくれって何度も言ってるわけだ
なんでコードで書かないんだ？

> Promise.resolve(true).then(function(v) {
> 　throw new Error('then'); ← ここでデバッガがブレークする
> });

それだけだと"Pause On Caught Exceptions"を有効にしてるようにしか見えないな
その場合ブレークするのは内蔵Promise一切関係ないからな
catch()してるケースではどうなんだ？ ブレークしちゃうんじゃねーの？
>>59のPromise.reject()版でもブレークするのか？ しないんじゃねーの？

> アホなお前はこれでも理解出来ないと思うが、俺はこれ以上説明しない

それこそ負け惜しみだろw
「しない」じゃなくて「できない」んじゃねーの？

> > nodeではsetInterval()で定期的にログ出力すればデバッガの必要性は低い
> 糞みたいな負け惜しみすんなよw

繰り返すけどここはサーバサイドJSスレなんでな
動かしっぱなしのサーバではロギングして調べる方が基本なんだよ
ぶっちゃけこのスレでもNodeでデバッガ普段使いしてるヤツの方が少数派じゃね？
他の人どうよ？
0064デフォルトの名無しさん2015/01/05(月) 23:38:49.17ID:xBMPeqox
>>61
> デバッガのデフォ設定では飲み込まれて無反応だ
> さんざんケチつけてる割にはそんな簡単な設定も分からんか

わからんな
頼むから教えてくれよ
煽るより少ない文字数で終了するだろ

> ただ、激しくスレチな事なんで無理もないからそろそろ黙ってくれ

何を今更w
>>55とか他の人も興味あるかもしれないだろ
そんな簡単な設定ならさっさと書いてくれよ
0065デフォルトの名無しさん2015/01/05(月) 23:41:57.54ID:gHiAPMtv
>>62
This API does not guarantee that timers will run exactly on schedule.
って書いてある
いつ実行されるか保証してないじゃん
上の方のa += 1;を実行するまでに100msの時間が掛かったとすると、その前に実行される可能性がある
0066デフォルトの名無しさん2015/01/05(月) 23:57:22.85ID:gHiAPMtv
昔WebkitかFirefoxのPromiseの実装を見た時に、これで非同期にしてんのかと思った事があった気がするから
とりあえずソースをあたったみるから待ってろ
それで全て解決だ
ソースを落とすには滅茶苦茶時間掛かるし、ブラウザで探すにしても時間が掛かる

> わからんな
> 頼むから教えてくれよ
デベロッパーツールを出して一番右にある黒丸に縦二重線のPause on exceptionsを押しといてリロードだよ
0067デフォルトの名無しさん2015/01/05(月) 23:59:55.31ID:xBMPeqox
>>65
> いつ実行されるか保証してないじゃん

それ俺が書いた

> ただしコールバックが実行されるまでの時間は指定したとおりになるとは限らないだけだ

のことな

> 上の方のa += 1;を実行するまでに100msの時間が掛かったとすると、その前に実行される可能性がある

その可能性はないんだよ
ステップの10でリターンした「後」、残りのステップは並列に実行される可能性がある
その一つのステップ14でコールバックを実行するタスクがキューに入れられる
タスクはキューに入れられるだけで実行はされない
そしてそのタスクがキューから取り出されて実行されるのは制御がイベントループに戻った後だ
お前の言うa += 1;の実行が終わらない限り制御がイベントループに戻ることはない
だからsetTimeout()はタイムアウト時間に一切関係なく常に非同期だ
詳細は"14. Queue the task task."のリンク先を見てくれ

そんな難しく考えなくてもシングルスレッドなんだからわかりそうなもんだがw
0068デフォルトの名無しさん2015/01/06(火) 00:14:54.50ID:KFlyuGQs
>>67
> そしてそのタスクがキューから取り出されて実行されるのは制御がイベントループに戻った後だ
イベントループに戻るのはsetTimeout()の直後の位置だ (a += 1;の前)
0069デフォルトの名無しさん2015/01/06(火) 00:22:50.21ID:oSSj0EiH
>>66
> デベロッパーツールを出して一番右にある黒丸に縦二重線のPause on exceptionsを押しといてリロードだよ

それ黒丸に縦二重線を押して出てくるパネルにあるチェックボックスのことだよな？
それ「Pause on exceptions」じゃなくて「Pause On Caught Exceptions」だよな？
俺がこれまで書いた↓全然読んでなかったのかwwwwww

>>58
> まずは確認だが、Chromeで"Pause On Caught Exceptions"は外してるよな？
>>63
> それだけだと"Pause On Caught Exceptions"を有効にしてるようにしか見えないな

"Pause On Caught Exceptions"って有効にすると

try {
　throw new Error('err'); //ここでもブレークする！
} catch (e) {
　console.log('handled');
}

こんなのまでブレークしちゃう代物なわけよ
内蔵Promiseがどうとか一切関係なく、自前のライブラリだろうがなんだろうが
どこでも例外スローするとブレークするオプションなわけじゃん
内蔵Promiseでないと実装できないとかって話と何の関係ないよな？

>>24
> > ・飲み込まれた例外をデバッグ出来る
> そりゃ、ライブラリ内部のcatch内にブレークポイントを張って待ちかまえていれば
> 可能だが毎回そんな事すんのか？いやするわけない
> そして例外がスルーされて何も起きない

↑の説明は"Pause On Caught Exceptions"と矛盾してることはわかるか？
0070デフォルトの名無しさん2015/01/06(火) 00:29:21.55ID:oSSj0EiH
>>68
> イベントループに戻るのはsetTimeout()の直後の位置だ (a += 1;の前)
は？ え？ え？

setTimeout(function() {
　...
}, 0);
// (a)
a += 1;

こういうコードで(a)の位置でイベントループに戻ると思ってるわけ？
いやいやいや、いくらなんでもそれは。。。 あー
0071デフォルトの名無しさん2015/01/06(火) 00:39:58.23ID:KFlyuGQs
>>69
あっそう、俺はFirefoxしか使ってないからChromeの事はそれでいいと思ったよ
Firefoxだと
try {
　throw new Error('err'); // ここでブレークしないで
} catch (e) {
　console.log('handled');
}
Promise.resolve(true).then(function(v) {
throw new Error('then'); // ここでブレークする
});
になる
もはやV8とも関係無くて悪いなw
0072デフォルトの名無しさん2015/01/06(火) 00:44:09.33ID:KFlyuGQs
>>69
ChromeでPromiseをブレークさせる方法は無いのか何らかの方法があるのか調べておくよ
0073デフォルトの名無しさん2015/01/06(火) 00:48:43.95ID:oSSj0EiH
>>72
別にいいよ、開発版で取り組んでるから
https://code.google.com/p/v8/issues/detail?id=3093
https://code.google.com/p/chromium/issues/detail?id=393913
0074デフォルトの名無しさん2015/01/06(火) 02:04:56.21ID:KFlyuGQs
俺が勘違いしていた
Promiseの仕様的にイベントループが1回以上発生する事を保証しないといけないから
setTimeout()では完全ではないということだな
はいおしまい
0075デフォルトの名無しさん2015/01/06(火) 05:03:53.45ID:D9r7QrzV
まだやってんのか…
0076デフォルトの名無しさん2015/01/06(火) 15:07:59.00ID:LUJGb7UT
ざっと読んでたら、
イベントループ＝非同期
って話してるのかと思った(笑)
何に対しての同期かにもよるだろうけどね
0077デフォルトの名無しさん2015/01/06(火) 19:05:27.58ID:oSSj0EiH
>>76
JSの世界(特にコールバック絡み)で同期・非同期といったら

function foo(function callback() {
　... //(1)
});
... //(2)

(1)->(2)で実行されるのが同期 (Array.forEach()とか)
(2)->(1)で実行されるのが非同期 (setTimeout()とか)

「Effective JavaScript」の項目67とか以下とか参照

http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/
0078デフォルトの名無しさん2015/01/06(火) 20:55:50.08ID:Xd0L/8rv
>>16
> 「Promiseを理解しないと非同期のメリットを生かせない」ってのは
> 表層しか理解してないって証だわな

真理だったな
0079デフォルトの名無しさん2015/01/06(火) 22:25:56.23ID:QIYM1JY4
JavaScriptはシングルスレッドだけど
NodeのIOは非同期、つまり別スレッドで行われる
0080デフォルトの名無しさん2015/01/06(火) 22:40:06.78ID:oSSj0EiH
>>78
まぁまぁw

>>79
別スレッドなのはファイルだけでネットワークやパイプはメインスレッドだよ
Windowsではファイルもメインスレッドかもしれん
0081デフォルトの名無しさん2015/01/06(火) 23:38:13.20ID:KFlyuGQs
>>78
ただ煽ってるだけだろ
理由を述べよ
すぐに理由を述べられなければただの煽りと認定する (たぶん無理だろうけど)
0082デフォルトの名無しさん2015/01/06(火) 23:44:03.55ID:KFlyuGQs
>>80
何がまぁまぁだよw
お前もどうせ無能なんだろ
とりあえずすぐに理由を言ってみろよ、言えないくせに
0083デフォルトの名無しさん2015/01/07(水) 14:59:21.93ID:R3Z2NWM/
>>80
そんな事無いだろ
メインスレッドでやる意味ないし
0084デフォルトの名無しさん2015/01/07(水) 20:07:44.58ID:OxX2nn0Y
>>83
逆に考えるんだ
ネットやパイプはノンブロッキングI/Oで多重化できるからワーカスレッドでやる意味の方がない
UnixのファイルI/OはそれができないからワーカスレッドでブロッキングI/Oせざるを得ない
以下のNoteにもそういうことが書いてある

http://nikhilm.github.io/uvbook/filesystem.html

ソースだとファイル系の操作(839行目〜)はみんな以下のPOSTマクロを使ってる

https://github.com/libuv/libuv/blob/v1.x/src/unix/fs.c#L97

その中のuv__work_submit()がワーカスレッドに処理を依頼する関数
ネットやパイプではそんなことしてない

詳細を知りたければブロッキングI/O、ノンブロッキングI/O、
多重化、非同期I/Oと順に説明してる解説を読むといい
そしてUnixでは本物の非同期I/Oは事実上ないことを知るw
0085デフォルトの名無しさん2015/01/13(火) 15:11:04.11ID:LHG94Mlu
ついに本日 io.js 1.0.0 が正式リリース。
v8エンジンのおかげで node より大幅速度向上。

本日は io.js の誕生日であるとともに node の命日ともなりましたﾅﾑﾅﾑ
0086デフォルトの名無しさん2015/01/14(水) 08:06:57.60ID:EnBoJmyV
2ちゃんもお別れの日が近い気がする
0087デフォルトの名無しさん2015/01/14(水) 22:24:56.52ID:knoTvZIn
CPUを使う処理の速度は確かに向上している
が、node-gypがライブラリをダウンロード出来ずビルドに失敗したり
v8のAPI変更でnanがコンパイル失敗したり
ちょっと困った

node-gypはどこに対策版があるか分からず自分でちまちまファイル名を直した
nanは本家リポジトリに対策版のブランチあり
0088デフォルトの名無しさん2015/01/14(水) 22:26:05.98ID:knoTvZIn
io.jsのことね

後、Path追加するように指定してインストールしたつもりなのに何故か追加されてない
0089デフォルトの名無しさん2015/01/16(金) 14:43:45.88ID:sXdFjxSo
nodejs、Javascriptに詳しくないけど。
基本が非同期ってのが面倒。
同期のJavascriptとは別物だ。
同期のソースコードに適合させたい。
これはどうやったら実現できますか。 downloadでの同期処理。


data = download("http://www.google.co.jp/";);
dataに対する処理;
0090デフォルトの名無しさん2015/01/16(金) 14:55:27.50ID:sXdFjxSo
こんなふうにやっても待ちが出来ず。


url = "http://www.google.co.jp/";;
data = download(url);
console.log(data);


function download(url) {
data = undefined;
request = require('superagent');
request.get(url)
.end( function(resp){ data = resp.res.text; });
for(i=0; i<10 && data==undefined; i++) setTimeout(null, 500);
return data;
}
0091デフォルトの名無しさん2015/01/16(金) 15:07:39.68ID:WEjV0wIz
同期のJavascriptってレアだな
generatorで擬似的にやるかasync/awaitを待て
0092デフォルトの名無しさん2015/01/16(金) 17:26:44.61ID:x/KvFbcS
>>90
こんなんでいいんじゃない？

var httpsync = require('httpsync');

var url = "http://www.google.co.jp/";;

var req = httpsync.get(url);
var res = req.end();
var data = res.data.toString();

console.log(data);
0093デフォルトの名無しさん2015/01/16(金) 17:44:25.51ID:TPIs3k36
JavaScriptで大量のリクエストを処理するなら
使うべきはメインスレッドをブロックする同期IOなんかじゃなくて
当然非同期IOだよな
0094デフォルトの名無しさん2015/01/16(金) 17:52:01.40ID:+cZ2zonb
にわか
0095デフォルトの名無しさん2015/01/16(金) 20:23:30.77ID:lUd0kLGp
本家のネスケが最初に作ったサーバサイドjavascriptは同期でマルチスレッドだった
0096デフォルトの名無しさん2015/01/16(金) 22:01:52.67ID:TPIs3k36
nodeの公式が同期とスレッドを使ったプログラムをこき下ろしてるぞ
Thread-based networking is relatively inefficient and very difficult to use.
とか

http://nodejs.org/about/
0097デフォルトの名無しさん2015/01/16(金) 22:55:28.32ID:gHXWvVDx
そりゃ最初のサーバサイドJSなんてほとんど20年前の代物だからw
こんなのあるから暇なヤツは聞いてみれ(ES7ってことはasync/awaitだろうけど)
https://player.fm/series/lately-in-javascript-podcast/asynchronous-javascript-without-callbacks-in-ecmascript-7-lately-in-javascript-podcast-episode-50
0098デフォルトの名無しさん2015/01/18(日) 09:56:30.56ID:5wNJLYNH
promise使うといたらええんや
0099デフォルトの名無しさん2015/01/18(日) 17:21:38.41ID:ckxewJLG
promiseじゃ同期っぽく書けない
0100デフォルトの名無しさん2015/01/18(日) 21:30:04.25ID:ohcYLEp3
perlに帰ろう
0101デフォルトの名無しさん2015/01/19(月) 13:14:20.73ID:KroxEeJe
StackOverFlowのスコアを上げとくと、何かいいことがあるかもしれない。

『【翻訳】多種多様な基準から見るプログラマの市場価値』
http://postd.cc/how-much-do-you-cost/
0102デフォルトの名無しさん2015/01/19(月) 15:04:48.09ID:ys/y/3Zn
くだらねぇｗ
0103デフォルトの名無しさん2015/01/19(月) 15:22:29.17ID:CuAQcBp8
2chで質問スレの住民やって回答してます！(ｷﾘｯ
みたいな面接のネタAAがあったけど似たようなもんだな
0104デフォルトの名無しさん2015/01/19(月) 15:25:22.24ID:KroxEeJe
2ちゃんも回答者にポイントくれないかな
0105デフォルトの名無しさん2015/01/20(火) 11:00:22.26ID:OQruBfwA
非同期だとデバッグ大変じゃないかな。
ブレークポイントで止まってる間もsetIntervalは裏で動いちゃって、待ち行列が出来たりするでしょ。
0106デフォルトの名無しさん2015/01/20(火) 21:07:01.09ID:GWZYH+JO
メーリングリストみたら0.11.15が出るらしいけど使われているv8がとても古い
0107デフォルトの名無しさん2015/01/21(水) 00:17:31.01ID:n3ucrSzY
>>106
それもip.jsがフォークした理由の一つ
0108デフォルトの名無しさん2015/01/21(水) 00:17:39.27ID:pMVsv6gb
>>106
それもip.jsがフォークした理由の一つ
0109デフォルトの名無しさん2015/01/21(水) 03:02:39.08ID:1UCwofHM
>>106
それもip.ry(
0110デフォルトの名無しさん2015/01/21(水) 13:36:21.00ID:W+aNuk6y
レスをフォーク
0111デフォルトの名無しさん2015/01/21(水) 17:08:05.52ID:VHJhqEss
何？また別のがフォークしたの？
0112デフォルトの名無しさん2015/01/21(水) 17:19:04.46ID:PfvOP5lB
node-gypはio.js 1.0.3では動かないけどpangypは動作するらしい
0113デフォルトの名無しさん2015/01/22(木) 21:04:56.44ID:lh8u5jbd
lodash 3.0 リリース間近！

https://github.com/lodash/lodash
3.0-preから-preが外れました！


スレが多すぎてどこに書けばいいかわからないので
関連スレすべてにマルチポストしています。m(__)m
0114デフォルトの名無しさん2015/01/22(木) 21:47:19.08ID:IMAN2WtB
Chrome 40(v8 3.30)のPromiseはハンドリングされてないrejectのデバッグがサポートされて>>59で書いたようになった
しかしio.js 1.0.3(v8 4.1)の組込デバッガは未対応
0115デフォルトの名無しさん2015/01/23(金) 12:41:14.68ID:iNKYdZ74
io.jsもvert.xのように一時期話題になるだけでnode.jsの代替にはならないよ
0116デフォルトの名無しさん2015/01/23(金) 16:47:56.23ID:CFiT31YS
なんでvert.xが出てくるんだよ、全然別物じゃん
node.jsとio.jsは名前とリポジトリが違うだけでコードも開発者もほぼ同じだぞ
oracleの支配を嫌ってhudsonからフォークしたjenkinsに近い
0117デフォルトの名無しさん2015/01/23(金) 19:35:57.38ID:Ztpp331L
性能ではもうio.jsが圧勝みたいだよ。
あとv8のバージョンもnodeはまだ3.*なのにio.jsはもう4.*に上がってる。
0118デフォルトの名無しさん2015/01/23(金) 19:50:06.18ID:raMd+kOH
　　　　　　,,､､､,,,、,,z､,_,､、
　　　　 ,r三ミﾐﾐヾヾﾐt,X(ﾘﾐ､,
　　　　 ミﾆﾐﾘ" ゛ミ､"゛ﾘ"ミﾐ､>
　　　　三ﾆ"　　　　　　　　゛ミi
　　 ,､_ミ爪",,-____　　　　　　,,<､.
　　 i ﾄ､ﾐﾐ　,r‐- ､｀`'ニ=‐、.彡ﾘ.
　　 ヾ,iﾊ゛.´ _,,､_ 　i.;　_,.　｀ 彡'i)
　　　 ｀､j,'　 `ﾟ''´:.ﾉ i::<･ゝ) .ﾊン 　　　　　！？
　　　　　i, 　 ｀ ,､/　i_　｀`　,r'
　　　,r〃'i　 ,r'ヽ、 _,〉　　/. 　
　　 /i:ﾄ､;;i, 　ﾐ=_‐_-, 'i　/ヽ__
r-‐'´i::::ﾊ;;ヾ、‐‐-､　 ノ´/i:::'i｀i‐- ､_
::i' .l:i 'i::::i ヾ;;`‐---‐'i':/ i､ 'i::!　i::::i　｀
:i'　i:|　!:::l _,r.､;;;;;,r''´ヽi. ll::i　i::i　l:::'
0119デフォルトの名無しさん2015/01/23(金) 20:13:06.13ID:CFiT31YS
つか性能差のほとんどはv8のバージョンの差だろ
io.js = node.js 0.11 + v8 4.1 + より多くのバグ修正
使う側はnode.js 0.12の次のバージョンから名前がio.jsに変わるくらいの認識でいいんだよ
0120デフォルトの名無しさん2015/01/23(金) 20:42:13.28ID:YkgE7zny
紛らわしいのは、io.jsは1.0といいながら
実態は0.10と0.11の間ぐらいなんだよな。

0.10よりかは機能が増えているかもしれないが、
0.11よりかは劣っているわけで。
0121デフォルトの名無しさん2015/01/23(金) 21:00:22.09ID:CFiT31YS
>>120
そりゃ誤解
io.jsのv1.xブランチはnode.jsのv0.12ブランチから派生したものだ
https://github.com/iojs/io.js/issues/218

io.js v1.0はnode.js v0.12と互換つってるしちょくちょくマージもされてる
0122デフォルトの名無しさん2015/01/23(金) 21:20:29.05ID:YkgE7zny
v0.12はまだリリースされていないんだから、
v0.12より劣っているのは確かだな。
0123デフォルトの名無しさん2015/01/23(金) 21:58:14.56ID:CFiT31YS
い み ふ

紛らわしいことがあるとするなら、io.jsはsemver採用で開発版と安定版を
バージョンで区別できないことかな
今v1.0.3まで出てるがこれは全部開発版で、安定版はたとえばv1.0.15からみたいなことになる
io.jsの安定版はおそらくnode.js v0.12が出た後にそれをマージしてからリリースされるだろう
0124デフォルトの名無しさん2015/01/23(金) 22:00:50.56ID:gqb5Qh0S
ベンチマーク見たがたいして違いないしnodejsのままでいいや
0125デフォルトの名無しさん2015/01/23(金) 22:05:12.22ID:YkgE7zny
>>123
semverだと、1.0が正式版なので、
0.12相当なのに1.0を名乗っているから
最初からおかしいんだよ。
0126デフォルトの名無しさん2015/01/23(金) 22:11:14.23ID:4o3NBFe/
なんで1.0.0-betaとかじゃないんだろとかは思う
0127デフォルトの名無しさん2015/01/23(金) 22:15:52.01ID:CFiT31YS
>>125
semverではpre-releaseはMUSTじゃなくてMAYだし、実装が不安定でもAPIを固定すれば1.0.0を名乗れるだろ
どこがおかしい？
0128デフォルトの名無しさん2015/01/23(金) 22:17:49.38ID:CFiT31YS
"-beta"がpre-releaseの部分な
0129デフォルトの名無しさん2015/01/23(金) 22:28:31.93ID:So6YQ3Pc
そんな事ないうんどろの差だよ
0130デフォルトの名無しさん2015/01/23(金) 22:43:16.31ID:YkgE7zny
>>127
だからMAYだろ？
MAYとはいえ、決まっているわけで、
その決まってることを意味なく破るのはなぁ。
0131デフォルトの名無しさん2015/01/23(金) 22:57:18.12ID:So6YQ3Pc
こんなに広く使われているのに何でずっとバージョン0.xなんだYO
0132デフォルトの名無しさん2015/01/23(金) 23:02:13.80ID:CFiT31YS
>>130
付けてもいい (MAY)
付けるべき (SHOULD)
付けなくてはならない (MUST)
付けてはならない (MUST NOT)

MAYなんだから付けなくて何の問題もないし、何も破ってない
だいたいsemverの主目的はAPIの互換性を示すもので実装の安定性を示すものではない
0133デフォルトの名無しさん2015/01/23(金) 23:22:59.99ID:CFiT31YS
>>131
安定するより早く広まってしまった
元々v0.12の次の安定版がv1.0になると言われてたんだがv0.12が出ないうちにgruntなんかが出てきちゃったから…
0134デフォルトの名無しさん2015/01/23(金) 23:30:41.62ID:OPE+Wqmb
安定する前に分裂とかｗ
0135デフォルトの名無しさん2015/01/23(金) 23:32:29.92ID:t01wISfr
結局のところ、io.jsは安定してないのに、
1.0を名乗っているわけで。
0136デフォルトの名無しさん2015/01/23(金) 23:41:14.77ID:CFiT31YS
だから、io.js v1.0はAPIを固定したという決意表明なのよ、semver的に
実装の安定ではなく
この辺はsemver自体が広く理解されないと紛らわしいよね
0137デフォルトの名無しさん2015/01/23(金) 23:44:10.78ID:XIEI9xsC
いや、だから本家がAPIを固定してないから
0.xという名前なわけで、なぜAPIを固定してないかというと
そこにまだ変えるべき問題があるからなわけで。

変えるべき問題があるのに、1.0を表明しているからダメだって言ってるんだよ。
これが後々、悪いAPIだけど変えるに変えられない状態を生み出してしまう。
0138デフォルトの名無しさん2015/01/23(金) 23:57:49.08ID:CFiT31YS
よくわからんな

・node.jsはsemverではないので0.xだからといってAPIを固定してないとは言えない
・node.js v0.11はすでにv0.12のRCであり、この系においてはAPIは固定されたとみなせる
・io.jsはAPIを変えたければv1.1.x、v2.0.0などにバージョンアップすればいい (すでにv1.1向けのPRも存在する)

何か問題が？
0139デフォルトの名無しさん2015/01/24(土) 00:05:56.67ID:erhfYoBY
io.jsはAPIが固定されてなく、
同じくAPIが固定されてないnodeのバージョンアップに
追尾することで、APIが変更になる。

つまりio.jsはこれから互換性がないバージョンアップを
短期間に繰り返すことになり
今使うべきじゃないプロダクトだねって話になる。
0140デフォルトの名無しさん2015/01/24(土) 12:14:35.97ID:WI6RO/N+
OH "io.js is a way better name than node.js" --Ryan Dahl. #forreal
https://twitter.com/mikeal/status/558787202919186432
0141デフォルトの名無しさん2015/01/24(土) 12:24:15.12ID:H0FHHZ5/
どうせタイプ数が少ないからとか言う、そういジョークだろうなｗ
0142デフォルトの名無しさん2015/01/24(土) 12:25:38.81ID:XGtAEOPl
検索する側からしたら迷惑な名前
0143デフォルトの名無しさん2015/01/24(土) 13:39:24.09ID:XGGvY8P/
io.jsも最初はsocket.io.jsがヒットしたりioとjsが含まれる関係ないサイトがヒットしたりして検索しにくかったけど
今はio.jsで検索しやすくなったし
ググラビリティー(検索しやすさ)の問題は知名度で改善する面もあると思う

何しろ線を意味する一般名詞が多大な知名度のおかげでIMサービスの名称としてググラビリティーをほとんど損なわずに成り立ってるわけだし
0144デフォルトの名無しさん2015/01/24(土) 15:35:38.09ID:WI6RO/N+
念のため書いておくと、>>140のポイントは語ったのがnode.jsの作者で命名者でもあるRyan Dahlってとこな
消息不明みたいなものだったから「ライアン生きてたっ！」とまずは喜ぶべき
■ このスレッドは過去ログ倉庫に格納されています