【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
何やこいつ
キャンセルする必要がない単発はPromiseでいいし、キャンセルが必要か連発ならobs使えばいいって話だろ
しゅうきょーせんそーかな？ 単発だからってキャンセルする必要が無いことにはならないんだが？
言ってる意味わかる？ Observableが得意なのはキャンセルだけじゃなくて
並列処理もなんで、fs.fstatを並列で実行したいときにも
簡単にかけるというメリットも有るな いくら君らが言い合っても、現実はかわらないでしょ？
今ある仕様がすべてで文句かるなら他の言語つかいなよで終わる話しじゃないの？
生産性のない答えもない事で争って暇すぎるだろ >>490
「キャンセルする必要がない場合は」
よく嫁 こいつもしかしてIT速報の管理人か？
転載禁止やぞ。対立煽りはNG スプーンとお玉の関係に似てる。
ジャムをすくうのにお玉を使ったら逆に不便だろ。そこは適切にスプーンを使え。
キャンセル処理がPromiseだと絶対無理というわけでもないし、Rxが必要とも思えないプロジェクトで無理やりRxを使う必要もない。 >>493
> 「キャンセルする必要がない場合は」
それはまずないだろうねｗ レスの文体からして前からJSスレに常駐してる荒らしでしょ
コピペブログ管理人もやってたのかは知らんが >>487
システムコールってwikipediaにもエントリあるのに
unix/linux系はダメなwindows君か
どうりでダメなわけだ >>498
分かってないなｗ
なんでシステムコールの話がでてくるんだってことだよ。
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をキャンセルする機能あるじゃんｗｗｗ
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相当のものは何？ｗ >>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の話で並列処理の話を始めると
すぐにキャンセルの話に変えるやつってなんなんだろうねｗ
わざとなのかな？ >>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しか使わないゆとりだから下のレイヤーのことは知らないんだろ 一年に１，２回は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
まさにピッタリの解説でした。ありがとうございました。 循環参照を持っていてもちょっと関数噛ましてテーブル２つに変換すればJSONに落とし込むことは可能だよ 以下のように表記を統一するクラス（またはデータベース）でありますでしょうか？
'php' => 'PHP' ,
'perl' => 'Perl' ,
'javascript' => 'JavaScript' , 思い出してください w
「自然言語処理 "単語の正規化" 」でググってみましたがズバリ思っているようなのはヒットしませんでした。
どなたか是非！ つうか全部小文字の単語を直したいだけの辞書なら
通常の固有名詞辞書にちょっと手を加えればいいだけじゃん freetaggerとか昔使ったことあるけど、javaScriptなんかの表記の統一は辛かったような。
isDisabledのiはどうするのとか、結局プロジェクト向けのスクリプト書いた気がする。 >>559
結局はそうだよな
完全な答えがあるものじゃないし package.jsonの"scripts"に書いたコマンドをnpm runで実行する際はnode_modules/.bniがPATHに
追加されますが、これ以外に任意のディレクトリをPATHに追加する方法ってあるでしょうか。 windowsだからpythonのpip以上にnpm厄介だな ありがとうございます。でもwindowsだとうまくいかないなぁ。
"somecommand": "set PATH=%PATH%;<パス> && <コマンド>"
＃<コマンド>は内部でPATH環境変数を使用するスクリプトで、これ自体にはPATHが通っている。
&&の両側のコマンドが同時に立ち上がるんだから当然と言えば当然か。
でもコマンドプロンプトで順次実行する&に変えても結果は同じだった。
bashのexportみたいなのが使えればいいんだけど。 めんどくせぇなぁ、
そのためのnpmライブラリでもあんだろ 他にnpm-run-allとかrimrafとかあればwinでも動くnpm scriptsが書ける ありがとうございます。cross-envでいけました。 node.jsでimportを使うと
SyntaxError: Unexpected token import
ってなるんですが、importに対応したnode.jsはまだ出てないのでしょうか？ >>571
importの使い方を聞いていません
babelとwebpackでimport書いてるので使い方は知ってます
node.js自体がimportを実装しているのかを聞いています *.mjsからはimport出来るようにしようぜ
ってのを結構前に読んだ気がするけど、まだ実装されたないんか? 実装どころか提案文書はドラフトのままだよ
(技術的検証が済んでACCEPTされないと実装に進まない)
検証だけであと1年以上掛かるってさ
なお拡張子(*.mjs)でES moduleかどうか判別する手法は
考え得る限り最低の糞という判断が下されたので無くなる そこはESの管轄外だよ
NodeがWebと合わせる必要もない いやnodeってv8使ってる立場だから何もできんでしょ
間違ってる？ v8はネットワークもファイルシステムも持ってないからimportは環境(ブラウザやnode)に丸投げでしょ Buffer.byteLengthをブラウザ側でも利用できるように移植して欲しい
今時バイトでカウントするにも自力でコード書かないといけないのは無駄すぎる importはJavaScript（EcmaScript）の仕様範疇の中に入れてもいいが、
ブラウザで動かすJavaScriptにおいて、
importはビルド時に解決する問題になるんだよね。
なぜならファイルのアクセス数が増えてパフォーマンス低下につながるから。
JavaScriptファイルを結合することでパフォーマンスをあげるという目的があるから
結合させずに動いたとしても、ビルド時に結合させるという手段は今後も続く。
ウェブサーバーのプラグインでJavaScriptファイルをimport定義に従って
結合するという仕組みができるかもしれないがこれもビルドを配信時に行うってだけ >>581
ブラウザ側で実装する or 自力でコードを書く
の中間に、ライブラリを使うという方法があるよ。
この方法を使えば、既存のブラウザでも動くし
自力でコードを書くムダもない
自力でコードを書けるたぐいのものなら、ブラウザに移植してほしい理由を言うとしたら
「ネイティブで実装されていれば速い可能性がある」であるべきだろう >>582
すごく巨大なファイルへのアクセス数でパフォーマンス低下するか、
CDNで配信されてて、もうすでにブラウザキャッシュに存在するかだと、後者の方が速いと思うけど。 すごく巨大なファイルもCDNで配信されブラウザにキャッシュされるだろw >>586
コネクションが再利用されるとしても、
ファイル要求は別に行われるだろうが ■ このスレッドは過去ログ倉庫に格納されています
