【node.js】サーバサイドjavascript 3【io.js】

1 名前：デフォルトの名無しさん mailto:sageteoff [2014/12/27(土) 18:40:07.70 ID:MwQYLNUR.net] pythonやrubyやPHPと同じ土俵でjavascriptが使えるようになりました。 サーバサイドjavascriptについて語りましょう。 node.js - googleが開発したV8エンジン上で実行できる処理系 nodejs.org/ io.js - node.js 互換で Joyent の影響からの脱却を目指す処理系 iojs.org/ Rhino - JVM上で実行できる処理系 https://developer.mozilla.org/ja/Rhino io.js の経緯 stackoverflow.com/questions/27309412/what-is-the-difference-between-node-js-and-io-js javascriptはrubyと比較してもかなり速い shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=yarv 基礎から学ぶNode.js gihyo.jp/dev/serial/01/nodejs node.jsの概要とアプリケーション開発の準備 gihyo.jp/dev/serial/01/realtimeweb/0002 前スレ 【node.js】サーバサイドjavascript 2【Rhino】 peace.2ch.net/test/read.cgi/tech/1358937029/ 【node.js】サーバサイドjavascript【Rhino】 toro.2ch.net/test/read.cgi/tech/1310087535/ 2 名前：デフォルトの名無しさん mailto:sage [2014/12/27(土) 18:40:56.41 ID:MwQYLNUR.net] あけおめことよろ 3 名前：デフォルトの名無しさん mailto:sage [2014/12/27(土) 18:42:30.42 ID:Cc0RXd7d.net] yesde.js 4 名前：デフォルトの名無しさん mailto:sage [2014/12/27(土) 22:58:41.76 ID:2nBgrTKt.net] node.jsって流行るの？ 5 名前：デフォルトの名無しさん mailto:sage [2014/12/27(土) 23:02:11.92 ID:+XmnrNOH.net] 流行ってる 流行ってた 6 名前：デフォルトの名無しさん [2014/12/31(水) 18:23:54.12 ID:ySiWi1AV.net] gulp 4 って使えるの？ 7 名前：デフォルトの名無しさん mailto:sage [2014/12/31(水) 19:45:43.48 ID:qeTCZCBA.net] node-webkitやatom-shellはスレチ？ OKなら、� 8 名前：｡どっち採用するか凄く迷ってるんですけど [] [ここ壊れてます] 9 名前：デフォルトの名無しさん mailto:sage [2015/01/01(木) 16:37:51.69 ID:PtOebUla.net] 「node.js覚えればクライアントもサーバもjavascriptだから他の言語覚えなくてすむぜ！」 と安易に寄ってきたにわかがイベントドリブン周りが頭に入らなくてすごすご退散するケースが多そう 10 名前：デフォルトの名無しさん mailto:sage [2015/01/02(金) 00:11:15.27 ID:8He3Adur.net] >>8 俺はそれに近い 11 名前：デフォルトの名無しさん mailto:sage [2015/01/02(金) 00:20:31.87 ID:mlj15zVW.net] とりあえずPromiseを理解しないと非同期のメリットを生かせないだろうな 12 名前：デフォルトの名無しさん mailto:sage [2015/01/02(金) 00:22:52.63 ID:1zRkX7fJ.net] >>8 自己紹介乙 13 名前：デフォルトの名無しさん mailto:sage [2015/01/02(金) 00:54:28.10 ID:buPBY5a2.net] Promise って非同期処理のコールバックを比較的キレイに書ける、 って以外のメリットって何かあるの？ 14 名前：デフォルトの名無しさん mailto:sage [2015/01/02(金) 14:54:02.14 ID:mlj15zVW.net] >>12 綺麗っていうのが曖昧な表現だがおおむね以下のメリットがある ・コールバック関数から更にコールバックを呼ぶ時にネストが深くなるのを防げる 　(ソースが三角形になるのを防げる) ・A,B,Cの内ABが終わっててかつCが終了した直後に処理を開始するとかの制御が簡単になる 　(つうか自前でやろうとするとかなり面倒な事になる) ・エラー処理を一纏めにしたりなんかの制御が簡単になる これを綺麗に書けるの一言でくくってしまったら他のメリットは無い 15 名前：デフォルトの名無しさん mailto:sage [2015/01/02(金) 16:32:56.94 ID:buPBY5a2.net] >>13 レスさんくす。 >>8 に対しては、むしろコールバック関数を使ったやり方のほうが node.jsの動作を理解できていいんじゃないかと思ったのでね。 16 名前：デフォルトの名無しさん [2015/01/03(土) 11:31:09.56 ID:duDbuP4G.net] >ソースが三角形 漏れはチベット国旗みたいになる 17 名前：デフォルトの名無しさん mailto:sage [2015/01/03(土) 22:51:09.22 ID:Uo8+VTLN.net] Promiseなんて実際綺麗に書きやすいライブラリの一つってだけだから 「Promiseを理解しないと非同期のメリットを生かせない」ってのは 表層しか理解してないって証だわな Promiseと非同期をjQueryとDOMにでも置き換えて考えてみるといい 18 名前：デフォルトの名無しさん mailto:sage [2015/01/03(土) 23:38:28.29 ID:AuGuhWCh.net] >>16 実際生かせないだろ > ・A,B,Cの内ABが終わっててかつCが終了した直後に処理を開始するとかの制御が簡単になる 非同期処理をやってると↑こういう事がしょっちゅうあるけど、どうやって自前でやんの？ 単にフラグだらけの糞みたいなソースが出来るだけだ 19 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 00:06:14.65 ID:NffMCEWR.net] その程度は自前でも並列と逐次の小さなヘルパ関数を用意するだけで十分きれいに書けるだろ 実際はそんなもん自前で書かずにasync使ってたけどな ECMA標準だから仕事じゃPromise使ってくけどそんなのは所詮表層の話に過ぎないよ PromiseよりStreamが適することも多いし 20 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 00:10:50.21 ID:kuXg+7pG.net] >>18 どうせマルチスレッドvs非同期処理の事いってんだろ そんな事言ってんじゃねーんだよ スレの流れも読まずに何一人でブチ切れてんだよアホか 21 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 00:18:39.72 ID:LcMrfHes.net] >>18 一方俺は、asyncもどきを自前で作った。（趣味でだけど） 非同期処理の中でさらに非同期処理をして、それぞれの終了時に指定された関数を呼び出す 可能性があるようなプログラムだったんで、途中頭がこんがらがったけど何とかできたわ。 22 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 00:26:18.12 ID:kuXg+7pG.net] >>20 一応だけど、ブラウザ内蔵のPromiseはJavaScriptで実装出来ない事をしてるから Promise使った方がいいとは思うよ ・渡されたコールバックを確実に非同期で実行する ・飲み込まれた例外をデバッグ出来る ってのがそう 23 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 00:35:28.28 ID:NffMCEWR.net] >>19 どこを誤読するとそうなるんだよwww 並列ってのはPromise.all()やasyncのparallel()のような処理フローのこと 逐次ってのはPromiseのthen()によるチェーンやasyncのseries()・waterfall()のような処理フローのこと 俺の方はスレの流れを読めてると思うぞ 24 名前：20 mailto:sage [2015/01/04(日) 00:38:56.49 ID:LcMrfHes.net] >>21 ブラウザのJavascriptもシングルスレッドじゃなかったっけ？ であれば、 ・渡されたコールバックを確実に非同期で実行する ・飲み込まれた例外をデバッグ出来る はPromise使わなくてもできるよ。使った方が楽だろうけど。 25 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 00:53:04.50 ID:kuXg+7pG.net] >>23 > ・渡されたコールバックを確実に非同期で実行する これはsetTimeout使ったハックがあってほぼ確実なのは可能だけど、 絶対確実な実装はブラウザが内部で実装しないと無理なんだよね > ・飲み込まれた例外をデバッグ出来る そりゃ、ライブラリ内部のcatch内にブレークポイントを張って待ちかまえていれば 可能だが毎回そんな事すんのか？いやするわけない そして例外がスルーされて何も起きない 26 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 00:54:44.21 ID:NffMCEWR.net] >>21 サーバサイドJSスレで「ブラウザ内蔵のPromise」ってw そこはv8のPromise実装って書けよ >>22 QとかBlurbirdはそれらをJSで実装してるわけだからな どうしてJSで実装できないと思い込んだのか謎だ 27 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 00:56:26.84 ID:NffMCEWR.net] 安価ミス、>>25の後半は>>23へのレス あとBlurbirdじゃなくてBluebird 28 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 01:03:40.55 ID:kuXg+7pG.net] >>25 ブラウザ内蔵って…ごめんちゃい QとかBlurbirdはほぼ確実な実装でお茶を濁してる (実用上問題ないけど) 例外の件は>>24の通りだ 29 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 01:21:16.51 ID:NffMCEWR.net] >>27 「お茶を濁してる」について詳しく nodeではprocess.nextTick()かsetImmediate()で確実に非同期にできるが？ v8のPromiseだってマイクロタスクキューに入れられて結局はnodeのイベントループで処理されるのは同じ 例外のデバッグって具体的には？ Promise.catch()にブレークポイント付けれるって話？(それはブラウザ関係ないと思うが…？) もしそうならライブラリがcatchした例外はコールバックの第1引数に渡されるのがnodeの流儀で同じようにできるが？ 30 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 01:41:12.11 ID:NffMCEWR.net] で、>>19は>>18を誤読してたってことでいいのか？ >>22を読んだ上での反論は？ 31 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 01:57:43.71 ID:kuXg+7pG.net] >>28 > nodeではprocess.nextTick()かsetImmediate()で確実に非同期にできるが？ Qとかはnode用やIE用じゃないが、場合分けしてる可能性はある > v8のPromiseだってマイクロタスクキューに入れられて結局はnodeのイベントループで処理されるのは同じ それがJavaScriptで実装出来ない事をしてることじゃなくて？ > 例外のデバッグって具体的には？ 説明が面倒になってきた… Promiseに限った話しじゃないが、ライブラリ内でtry,catchしちゃってると 呼び出し側に例外が来ないって事だ (当たり前の事だけど) で、Promiseの場合は呼び出し側がエラー処理もしてない場合でも、 32 名前：デバッガが気を効かせて例外を上げてくれるってだけだ ま、薄々感づいてると思うが、俺はずっとブラウザ実装の事を言っていた… しかしPromiseが満たすべき一般的な動作仕様を言ってるつもりではある [] [ここ壊れてます] 33 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 02:35:21.46 ID:NffMCEWR.net] >>30 > それがJavaScriptで実装出来ない事をしてることじゃなくて？ nodeではv8のマイクロタスクキューもsetImmediate()もnodeのイベントループで処理されるのは同じって意味な つまりJSのsetImmediate()でコールバックを確実に非同期にできるってこと これはブラウザでも同じはずだ 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ > 呼び出し側に例外が来ないって事だ (当たり前の事だけど) ライブラリの実装依存ではあるが、nodeでは当たり前じゃない nodeでは例外を第1引数としてコールバックすることで呼び出し側に例外を伝えるのが流儀だ だからPromiseでnodeのAPIやライブラリをラップしてもPromise.catch()に例外が渡る (ラッパーはコールバックの第1引数に例外が渡されたらPromise.reject()を呼び出す) >>21を見てから薄々じゃなく確信していた 34 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 02:54:15.95 ID:kuXg+7pG.net] >>31 > 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ setImmediate()がコールバックを確実に非同期に出来るっていう仕様ではないだろ 確実に非同期って意味は setImmediate(function callback() { }); a += 1;みたいななんらかの処理 ←これが実行される前にcallbackが絶対実行されない ことを保証してんの？ そもそも非標準のAPIなんだけど… > ライブラリの実装依存ではあるが、nodeでは当たり前じゃない QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか… Promiseの実装を熱弁してるけど、とりあえずそういう事でいいよ 35 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 03:42:19.87 ID:NffMCEWR.net] >>32 > これが実行される前にcallbackが絶対実行されない ことを保証してんの？ 仕様はそうなってる https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html > そもそも非標準のAPIなんだけど… そこはこのNotesに書いてある"platform code"から好きなものに置き換えてくれ https://github.com/promises-aplus/promises-spec > QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか… >>23（これは俺とは別人）からは「それPromise使わなくてもできるよ」って話をしてるな それは当然JSで書かれたQやBluebirdでもできるってことだから元の話と違ってるわけではない、スコープが広がっただけ で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？ 36 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 04:38:34.06 ID:kuXg+7pG.net] >>33 > 仕様はそうなってる Schedules to run handler immediately after user agent events have been flushed. user agent eventsってなんだ？ a += 1;の実行が終わってからとは言ってないと思うが > そこはこのNotesに書いてある"platform code"から好きなものに置き換えてくれ 置き換えて何だよ？ platform code(要するにJavaScriptでないコード)を実行しろとわざわざ書いてる > 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ 元の質問は↑これ、お前は論点をずらそうとしてるだけだな > で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？ お前眠いのかw 俺はもうもちそうもないが >>30の下の方で言ってるよ 37 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 14:15:40.27 ID:DzK37a2V.net] https://twitter.com/msdev/status/551558635198099457/photo/1 もし1995年にnode.jsがあったら 38 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 14:59:18.44 ID:x8qIKDC6.net] 入れ替えんのがとてつもないボトルネックやな 39 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 16:12:14.10 ID:HFKhuxk5.net] こんな難しい議論理解できないと 綺麗なコード書けない時点で人気出ないだろうね 40 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 16:24:29.87 ID:l0Z2uGSM.net] そんな難しい話かぁ？ 41 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 16:39:24.09 ID:w2TCoU2v.net] >>35 そいつがアホなだけ 42 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 16:44:05.85 ID:CtgO5+tK.net] >>39 ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ 43 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 16:57:31.37 ID:2KBXdzj3.net] その頃にはもうMPC規格が普及して CD-ROMドライブが� 44 名前：W準でついてるというのに(TOWNSユーザー並の感想 [] [ここ壊れてます] 45 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 17:40:22.84 ID:NffMCEWR.net] >>37-38 技術的に難しい話はしてないが、こういう場で会話を成立させるのは難しいなw できれば誰か ID:kuXg+7pG の主張を翻訳して欲しい 46 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 18:06:08.86 ID:NffMCEWR.net] >>34 > a += 1;の実行が終わってからとは言ってないと思うが "5 Processing Model"の4に、5以降は非同期に実行すると書いてある > 置き換えて何だよ？ お前が使ってるブラウザに合わせて読み替えろというだけだ サーバサイドJSスレとしてはnodeで使えるprocess.nextTick()やsetImmediate()で何の問題もない > platform code(要するにJavaScriptでないコード)を実行しろとわざわざ書いてる "paltform code"はプラットフォームごとに異なるコードという意味で それがJSで実装されてようがされてまいがどうでもいい 実のところnodeのsetImmediate()はJSで実装されている https://github.com/joyent/node/blob/v0.10/lib/timers.js#L361 > > 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ > 元の質問は↑これ、お前は論点をずらそうとしてるだけだな いみふ 「ブラウザが内部で実装しないと無理」の対象はPromiseそのものの実装だ Promiseの実装が呼び出すAPIの話じゃない 「stringはブラウザで実装されている」を理由に「stringを使うのはブラウザが内部で実装しないと無理」っておかしいだろ？ "platform code"がブラウザやnodeで実装されていても、それを使うコードはJSで書ける たとえばQはこの辺で"platform code"を呼び分けてる (モダンブラウザだとpostMessage()が使われてるな) https://github.com/kriskowal/q/blob/v1/q.js#L160 これは「ブラウザが内部で実装しないと無理」ではなく普通のJSのコードだ 47 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 18:08:08.79 ID:NffMCEWR.net] >>34 > >>30の下の方で言ってるよ 話がループしてるな… その>>30の以下について > Promiseに限った話しじゃないが、ライブラリ内でtry,catchしちゃってると > 呼び出し側に例外が来ないって事だ (当たり前の事だけど) これはPromiseを実装するQのようなライブラリ側の話だよな？ ライブラリ側がcatchした例外を飲み込んで捨てた場合は確かにそうだが、 QやBluebirdは飲み込まずにPromise.catch()に通知するだろ Promiseを使わない場合でもnodeの流儀ならコールバックの第1引数で通知する だからこれは「ブラウザ内蔵のPromiseはJavaScriptで実装出来ない事をしてる」に該当しない っていうのが>>31で書いたことだ それに対して>>32で > QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか… と返されたわけだが、前述の通り飲み込まずにPromise.catch()で通知されるはずだから そうじゃないっていうなら > で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？ と>>33で尋ねたわけだ その返事が>>34の「>>30の下の方で言ってるよ」だと完全にループ まずは確認だが、 ・QとかBluebirdでは例外が飲まれる って主張してるんだよな？ それならどういうケースでそうなるのか例を示してくれ Promise.catch()に伝わらないケースがもしあるなら、おそらくそれはただのバグだ 48 名前：デフォルトの名無しさん [2015/01/04(日) 19:14:35.42 ID:w9Cj0tkO.net] JavascriptとPHPでだいたいのことはカバー可能という認識でおｋでしょうか？ 49 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 19:32:10.48 ID:zyY9pL0A.net] MySQLかSQLiteも欲しい 50 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 20:18:20.57 ID:w9Cj0tkO.net] やはりMySQLがないと片手落ちなのですね どうもありがとうございます 51 名前：23 mailto:sage [2015/01/04(日) 20:31:31.22 ID:LcMrfHes.net] >>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の通りで、それ以上に言うべきことはないかな。 ただデバッガとかブレークポイントとかの言葉が出ていたから、 必要以上に難しく考えていたんじゃないかという気がしないでもない。 52 名前：23 mailto:sage [2015/01/04(日) 20:43:54.20 ID:LcMrfHes.net] >>43 >たとえばQはこの辺で"platform code"を呼び分けてる (モダンブラウザだとpostMessage()が使われてるな) MessageChannel 知らんかった。。。 node.js では process.nextTick、ブラウザでは setTimeout と使い分けるだけだったよ。 勉強になった、サンクス。 53 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 20:59:25.50 ID:CtgO5+tK.net] >>44 > Promiseを使わない場合でもnodeの流儀ならコールバックの第1引数で通知する 通知しても呼び出し側がハンドリングしてなきゃ意味ないだろ 別にハンドリングしたきゃrejectjをハンドリングすりゃいいんだよ、アホか まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが 気を効かせて例外を通知してくれるって事を言ってんのに お前はなんで分かんないんだよマジで無能だな 54 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 21:02:03.05 ID:CtgO5+tK.net] >>44 お前がPromise使ってプログラムなんかした事ないド素人なのは分かったよ じゃなきゃ、そんな事言う訳ないし 普通はそうだね、で終わる話しを、ドアホのお前がバカみたいに突っこんでるだけなのを オレが暇だから相手してるだけだよ 55 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 22:08:03.31 ID:NffMCEWR.net] 暇ならもう少し相手してもらおうか まず > ・渡されたコールバックを確実に非同期で実行する これが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スレなんだからその辺はお前の方が考慮してくれ 56 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 22:36:38.77 ID:NffMCEWR.net] せっかくなので具体的に こういうコード(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行目で止まったじゃろ 57 名前：デフォルトの名無しさん mailto:sage [2015/01/04(日) 23:45:19.91 ID:NffMCEWR.net] ところで「ハンドリングしてない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開発版や他のブラウザだとブレークするのか？ 58 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 09:46:01.36 ID:mZODWVt6.net] >>50 横から失礼、俺も読んでて意味わからないから質問させてくれ ＞まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが ＞気を効かせて例外を通知してくれるって事を言ってんのに ＞お前はなんで分かんないんだよマジで無能だな 内臓Promiseの利点はデバッガが気を利かせて例外通知をしてくれる、と読めるんだけど、つまり製品に使うと勝手にデバッガが動いてる状態になるから開発時以外は使っちゃいけないって事でOK？ それともPromiseには何らかのデバッガが内臓されている感じなのかな？もしそうだとして、デバッガが動作してることを前提でコードを組むのがPromiseの使い方って事？ もし前者なら(特に将来的に)仕様がどうなるかは環境依存って事になるから、Promiseは使ってはいけないんじゃないだろうか？ 59 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 12:38:50.48 ID:A9O4oHD7.net] 面倒だがこうなったらしょうがない少し付き合ってやる >>52 > > ・渡されたコールバックを確実に非同期で実行する > > これがJSで実装できないって主張は間違いだったということでいいのか？ setImmediate()の仕様は、渡されたコールバックを次のJavaScriptの命令が確実に実行された後に 実行するとは読めなかったが、もし内部の実装がそうなってるのであれば、setImmediate()で 実装できるよ ただし、本当に内部の実装がそうなってるかどうかはお前が確認して報告しろ > Chrome開発版や他のブラウザだとブレークするのか？ 通常のChromeとFirefoxでブレークするのを確認した >>55 > つまり製品に使うと勝手にデバッガが動いてる状態になるから開発時以外は使っちゃいけないって事でOK？ デバッガは普通のブラウジング時には有効になってないよ 有効にするにはブラウザごとにやり方が違うから自分で調べてくれ 60 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 20:40:46.70 ID:xBMPeqox.net] >56 > ただし、本当に内部の実装がそうなってるかどうかはお前が確認して報告しろ process.nextTick()もsetImmediate()もsetTimeout()もそうなってるよ どの関数もreturnして後続のコードが実行されてイベントループに戻るより前に コールバックが呼ばれることはない > > Chrome開発版や他のブラウザだとブレークするのか？ > 通常のChromeとFirefoxでブレークするのを確認した >>54が引用されてるが、それはお前の言う「ハンドリングしてない予期しない例外」 とは別の「ハンドリングしてないreject」の話だぞ >>54の一行目にそう書いてあるだろ それより > まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが > 気を効かせて例外を通知してくれるって事を言ってんのに について具体的にコードでも書いて説明してくれよ 日本語じゃまともに通じてないんだからその方がお互い手っ取り早いだろ？ 61 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 20:47:12.39 ID:xBMPeqox.net] これは「ハンドリングしてない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の設定が必要なら教えて欲しい 62 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 20:56:09.22 ID:xBMPeqox.net] これも「ハンドリングしてない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()で定期的にログ出力すればデバッガの必要性は低い 63 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 22:13:35.53 ID:gHiAPMtv.net] >>57 > process.nextTick()もsetImmediate()もsetTimeout()もそうなってるよ 調べもせずに適当な事言うなよ 少なくともsetTimeout()は絶対違う 他は日本語が意味不明 Promise.resolve(true).then(function(v) { 　throw new Error('then'); ← ここでデバッガがブレークする }); アホなお前はこれでも理解出来ないと思うが、俺はこれ以上説明しない > nodeではsetInterval()で定期的にログ出力すればデバッガの必要性は低い 糞みたいな負け惜しみすんなよw 64 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 22:22:33.23 ID:gHiAPMtv.net] > 少なくともsetTimeout()は絶対違う 捕捉するがタイムアウト時間を1msとかにすれば、99.9%実用上問題無いだろう だが「確実」に非同期にするという事とは全く意味が違う >>58 > もしChromeの設定が必要なら教えて欲しい デバッガのデフォ設定では飲み込まれて無反応だ さんざんケチつけてる割にはそんな簡単な設定も分からんか ただ、激しくスレチな事なんで無理もないからそろそろ黙ってくれ 65 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 23:31:48.05 ID:xBMPeqox.net] >>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は待たされる(上の仕様に書いてある) だが常に非同期だ 66 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 23:36:20.18 ID:xBMPeqox.net] >>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でデバッガ普段使いしてるヤツの方が少数派じゃね？ 他の人どうよ？ 67 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 23:38:49.17 ID:xBMPeqox.net] >>61 > デバッガのデフォ設定では飲み込まれて無反応だ > さんざんケチつけてる割にはそんな簡単な設定も分からんか わからんな 頼むから教えてくれよ 煽るより少ない文字数で終了するだろ > ただ、激しくスレチな事なんで無理もないからそろそろ黙ってくれ 何を今更w >>55とか他の人も興味あるかもしれないだろ そんな簡単な設定ならさっさと書いてくれよ 68 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 23:41:57.54 ID:gHiAPMtv.net] >>62 This API does not guarantee that timers will run exactly on schedule. って書いてある いつ実行されるか保証してないじゃん 上の方のa += 1;を実行するまでに100msの時間が掛かったとすると、その前に実行される可能性がある 69 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 23:57:22.85 ID:gHiAPMtv.net] 昔WebkitかFirefoxのPromiseの実装を見た時に、これで非同期にしてんのかと思った事があった気がするから とりあえずソースをあたったみるから待ってろ それで全て解決だ ソースを落とすには滅茶苦茶時間掛かるし、ブラウザで探すにしても時間が掛かる > わからんな > 頼むから教えてくれよ デベロッパーツールを出して一番右にある黒丸に縦二重線のPause on exceptionsを押しといてリロードだよ 70 名前：デフォルトの名無しさん mailto:sage [2015/01/05(月) 23:59:55.31 ID:xBMPeqox.net] >>65 > いつ実行されるか保証してないじゃん それ俺が書いた > ただしコールバックが実行されるまでの時間は指定したとおりになるとは限らないだけだ のことな > 上の方のa += 1;を実行するまでに100msの時間が掛かったとすると、その前に実行される可能性がある その可能性はないんだよ ステップの10でリターンした「後」、残りのステップは並列に実行される可能性がある その一つのステップ14でコールバックを実行するタスクがキューに入れられる タスクはキューに入れられるだけで実行はされない そしてそのタスクがキューから取り出されて実行されるのは制御がイベントループに戻った後だ お前の言うa += 1;の実行が終わらない限り制御がイベントループに戻ることはない だからsetTimeout()はタイムアウト時間に一切関係なく常に非同期だ 詳細は"14. Queue the task task."のリンク先を見てくれ そんな難しく考えなくてもシングルスレッドなんだからわかりそうなもんだがw 71 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 00:14:54.50 ID:KFlyuGQs.net] >>67 > そしてそのタスクがキューから取り出されて実行されるのは制御がイベントループに戻った後だ イベントループに戻るのはsetTimeout()の直後の位置だ (a += 1;の前) 72 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 00:22:50.21 ID:oSSj0EiH.net] >>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"と矛盾してることはわかるか？ 73 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 00:29:21.55 ID:oSSj0EiH.net] >>68 > イベントループに戻るのはsetTimeout()の直後の位置だ (a += 1;の前) は？ え？ え？ setTimeout(function() { 　... }, 0); // (a) a += 1; こういうコードで(a)の位置でイベントループに戻ると思ってるわけ？ いやいやいや、いくらなんでもそれは。。。 あー 74 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 00:39:58.23 ID:KFlyuGQs.net] >>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 75 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 00:44:09.33 ID:KFlyuGQs.net] >>69 ChromeでPromiseをブレークさせる方法は無いのか何らかの方法があるのか調べておくよ 76 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 00:48:43.95 ID:oSSj0EiH.net] >>72 別にいいよ、開発版で取り組んでるから https://code.google.com/p/v8/issues/detail?id=3093 https://code.google.com/p/chromium/issues/detail?id=393913 77 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 02:04:56.21 ID:KFlyuGQs.net] 俺が勘違いしていた Promiseの仕様的にイベントループが1回以上発生する事を保証しないといけないから setTimeout()では完全ではないということだな はいおしまい 78 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 05:03:53.45 ID:D9r7QrzV.net] まだやってんのか… 79 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 15:07:59.00 ID:LUJGb7UT.net] ざっと読んでたら、 イベントループ＝非同期 って話してるのかと思った(笑) 何に対しての同期かにもよるだろうけどね 80 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 19:05:27.58 ID:oSSj0EiH.net] >>76 JSの世界(特にコールバック絡み)で同期・非同期といったら function foo(function callback() { 　... //(1) }); ... //(2) (1)->(2)で実行されるのが同期 (Array.forEach()とか) (2)->(1)で実行されるのが非同期 (setTimeout()とか) 「Effective JavaScript」の項目67とか以下とか参照 blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/ 81 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 20:55:50.08 ID:Xd0L/8rv.net] >>16 > 「Promiseを理解しないと非同期のメリットを生かせない」ってのは > 表層しか理解してないって証だわな 真理だったな 82 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 22:25:56.23 ID:QIYM1JY4.net] JavaScriptはシングルスレッドだけど NodeのIOは非同期、つまり別スレッドで行われる 83 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 22:40:06.78 ID:oSSj0EiH.net] >> 84 名前：78 まぁまぁw >>79 別スレッドなのはファイルだけでネットワークやパイプはメインスレッドだよ Windowsではファイルもメインスレッドかもしれん [] [ここ壊れてます] 85 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 23:38:13.20 ID:KFlyuGQs.net] >>78 ただ煽ってるだけだろ 理由を述べよ すぐに理由を述べられなければただの煽りと認定する (たぶん無理だろうけど) 86 名前：デフォルトの名無しさん mailto:sage [2015/01/06(火) 23:44:03.55 ID:KFlyuGQs.net] >>80 何がまぁまぁだよw お前もどうせ無能なんだろ とりあえずすぐに理由を言ってみろよ、言えないくせに 87 名前：デフォルトの名無しさん mailto:sage [2015/01/07(水) 14:59:21.93 ID:R3Z2NWM/.net] >>80 そんな事無いだろ メインスレッドでやる意味ないし 88 名前：デフォルトの名無しさん mailto:sage [2015/01/07(水) 20:07:44.58 ID:OxX2nn0Y.net] >>83 逆に考えるんだ ネットやパイプはノンブロッキングI/Oで多重化できるからワーカスレッドでやる意味の方がない UnixのファイルI/OはそれができないからワーカスレッドでブロッキングI/Oせざるを得ない 以下のNoteにもそういうことが書いてある 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 89 名前：デフォルトの名無しさん mailto:release age [2015/01/13(火) 15:11:04.11 ID:LHG94Mlu.net] ついに本日 io.js 1.0.0 が正式リリース。 v8エンジンのおかげで node より大幅速度向上。 本日は io.js の誕生日であるとともに node の命日ともなりましたﾅﾑﾅﾑ 90 名前：デフォルトの名無しさん [2015/01/14(水) 08:06:57.60 ID:EnBoJmyV.net] 2ちゃんもお別れの日が近い気がする 91 名前：デフォルトの名無しさん [2015/01/14(水) 22:24:56.52 ID:knoTvZIn.net] CPUを使う処理の速度は確かに向上している が、node-gypがライブラリをダウンロード出来ずビルドに失敗したり v8のAPI変更でnanがコンパイル失敗したり ちょっと困った node-gypはどこに対策版があるか分からず自分でちまちまファイル名を直した nanは本家リポジトリに対策版のブランチあり 92 名前：デフォルトの名無しさん mailto:sage [2015/01/14(水) 22:26:05.98 ID:knoTvZIn.net] io.jsのことね 後、Path追加するように指定してインストールしたつもりなのに何故か追加されてない 93 名前：デフォルトの名無しさん [2015/01/16(金) 14:43:45.88 ID:sXdFjxSo.net] nodejs、Javascriptに詳しくないけど。 基本が非同期ってのが面倒。 同期のJavascriptとは別物だ。 同期のソースコードに適合させたい。 これはどうやったら実現できますか。 downloadでの同期処理。 data = download("www.google.co.jp/"); dataに対する処理; 94 名前：デフォルトの名無しさん [2015/01/16(金) 14:55:27.50 ID:sXdFjxSo.net] こんなふうにやっても待ちが出来ず。 url = "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; } 95 名前：デフォルトの名無しさん mailto:sage [2015/01/16(金) 15:07:39.68 ID:WEjV0wIz.net] 同期のJavascriptってレアだな generatorで擬似的にやるかasync/awaitを待て 96 名前：デフォルトの名無しさん [2015/01/16(金) 17:26:44.61 ID:x/KvFbcS ] [ここ壊れてます] 97 名前：.net mailto: >>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); [] [ここ壊れてます] 98 名前：デフォルトの名無しさん mailto:sage [2015/01/16(金) 17:44:25.51 ID:TPIs3k36.net] JavaScriptで大量のリクエストを処理するなら 使うべきはメインスレッドをブロックする同期IOなんかじゃなくて 当然非同期IOだよな 99 名前：デフォルトの名無しさん [2015/01/16(金) 17:52:01.40 ID:+cZ2zonb.net] にわか 100 名前：デフォルトの名無しさん mailto:sage [2015/01/16(金) 20:23:30.77 ID:lUd0kLGp.net] 本家のネスケが最初に作ったサーバサイドjavascriptは同期でマルチスレッドだった

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef