【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>449
promiseでは全てのケースをカバーできない→正しい
だからpromiseはいらない→そんなこと言ってない
Observableでpromiseのケースをカバーできる→正しい
だからpromiseはいらない→こう言っている >>460
> なんかの勉強会でcancelable promiseの標準化は頓挫したと聞いた
そしてObservableの標準化が進んでいる promiseで十分なケースでわざわざobservable使うメリットあんのかよ >>464
promiseとobservableはインターフェースが違うから互換性がない。
だからライブラリを作るならば両方に対応しなければならない。
またtoPromise()などでobservableからPromiseに変更するなんて
面倒なことをしなければならない場合もある。
promiseとobservableの両方に対応しなくて良いのがメリットだ >>465
は?
それならobservableなんて対応しなけりゃいいだけじゃねーか
なんで両方に対応しなきゃいけねーんだよ >>467
殆どの要件でcancelは必要だから結局Fetch APIみたいに
cancelするための別の仕様が出てくる。
だから最初からobservable一本にしておけばいいという話
急ぎすぎてPromiseを標準化してしまったのは黒歴史
Promiseを使ったFetch APIも黒歴史 >>468
fetchのことしか考えてねーのかよ
fsの非同期apiはキャンセル不可だがこれobservableにする意味あんのかよ
fetchが黒歴史なのは正しい
promiseじゃなくstreamだろってsubstackも突っ込んでた > fsの非同期apiはキャンセル不可だがこれobservableにする意味あんのかよ
あると思うけど?
俺は200MBを超えるファイル×数十個を "並列で" サーバーに送信したことがあるのだが、
もしメモリに全部読み込んでいたら、マシンによってはメモリ不足になっただろう。
だから特定のチャンクごとに読み込んで送信していたわけだが、当然キャンセルもしたいし
どのファイルが何%処理完了したかの状況も表示したくなる。
そんときはループを使って、チャンクごとにデータを読み取って処理したわけだが、
もしfsがobservableであれば、メモリに全部読み取ることなく
一定のチャンクごとに処理する簡単な方法も提供されただろう。 setTimeoutなんかもclearTimeoutみたいにキャンセルするメソッドがあるし、
時間がかかるからこそ非同期にしているわけで、時間がかかる処理を
キャンセルしたいことがありえないなんてAPIが本当にあるのだろうか? >>470
それはnodeじゃ昔からstreamでやってるやつだがその話じゃねーよ
今のnodeではcallbsckを取るfs.fstatとかの話だ >>472
俺が話をしているのはブラウザ版だ
nodeの話はしてねーよw >>471
時間がかかる処理をキャンセルじゃなくて、待つのをキャンセルするじゃね? >>477
それは言い方の違いでしかないよ
nodeでcallbackを使うやつの話であれば、そもそもなんで
nodeはPromiseを使わなかったのか?の話になるだろ。
それはcallbackを使う方が速いのと、
何度もイベントを発生する必要があるものがあるからだろうな。
つまり、Promiseでは要件に耐えられないから
Promiseではなくcallbackを使ったんだよ。
fs.fstatでは何度もイベントが発生するわけじゃなくても、
何度もイベントが発生することが可能なcallbackを使っている。
それは一度しかイベントが発生しなくてもPromiseではなく
Observableを使ってよいのと同じ考えだ。 >>478
promiseの仕様がいつできたかも知らないのかよ
nodeはその前からあるんだよ
スレ違い野郎は消えろ http://stackoverflow.com/questions/30299613/why-does-nodejs-not-use-promise-for-the-readfile-api
Node’s early iterations used Promises in its nonblocking API. However, in February 2010,
Ryan Dahl made the decision to switch to the now-familiar callback(err, results...)
format, on the grounds that Promises are a higher-level construct that belongs in “userland.”
英語わかるか?
Nodeは最初Promise使っていて、callbackに変えたって書いてあるんだぞ (JavaScriptの)Promiseはいつできたんだっけな?
前に調べたんだが忘れたな。
ここを見る限り2009年なのは間違いないが。
http://wiki.commonjs.org/index.php?title=Promises&oldid=516 そのpromiseはes6のpromiseとは別物だ nodeでobservableに相当するのはstream
fs.fstatはstreamを使わない
それが答え
以上 >>482
それは当たり前だが、Promiseを捨てた理由は同じだ
>>483
fs.fstatはPromiseを使わない。
それが答えだろう?w > nodeでobservableに相当するのはstream
ちなみに、streamを知らない人に説明しておくと、
streamが使ってるのはPromiseではなくcallback >>484
promiseを使わない理由がキャンセルできないからじゃないのは分かってんのかよ
システムコールレベルでキャンセルする方法がないのにobservableにするメリットあんのかって問いに答えてねーだろ
nodeは単発にcallback、連発にstreamで使い分けてる
大は小を兼ねるとは限らないんだよ システムコールレベルって何の話?
Win32APIとかレベルの話してるの?
独自用語で話すんなよ 何やこいつ
キャンセルする必要がない単発はPromiseでいいし、キャンセルが必要か連発ならobs使えばいいって話だろ
しゅうきょーせんそーかな? 単発だからってキャンセルする必要が無いことにはならないんだが?
言ってる意味わかる? Observableが得意なのはキャンセルだけじゃなくて
並列処理もなんで、fs.fstatを並列で実行したいときにも
簡単にかけるというメリットも有るな いくら君らが言い合っても、現実はかわらないでしょ?
今ある仕様がすべてで文句かるなら他の言語つかいなよで終わる話しじゃないの?
生産性のない答えもない事で争って暇すぎるだろ >>490
「キャンセルする必要がない場合は」
よく嫁 こいつもしかしてIT速報の管理人か?
転載禁止やぞ。対立煽りはNG スプーンとお玉の関係に似てる。
ジャムをすくうのにお玉を使ったら逆に不便だろ。そこは適切にスプーンを使え。
キャンセル処理がPromiseだと絶対無理というわけでもないし、Rxが必要とも思えないプロジェクトで無理やりRxを使う必要もない。 >>493
> 「キャンセルする必要がない場合は」
それはまずないだろうねw レスの文体からして前からJSスレに常駐してる荒らしでしょ
コピペブログ管理人もやってたのかは知らんが >>487
システムコールってwikipediaにもエントリあるのに
unix/linux系はダメなwindows君か
どうりでダメなわけだ >>498
分かってないなw
なんでシステムコールの話がでてくるんだってことだよ。
nodeのAPIと、OSのシステムコールを
一対一で直接結びつける必要はないっつーの
nodeのAPIは単純な一命令でも、内部の実装は
何回もシステムコール呼んだって良いわけだ。
それが分かってないから、お前はシステムコールが
キャンセルできるかどうかなんて言い出したんだろ
こっちは全部お見通しだってーの fetchはキャンセルできる必要があるが、
fetchの戻り値をObsevableにするのは駄目。
Obsevableって一様な幾つものデータを受け取るのに向いているので
fetchのように幾つかの段階で全然違うものが帰って来るのには向いていない。
単純に、Responseにabortメソッドを付けるのが良いと思う
勿論途中のStreamをObsevableにするのはとても良いと思うけど、
それを含んだ全体をするのはおかしい。 というか考えたら分かると思う。
キャンセルしたいのはfetchではなく、DLなのだから。
やっぱりCancelToken以外の解は無いと思うよ。 > キャンセルしたいのはfetchではなく、DLなのだから。
fetchはデータ送信もするんだが?
その場合キャンセルしたいのは何だよ >>500
> 単純に、Responseにabortメソッドを付けるのが良いと思う
fetchの戻り値はpromiseであってresponseではない。
responseはpromiseのthenの時に渡される。
promiseのthenが呼び出されるのはfetchの処理が完了した後。
つまりresponseを取得したとき=fetchし終わった時に
abortするのは遅すぎる >>499
なにを見通してるのかさっぱり分からんがnodeは低水準のapiを提供するものだ
そうすれば複数のシステムコールを組み合わせた高水準apiはユーザーレベルのライブラリで実現できる
だからfsモジュールは意図的にposixの薄いラッパーになっていてキャンセルはない >>505
> nodeは低水準のapiを提供するものだ
どこにそんなことが書いてあるのか?
nodeの立場はブラウザと同じだ。
JavaScriptの実行環境だ。
お前の理屈だと、ブラウザは低水準のAPIを提供するものということになる。 >>505
> だからfsモジュールは意図的にposixの薄いラッパーになっていてキャンセルはない
じゃあ、例えば、fs.lstatSync は posixのどの薄いラッパーなのか言ってみ >>506
> 仕様にはstreamが追加されてる
どっちみち仕様を加えるなら
Observableにした方がいいだろうな。 しかもPOSIXは非同期I/Oをキャンセルする機能あるじゃんwww
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/aio_cancel.3.html
aio_cancel - 完了していない非同期 I/O リクエストをキャンセルする
POSIX.1-2001, POSIX.1-2008. >>507
https://nodejs.org/api/fs.html
File I/O is provided by simple wrappers around standard POSIX functions.
>>508
lstat
>>510
posix aioはほとんどのosで実装されてないしnodeでもサポートしてない >>510
細かく言うとposix aioはほとんどのos kernelで実装されてない
gnuがユーザーレベルのライブラリとして実装したものがあるだけ manだとlstat(2)に対して>>510のaio_xxx(3)なのでシステムコールじゃないことが分かる >>504
fetch apiが返すpromiseはfetchが完了してからresolveするわけではない
完了してからresolveするのはres.text()が返すpromise >>514
>>508のlstatSyncは非同期じゃない >>515
> fetch apiが返すpromiseはfetchが完了してからresolveするわけではない
完了してからだよ。正確にはレスポンスが返ってきてから、
データの受信が完全に完了してからではない。
でないと、Response.statusが取れるわけがないだろう? >>518
それではシステムコールにあるPromise相当のものは何?w >>519
そう、だから完了してからじゃないじゃん
最初のチャンクが届いたらresolveする
「fetchの処理が完了した後」は明らかな間違い >>520
システムコールにはない
単にワーカースレッドでlstat呼ぶだけ >>521
Fetchの処理はリクエスト投げてレスポンス戻すところまでだよ。
ダウンロードが終了するまでの話は最初からしてない
で、Fetchのキャンセル(thenが発動する前)はPromiseでできるの?
できないでしょ?
そこに新しい仕様が必要ならObservableを使えば良いわけさ。 >>522
だろう? Promiseを含めて「システムコールの軽いラッパー」と
お前が呼ぶならば、Observableを含めたって「システムの軽いラッパー」になる >>523
fetch apiがpromiseベースでバカなのは何年も前から言われてるし俺も言ってきたからそこに反論する気はない >>524
キャンセルできなくて単発で結果が決まるシステムコールのラッパーにpromiseよりobservableを選ぶメリットは? システムコールとライブラリの違いをわかってないやつがいそうだから、用語をシステムAPIかOSのAPIで統一してくれ >>523
何度も説明してるが、キャンセルは必要だが、Observableはそぐわない
CancelTokenのようなものじゃないと実際齟齬が出るし
その流儀に則って真似して使いやすいように色んなAPIを実装していくのは大変 俺がobservableの話で並列処理の話を始めると
すぐにキャンセルの話に変えるやつってなんなんだろうねw
わざとなのかな? >>528
正しくは並行処理だが常に必要となるわけではない
必要ならpromiseをobservableでラップすればいいだけ
そのために無駄に高機能なapiを土台にするメリットはない
シンプルの上にリッチを乗せることは有意だが逆は無意味だ > 正しくは並行処理だが常に必要となるわけではない
絶対に必要ないならいらんだろうさ
常に必要となるわけではない=必要な場合もある。
ならば同じやり方でやったほうが楽 長さ1の配列があればスカラ値の変数はいらない
let x=1
let y=2
let z=x+y
これは配列が必要な場合と同じやり方で
let x=[1]
let y=[2]
let z=[x[0]+y[0]]
ってやった方が楽
なるほど Observableだけでなく、jQueryもLodashもそうなんだけど、
配列をスカラのように扱うことができるんだよね。
1と2以上を同一化して処理できる。
例えばquerySelectorAllは配列を返す。$()だとスカラ値を返す
どちらもセレクタから複数の要素を検索しているようだけど、この違いによって
querySelectorAllではループ処理が必要になるが、jQueryではループ処理が不要になる
Promiseも単数だから並列しようと思ったら配列が必要になってループも必要になる
つまり>>533でいう後者の書き方
Observableであれば単数も複数も同じように処理できるから、>>533の前者の書き方で
複数の対象を単数と同じ書き方で並列に処理できる。 querySelectorAllが配列を返すなんてとんと知りませんでしたわ そもそも「配列」という言葉の定義がない
因みにNodeListは@@iterator対応の予定がずっとある jQueryしか使わないゆとりだから下のレイヤーのことは知らないんだろ 一年に1,2回はtoArrayをどうするかの話題で盛り上がるよね
Array、TypedArray、@@iterator、length、Array.isArrayとか沢山楽しい話できるよね >>541
https://azu.github.io/slide-what-is-ecmascript/slide/12.html
Stage 0: Strawman
アイデア
から抜け出したら、もう一回知らせてくれ
せめてStage 3にならなければ評価する価値もない stage1のobservableも評価する価値がない
よってこの話題完全終了 50歩100歩ってやつだな。
差は2倍もあるということだ デバッグ用にconsole.logで出力を行ってるんだけど、foreverで起動するときはどこにも出力されてないって事でいいのかな? >>545
Optionsを観ると以下のようになってる。
-o OUTFILE Logs stdout from child script to OUTFILE
-e ERRFILE Logs stderr from child script to ERRFILE ln -s -f /dev/null /dev/stdout Converting circular structure to JSON
at JSON.stringify
自分なりにdeepCopyつもりのコードで
上記エラーが出た場合に、原因なコードを簡単に見つける方法ってどんなのがありますでしょうか? circular structur
原因書いてますやん >>551
まさにピッタリの解説でした。ありがとうございました。 循環参照を持っていてもちょっと関数噛ましてテーブル2つに変換すればJSONに落とし込むことは可能だよ 以下のように表記を統一するクラス(またはデータベース)でありますでしょうか?
'php' => 'PHP' ,
'perl' => 'Perl' ,
'javascript' => 'JavaScript' , 思い出してください w
「自然言語処理 "単語の正規化" 」でググってみましたがズバリ思っているようなのはヒットしませんでした。
どなたか是非! つうか全部小文字の単語を直したいだけの辞書なら
通常の固有名詞辞書にちょっと手を加えればいいだけじゃん freetaggerとか昔使ったことあるけど、javaScriptなんかの表記の統一は辛かったような。
isDisabledのiはどうするのとか、結局プロジェクト向けのスクリプト書いた気がする。 >>559
結局はそうだよな
完全な答えがあるものじゃないし ■ このスレッドは過去ログ倉庫に格納されています