【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>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
コネクションが再利用されるとしても、
ファイル要求は別に行われるだろうが 要求されるまでもなくプッシュできる
キャッシュとの絡みで今んとこ絵にかいた餅だが ふーん
そういう妄想は同人誌即売会で売ってるといいよ それよりもminifyが未だにes2015を正式対応してないの早くなんとかしてほしい。ブラウザがes2015サポートしてても結局es5で吐き出してる babel使えば？
babel自体にminify入ったろ？ >>591
おー。愚痴ってみるもんですな。
typescript使ってたんだけどbabel挟んでみようかな。 typescript使ってるならビルドした後minifyすればいいだろ jsでデスクトップアプリケーションが作成できるelectronでソフトを作りたいのですが、
http通信のためのモジュールであるrequestモジュールを、main processからrequireするといろんなプロパティを持ったオブジェクトが返ってきてその中の関数でhttp通算できるのですが、
renderer processからrequireするとただのrequestという名前の関数オブジェクトが返されるだけで使い物にならないです。
pc通信でrenderer processからmain processにhttp通信を代行してもらうしかhttp通信をrenderer processで扱うための方法はないですか？ >>595
renderプロセスはブラウザと同じなのでfetch使えばいいですよ >>598
そりゃサポートはされるだろ
結合しないと遅いってだけなんだから >>599
モジュール化するほうがファイル増えて遅くなりそうなんだが >>600
だからwebpackでビルドして結合するんだよ >>582
> ウェブサーバーのプラグインでJavaScriptファイルをimport定義に従って
> 結合するという仕組みができるかもしれないがこれもビルドを配信時に行うってだけ
事実誤認も甚だしい
パックする仕組みは配信からの要求で考えられた
それをトランスパイルとかいう歪な仕組みを進めている連中が取り込んだだけ
逆だね >>602
うん
だからhttp配信という構図だとパックする必要があるからimportがあまり意味がないというのは間違ってないとおもうんだが 正しいか正しくないかでなく
自分が最後に喋って締めないと気が済まない人種というのがいるのだ
マウンティング症候群を併発していることが多い
ようするにキチガイ >>605
それって相手もそうじゃないとそんな状態が発生しなくね
どっちかが最後にレスしなくてもいいと思ってるならいつまでも会話続かなくね >>607
自分はするけど相手がするのは許せない人なんでしょ 初めてインストールする初心者なんですが、インストールしようとすると
下記エラーが出てインストール出来ません。
There is a problem with this Windows Installer package.
A DLL required for this install to complete could not be run.
Contact your support personnel or package vendor.
色々ググってみましたが解決方法がさっぱりです。
どなたか対処方法をご存じでしょうか？
ご意見を戴ければ幸いです。 検索すると解決法がでて来てるじゃん
それをやったけど解決しないというのか?
それとも検索する能力がないのか?
はっきりしろ >>614
その通りです。英語どころか日本語にすら不自由しているバカです。
よろしければ解決方法をお教え戴けないでしょうか？ >>615
win版はとにかく問題がおおくMSが公式にインストール順序公開してたぞ
ぐぐってみろ >>617
npm5も
yarnよりは遅いけど高速化＆lockファイル追加 つーかむしろリリース早くないか？
どうしちゃったの最近 いやん、6にしなきゃなぁと思ってたら8がでちゃったよ おれ4のまま使ってるんたけど6とか8は何が違うの？ ■ このスレッドは過去ログ倉庫に格納されています
