+ JavaScript の質問用スレッド vol.126 +

**デフォルトの名無しさん** · 2018/06/02(土) 14:31:23.04

JavaScript を自ら学ぶ人のための質問スレッドです。

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。

前スレ
+ JavaScript の質問用スレッド vol.125 +
https://mevius.5ch.net/test/read.cgi/tech/1518940081/

（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）

**デフォルトの名無しさん** · 2018/12/04(火) 22:34:21.67

いやでもapacheの説明書とかではjsもhtmlやcssと同じくスタティックコンテンツやけども…

**デフォルトの名無しさん** · 2018/12/04(火) 23:57:54.73

>>631
まあ言っていることは分かるし、その通りだが…

> pause: auto だの draw: lazy だのも素直に実現できる
表現は出来るが、これだと実際やるのはJSだろ。
つまり、今JSで実装しているReactのコードをCSSに持っていくだけであり、速度上のメリットは無い。
それでも外部APIが素晴らしく改善されるので効果はあるが、俺が欲しいのはコレジャナイ。

JSで実装する遅延描画がイマイチなのは、offsetTop等が糞遅いからで、
これは『正しい』offsetTopを要求するAPIしかないからだ。
だから、offsetTopの度にリフローを行い、未描画のDOMがないか全チェックする為、遅くなる。（多分）
ただ、遅延描画に必要なのは「そのページ以上の所まで描画済みか？」であり、
offsetTopの精度が悪くてもいい。（未描画DOMが残ってても問題ない）
そしてこの「精度の悪いoffsetTop」をAPIとして定義しろ、なんていちいちやっていてもキリがないから、
レンダラに介入させろ、というわけだ。
レンダラ内でラスタライズしている時、アドレスからおおよそのoffsetTopなんて一瞬で出せる。
当然高速化するし、きめ細かく制御出来るから、限界まで高速化出来る。
(ただしGPUにやらせようぜなんて話が出てたからそうなると一筋縄ではいかないが）

**デフォルトの名無しさん** · 2018/12/04(火) 23:58:28.93

>>631（続き）
> つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
言っていることは分かるし、確かにこれ以外に現実的路線はないが、果たして上手く行くかね？
今以上にフレームワークが乱立して、なんだかな、な状態になりそうな気がするが。
それも含めてWebだというのならそうだが、
今フレームワークを乱立させてる連中をどうにかして一ヶ所に集中させ、一ついい物を作る方が、
皆にとって幸せだと思うがな。
現状のフレームワークなんて全部死に体だし、あれでは浮かばれんだろ。

> 今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
これがかなり無理があるんだよ。
JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが、
実際はC++ヘビーでレンダラやDOMが実行時間の大半を占めてるだろ。
JS側には改善予算（改善しろ）がないんだよ。
かといって、C++側にAPIやフックを用意させるのもかなり無理な話ではあるが、
しかしJSがパフォーマンスの全責任を負うのはそれ以上に『原理的に』無理だ。

強いて言うなら、現状のブラウザは十分高速で、１ページ程度ならレンダリングは一瞬だ。
遅いのは無駄に10ページ分レンダリングしてたりするか、無駄に遅いJSを実行しているからであり、
ここら辺を遅延描画で改善してやれば可能だが、
今はこれを実装する為の「速い（が精度の悪い）offsetTop」がないんだよ。

> それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
現実的にはこの路線しかないからな。これは認める。

**デフォルトの名無しさん** · 2018/12/05(水) 00:18:53.86

きたないコード書いてそうだなあ

**デフォルトの名無しさん** · 2018/12/05(水) 00:27:04.77

>>632
すまん、それはちょっと俺が先走った。
普通の「静的ページ」は君の定義で正しいだろう。

俺は616に書いたとおり、jQueryが活躍するサイトはHTMLがグダグダな場合で、
それはhtmlを自動生成してない場合と認識しているから、
彼はjQuery廚なのもあり、先走ってしまった。

さて、実際yahooニュースをJS無しで確認してみると、
<noscript>が大量に使われているものの、どうでもいい場所ばかりだ。
これなら変にアドブロックするより、JSを切った方がいいのでは…とも思える。
SPAでもないし、ポップアップもない。リンクはいちいちページ遷移する。
これは「静的ページ」だ。

もうちょっとましな作りかと思っていたのだが、
確かにこれで大して問題ないのも事実だな。

もっとも、鯖側で動的にhtmlを生成する場合、
当然画一的なhtmlとなり、IDやclassをきっちり振ることも簡単だから、
jQueryを使う意味はほぼ無いと思う、という主張はそのままだが。
(yahooはjQuery使っているが)

**デフォルトの名無しさん** · 2018/12/05(水) 06:07:21.44

>>637
もう口閉じてろ

ここはお前のような馬鹿が議論する場じゃねぇんだよ。板違いって事知れや間抜け

**デフォルトの名無しさん** · 2018/12/05(水) 07:03:28.49

>>635
>>一ついい物を作る方が
君がそれができるというのならしてみると良い
Webは一度APIを入れると中々消すことができない
だけど流れは早いので慎重に進めすぎるわけにもいかない
それを両方解決できる人間はこの世にいない
今のまま標準に機能を入れ続けていったらそれこそカオスになる
だからそういったリスクはライブラリに押し付けるのが正しい

>>JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが
俺は今あるコードのことを言ってるんじゃない
これからは高レベルなAPIは低レベルなAPIをもとに作っていくことになるのだから
なにか新しい機能を求めたり、今まで難しかったことを素直に実現するため
Houdini含む低レベルAPI叩いたり、それを利用したライブラリを使うときは
その機能のパフォーマンスを含む責任はJSサイドに来ると言っているんだよ

**デフォルトの名無しさん** · 2018/12/05(水) 08:57:03.83

一般人「クライアントからの情報に応じてサーバーサイドでJavaやPHP、Rubyなどで動的にHTMLを生成して返すのが動的ページ、用意してあるHTMLをそのまま返すのが静的ページ」
キチガイ「Javascriptが動いてたら動的ページ！」

なぜキチガイはイカれた頭の中のオレオレ定義をその汚い口からひり出してしまうのか…

**デフォルトの名無しさん** · 2018/12/05(水) 09:46:02.65

>>639
> Webは一度APIを入れると中々消すことができない
> だけど流れは早いので慎重に進めすぎるわけにもいかない
これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
そしてWebが速いって言ったって、結果出来上がっているのはゴミの山であって、
進歩(＝成功したパス＝使えるものとして残った経路）だけ見ればC#の方が断然速い。
事実として今のJavaScriptはC#の後追いでしかないだろ。

> それを両方解決できる人間はこの世にいない
これは「創始者」がこれに近いものとして振る舞う、というのが他言語/OSSの習わしだ。
この点、ブレンダン・アイクが全く出てこないところがJavaScriptの不幸な点ではあるけれど。

とはいえ、現状で現実的判断をするなら、君の言っている方向性しかない。
ただ、カオスにはもうなってると思うけどな。
○○ってフレームワークはどうですか？みたいな質問ばかりなのがそれを如実に示してる。
標準さえ汚れなければいい、という考え方もありだが、
Promiseは要らない子だと俺は思うし、防波堤になりきれてない。

> 君がそれができるというのならしてみると良い
機会があればやるかもしれん。(これは君も同じだと思うが）
俺が今フレームワークとして欲しいのは遅延描画だけで、Houdiniでは無理だからすぐにはやらないね。
ただ、どっちかと言えば俺が試してみたいのはフレームワークではなくJavaScript自体の直接的拡張であり、
JSエンジンの低レベルAPIについて提供するような方向になっているか知ってれば教えて欲しい。
例えば async とか、ああいう言語拡張をする為のJSそのものの低レベルAPIだ。

**デフォルトの名無しさん** · 2018/12/05(水) 18:04:37.79

>>636
全くもって。

**デフォルトの名無しさん** · 2018/12/05(水) 20:58:57.31

>>641
>>これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
その場合でも旧バージョンは旧エンジンで動かせば良いのだから
しかしWebでは旧サイトは旧ブラウザで見れば良いとは言えない
JSもしかり、機能を非推奨としても、新しい機能との兼ね合いを定義しないといけないし
廃そうとしても10年以上かかる

>>結果出来上がっているのはゴミの山
WebAPIをゴミの山と言うのは流石に言いすぎだと思う
１つ１つ思い返してみても、ゴミだったねと言えるAPIはそう多くない

>>ブレンダン・アイクが全く出てこないところ
間違っている
彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
彼が慎重なおかげでJSはまだ「失敗」していない
勢いのまま進んでたら失敗していたであろう瞬間はいくつもあった

とは言え、今まで話してきたのはほとんどWebAPIについてだ
JSとWeb違う　彼がWebに口出す責任はない
そもそもWebとは皆の総意の中に秩序を見出す形で作られるものなのだから
皆がその時実現したいと思っていることを実現できるようにするのが正しいWebだ
だから流れは速い

それをプロプライエタリで創始者が全て管理するプラットフォームと比べて、あれが悪いこれが悪いというのは間違っている
なぜならそれは男がいて女がいるようなものだから
男が女らしくなったら男じゃないし、女が男らしくなったら女じゃない
男に女らしくないとか、女に男らしくないとか言うのは根本的に間違っていること
男らしいのが好きか、女らしいのが好きか、という話でしか無い

**デフォルトの名無しさん** · 2018/12/05(水) 21:01:06.04

>>641
>>○○ってフレームワークはどうですか？みたいな質問ばかり
いやいや、それが理想なのに、質問がまだまだ少なすぎるくらいだよ
というか、カオスになったら、モジュールの検索のしやすさや、そのためのスレを立てることが必要になるはずだ
でもまだそういった、「これを実現するためにどのライブラリが良いんだろう」という質問がなく、
具体的なライブラリばかり質問に挙がるのだから、全然まだまだってことだ

>>Promiseは要らない子
Promiseがどうして要らない子だと思うのかさっぱりわからない
Promiseとasync-awaitの関係は他と比べても無難で普通だ
Kotlinの用に中断可能なスレッドの組み合わせでやるのも面白いが、
基本的に「スクリプト言語である」はJSは、何かの対象を操作するためのものであって、
例えばWebならレンダリングスレッド上でイベントを受け取ったり操作したりすることが基本の動作であるから
今の仕組みになるのが最も自然と言える

>>言語拡張をする為のJSそのものの低レベルAPI
アイディアは昔から出てるが、これこそ正に流行り廃りが激しく未開拓な分野
安易に入れてしまうと後々公開するので、マクロ的な機能はずっと後
ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい

**デフォルトの名無しさん** · 2018/12/05(水) 23:32:43.96

>>643
> いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
これは技術的にはそうだが、実際はいきなりは壊してない。
JSと同じく、一旦obsoleteにして様子見し、衰退を待ちつつ、だ。
JS界隈ならちょうどjQueryと同じだ。
そこそこ互換性を壊しつつ、どのバージョンを使うかはユーザー選択だ。

だからこの意味で「メジャーアップデートのときに互換性を壊すことができる」を利点とするなら、
それはjQueryが素晴らしくフィットするわけだし、実際そうだから蔓延ったわけだろ。
ならずっとjQueryをポリフィルライブラリとして使えばいいだけだ。
実際そういう人もいるだろう。

> 彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
そうなのか。ならそれは正しい姿だ。

> 正しいWebだ
いややはり買いかぶりすぎだよ。
これは君だけではなく、最近の連中はみんなこんな感じだが。他言語も含めて。
自分が乗っかっているプラットフォームが正義だ、と思いこみたがっている。

実際の所、プロプライエタリにもオープンにもそれぞれの良さはある。
そしてWebは実質Google/MS/Appleによる準プロプライエタリだし、
C++仕様委員会の方が裾野も広くてオープンだ。
が、そもそもこんなのはどうでも良くて、
上位階層で「気に入らなければ使わない」という自由が保障されているから、
外部から見てどういう状況か明確に分かれば問題ない。
この意味で、ブラウザ上で動く言語がJSに限定されている現状は「プロプライエタリ」以上に大問題なわけだが、
お前らはこれを問題だとは認めないわけだろ。
まあこれもWebAssemblyで改善されそうだし、正しい方向に向かってはいるが。

**デフォルトの名無しさん** · 2018/12/05(水) 23:34:08.33

>>644
> 全然まだまだってことだ
なるほどそっちの立場か。それは理解した。
俺は「適切に制限されている方がいい」という立場だから、見方は異なるが、ここを合わせる必要はない。

Promiseについては君の立場なら「あり」だろう。
俺の立場なら、ほぼ async で間に合うのだから「要らない」し、
そもそもパクリ元のC#にpromiseなんて無いのに「要るわけがない」だろ、となる。
それ以前に、promiseが必要なのはいわゆるcallback地獄だが、
これも非同期なのに無理に同期的に書いた結果であって、
最初から非同期で書けばそんなことにはならないし。

> ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい
ASTは正直言って要らん。あれはローレベルすぎる。
俺が欲しいのはJSパーサに対してコードを注入出来るものと、Proxyの超豪華版だね。
ただまあ、全体的にそちらに向かっているとは理解した。

ちなみにdocument等、いわゆるグローバルをフック出来るようになるかは分かる？
ReactでJSXが必要になるのはdocumentに対する操作を全部VirtualDOM側にフックする為で、
documentそのものをフック（上書き）出来ればAPIの外面上の違いは極めて少なく出来る。
(jQueryのコードみたいに全部 $(document)してくれてれば$の上書きで簡単にフック出来るから、
jQueryはこの意味では逆転ホームランの可能性を秘めているわけだが。
というか、DOM操作を全て$()でフックしてくれてるjQueryとvirtualDOMは技術的にはかなり相性がいいはずだが、
全く話題になってないところを見ると、virtualDOMやってる連中もjQueryは死ね、と思ってるんだろうな）

**デフォルトの名無しさん** · 2018/12/06(木) 00:03:12.65

準プロプライエタリｗｗｗｗｗ
広義の強制連行ｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/12/06(木) 00:04:54.72

話が長い
プロプライエタリの意味が分かってないんだろうなぁとは思った

**デフォルトの名無しさん** · 2018/12/06(木) 03:08:30.00

>>879
お前みたいなヴァカに比べたら在日はみんな天才だよ
ITオンチ丸出しの恥ずかしいロートル野郎だな

**デフォルトの名無しさん** · 2018/12/06(木) 04:20:19.55

読んでる人偉いな

**デフォルトの名無しさん** · 2018/12/06(木) 12:44:28.29

パクリ元のC#だか言ってる時点で御里が知れてる
C#にTaskとasync-awaitの絡みが入る前からdojoでdefferedが使われている
つうかESがよく参考にしてるのはC#じゃない、.NETだろ

**デフォルトの名無しさん** · 2018/12/06(木) 22:44:18.59

流れぶった切って悪いが、
教えてくだしい。
↓を解読しようとしてるんだけど、DLしたら文字化けしてる？のときって
どうしらいいでしょうか？
ttps://d21agqkwgk4jud.cloudfront.net/MW-Common/RS4B/v0.1.9mw_2018-10-09/js/viewer_loader_v0.1.9mw_2018-10-09.js

**デフォルトの名無しさん** · 2018/12/07(金) 02:41:15.18

ttps://github.com/getify/LABjs
解読したいだけならこっち見れば良いんじゃないかな

**デフォルトの名無しさん** · 2018/12/07(金) 03:39:36.49

雑誌読み放題とかのシャッフル画像を元に戻したいなら、
ブラウザを改造して、キャンバスの描画情報を出力できるようにしちゃったほうが早い

**652** · 2018/12/08(土) 02:27:44.56

>>654
ネット配信の漫画の画像をコピーしようかと思ってるのですが、
ブラウザ改装って、javascriptでどうにかなるのですか？

>>653
LAB.jsを改造したのが使われるみたいです。

**デフォルトの名無しさん** · 2018/12/08(土) 12:53:03.79

JSでスクリーンキャプチャしてもいいが
OS上で動くキャプチャツール使ったほうが良いだろう

**デフォルトの名無しさん** · 2018/12/09(日) 09:32:12.46

>>654
>雑誌読み放題とかのシャッフル画像を元に戻したいなら、
シャッフル画像ってこんなやつか、
http://demon-uploader.rosepink.us/uploads/2018120909160154095.png
有料の漫画発信サービスって、大元の画像ってサーバーにあると
思ってたが、こんな感じで加工して、まるまる出回らないようにしてたのか
っで、javascriptのcanvasで描画し直してユーザーのブラウザに表示してんだな

オレの仕事、工業用機械のプログラム担当だから、
web業界は知らんが、漫画発信ってこんなことしてんだな

**デフォルトの名無しさん** · 2018/12/09(日) 22:09:22.03

画像でも、DL されたくない場合に、画像上で右クリック禁止などにするけど、
F12 開発者ツールを起動して、URL を突き止められて、直リンクされる

だから、コピーされたくない場合は、canvas に描く

**デフォルトの名無しさん** · 2018/12/09(日) 22:48:22.77

今どき違法サイトだとしても直リンクはしないだろ

**デフォルトの名無しさん** · 2018/12/09(日) 23:15:43.62

仮想DOMにはデメリットはないの？

**デフォルトの名無しさん** · 2018/12/09(日) 23:43:25.74

一旦仮想DOMを構築してからそれを実際のDOMに反映させるという手順を踏む以上、
ある程度のオーバーヘッドはある。
やりたいことがごく少量のDOM操作で済むような場合はかえって高くつく可能性がある。

**デフォルトの名無しさん** · 2018/12/10(月) 00:11:14.50

>>660
DOM APIと相性が悪い。
DOM APIを使って直接DOMをいじるのはご法度
いじりたい場合、フレームワークのやり方に合わせる必要がある

**デフォルトの名無しさん** · 2018/12/10(月) 00:24:42.59

>>661
メモリもりもり使いそうだね
あとSEO的にはどうなのかな？

>>662
ドラッグしてリスト入れ替えとか無理？

**デフォルトの名無しさん** · 2018/12/10(月) 01:15:42.73

>>661
指摘はその通りだが、実際はそこは問題にはならない。
体感100倍くらいDOMのレンダリングは遅いので、オーバーヘッドは1%だし、無視出来る。
それで10ページ分纏めてレンダリングしているのを遅延描画に出来れば、単純に10倍速くなる。
普通に考えて、『導入に手間がかからなければ』みんな使う。
（ただし実際の所はネットワークディレイの方が支配的で、
変に無理してSPA等するよりも物理鯖に金かけた方が効果があることもよくあるが）

最大の問題は、ブラウザが勝手にやってくれるのではなくて、手動でやれ、という点だ。

>>662
> DOM APIを使って直接DOMをいじるのはご法度
これは(jQuery含めて)DOMフレームワークの宿命だ。
というか、フレームワークの場合はフレームワークに合わせるのが当然であって、
それが必要なのにライブラリだと嘘ぶくjQueryは相当汚いのさ。

VirtualDOMは実験としては面白いが、手動でやらないといけない現状の仕様では、流行らせるのは厳しい。
自動でやってくれるのなら確実に流行る。
が、その場合は現状のvirtualDOMの知識なんて不要なレベルまで隠蔽される。
（はず。ただしJavaScriptの仕様委員会はかなり間抜けなのであまり期待は出来ないが）

**デフォルトの名無しさん** · 2018/12/10(月) 01:17:12.68

以上、間抜けの長文でしたｗ

**デフォルトの名無しさん** · 2018/12/10(月) 06:20:05.87

>>664
お前さ、長文うざいんだよ。
ここは質問用スレッドであって

テメエのプログラム論語る場所じゃねーんだよ。クソ野郎。

今すぐ消え失せろ

**デフォルトの名無しさん** · 2018/12/10(月) 10:52:32.91

>>663
これ質問だから何かお願いします

**デフォルトの名無しさん** · 2018/12/10(月) 12:31:44.90

>>666
jQuery語る奴にもいってやれ

**デフォルトの名無しさん** · 2018/12/10(月) 12:55:42.53

DOM をjQuery で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する

Vue.js から見たら、仮想DOMがすべての情報だから、
仮想DOM以外の情報は捉えられない

**デフォルトの名無しさん** · 2018/12/10(月) 13:19:29.74

DOMをAPIで変えた場合も同じ

**デフォルトの名無しさん** · 2018/12/10(月) 13:59:37.35

bootstrapはjQueryありきだからUIは自前でデザインしないといかんね

**デフォルトの名無しさん** · 2018/12/10(月) 18:13:52.48

>>667
DOM をDOM API で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する

**デフォルトの名無しさん** · 2018/12/10(月) 20:11:33.28

>>672
うーん
めんどくさいね
reactはDOM変更されたのを読み取れるから勝手に仮想も変更しといてほしいんだが

**デフォルトの名無しさん** · 2018/12/10(月) 20:24:16.30

それが仮想DOMの限界なんだよ
ウェブの標準との相性が悪い

**デフォルトの名無しさん** · 2018/12/10(月) 22:13:45.73

>>674
それは仮想DOMというよりは、フレームワーク全体の問題なのではなくて？

**デフォルトの名無しさん** · 2018/12/10(月) 22:53:24.37

触らずに済むように作ったら
触れないからダメって言われても

**デフォルトの名無しさん** · 2018/12/10(月) 23:15:27.01

その通りだな。
問題でも限界でもなく、当然の仕様であり、それが嫌なら使うな、でしかない。
というか直接いじったらフレームワーク導入の意味が無いし。

**デフォルトの名無しさん** · 2018/12/11(火) 13:17:30.38

Doodle2というスクリプトから画像を描画できるCOMコンポーネントを64ビットのwindows10で使うことは無理でしょうか？
古い32ビットのDLLなので難しいかとは思うもですが
XPで使っていて自分にはこれで十分な機能だったので
使えるのならコードも流用できるので使いたいのです

C:\Windows\System32\ にはレジスト出来ず、調べたところC:\Windows\SysWOW64\のほうに入れるこはできましたが
依存 .DLL ファイルに問題がある、っぽいエラーがでてダメでした
何かを持ってきたり頑張れば使えるようになるのか、どうやっても無理なのかだけでも知りたいのですが
さすがに今使ってる人はいないとｊは思うんですが

**デフォルトの名無しさん** · 2018/12/11(火) 14:12:20.06

+ JavaScript の質問用スレッド vol.126 +

**デフォルトの名無しさん** · 2018/12/11(火) 22:02:27.12

>>678
スレチだしそのDLLについては知らないが
https://soundengine.jp/wordpress/tips/try/555/
とかで調べたらワンチャンいけるかも

**678** · 2018/12/12(水) 21:56:56.08

まずスレチすいませんでした
こういうのをどこで質問していいかわからず、もし使ったことのある人がいるならこのスレかなと思いここにしてしまいました
どうにか解決したので報告だけさせてください

>>680
すごくヒントになりました
結局dllは不足なかったことがわかり不思議でよく考えてみたところ
wscriptのほうもSystem32のものではなく、SysWOW64の32ビットのものを指定して実行したところ問題なく使うことができました
わかってみたら単純なことでしたが思いこんでました
ありがとういございました

**680** · 2018/12/13(木) 03:26:42.51

>>681
よかったな
わしも今後の参考にするわ

**デフォルトの名無しさん** · 2018/12/14(金) 21:27:47.36

JavaScriptの非同期の書き方がまだおぼつかないのですが

var defarr = [];
for(x of list) {
var d = new $.Deferred();
$ajax(...)
.done(() => { d.resolve() });
defarr.push(d.promise());
});
return $.when.apply($,defarr);

みたいな感じでAPIからデータをとってきて画面に非同期で順番に表示する
みたいな処理があるときに
途中で中断したいときどこにどういうコードをはさめばいいんでしょうか

**デフォルトの名無しさん** · 2018/12/16(日) 20:50:25.64

中断の伝播とか真剣にやってるとやっぱり複雑になってきたときにバグるよ
手抜きして要素を非表示にしたりメインツリーから消したりして
表示までの処理は動いてるけど機能しない状態にするのが一番お手軽で安全

**デフォルトの名無しさん** · 2018/12/16(日) 21:00:20.73

requreを使っているfile.jsライブラリファイルをインポートできなくて困っています。
file.js内には「func」という関数が定義されていて
これをインポート先で呼び出したいとします。
ただし「file.js」内部にはrequireが使われていて
これに失敗します。
.htmlファイルから
scriptタグのsrc属性で読み出す。
普通なら「file.func()」で関数を呼び出せる
のですが、
requireが失敗するためにfile.jsをbrowserify
で変換しました。
変換後はrequireが使えるようになりますが
変換の影響でfile.js内部のコードが変なコードで
囲まれて内部で定義されている関数「func」
がインポート先から見つけられなくなってしまいます。
requireを内部で使っているファイルを
.htmlのscript src属性でファイルパスで読み込んで
内部の関数を呼び出すにはどうしたらいいでしょうか？

**デフォルトの名無しさん** · 2018/12/16(日) 21:19:05.88

ライブラリLAB.jsの質問
script src="LAB.js" で読み込んだあとで
$LAB
.script("jquery.js").wait()
.script("jquery.ui.js")
.script("jquery.lightbox.js")
.wait(function() {
$(document).ready(function() {
$('#gallary').lightbox();
});
});
とすると実行されるのですが、

htmlにscript src="LAB.js" を書かずに
下記にあるように、LABjsを動的に読み込むと
$LABが未定義ってなるのですが、
このように～.jsを動的に読み込んだ後ってどうすればコードが
動くのでしょうか？

load LABjs itself dynamically!
ttps://gist.github.com/getify/603980

**デフォルトの名無しさん** · 2018/12/16(日) 21:39:52.63

JavaScript の質問は、web制作管理板の方へ書き込んでください！
こちらのスレは、答える人が少ない

>>683
頼んでいた非同期処理を、中断・取り消すのか。
そういうのは、できるかな？

「javascript 非同期処理中断」で検索！

>>685
「javascript require commonjs」で検索！

>>686
「javascript 動的読み込み」で検索！

**デフォルトの名無しさん** · 2018/12/16(日) 22:18:46.36

>>687
document.onreadystatechange = function() {
if (document.readyState == "complete") {
$LAB (以下略)
}
}
ありがとうございました。これで動きました。

**デフォルトの名無しさん** · 2018/12/17(月) 11:44:23.10

これほど書き方が統一されていない言語あるかね？
function書くだけなのにいくつもパターンありすぎ

**デフォルトの名無しさん** · 2018/12/17(月) 11:48:12.21

python行けば？誰も止めないよ

**デフォルトの名無しさん** · 2018/12/17(月) 13:51:26.97

pythonは関数を書くときにdefとlambdaがある

**デフォルトの名無しさん** · 2018/12/17(月) 17:37:22.98

つまり未だにアロー記法を採用してくれないPHP最強ってことだな
何回function書かせるねん

**デフォルトの名無しさん** · 2018/12/17(月) 17:48:18.50

打つのが面倒でないならjavascriptでも全部functionで通してもええんやで。
所詮(function () {}).bind(this)の糖衣構文に過ぎない。

**デフォルトの名無しさん** · 2018/12/17(月) 18:28:11.97

入力補完でfunctionを打つのは楽だから、基本はfunction使う
アローより可読性高いから

ワンラインで済むときと、thisを受け継ぎたい時だけアロー使う

**デフォルトの名無しさん** · 2018/12/17(月) 18:44:46.88

mapとかfilterの引数もfunction渡すの？
複数行あるならともかく、一行で済むものにわざわざfunctionとreturn書くのは、可読性の観点だと逆効果のような

**デフォルトの名無しさん** · 2018/12/17(月) 18:58:59.52

>>695
> ワンラインで済むときと、thisを受け継ぎたい時だけアロー使う
> ワンラインで済むときと、

**デフォルトの名無しさん** · 2018/12/17(月) 21:20:06.41

> 所詮(function () {}).bind(this)の糖衣構文に過ぎない。

糖衣構文って素晴らしいよね

**デフォルトの名無しさん** · 2018/12/17(月) 22:29:47.87

念のため、素晴らしくないとは言ってないからな。
functionでも書けるから、そうしたいならどうぞご勝手に、という話。

**デフォルトの名無しさん** · 2018/12/18(火) 14:54:48.45

アロー使ったら複数行でもreturnなしにしてほしい
最後の行の値を返せばいいだけと思うけど、難しいのかな

**デフォルトの名無しさん** · 2018/12/18(火) 15:53:26.83

() => (
,
,
,
)

どうぞ。

**デフォルトの名無しさん** · 2018/12/18(火) 17:10:59.06

むしろアロー関数は1行でしか使えないようにしてほしいくらいだ

**デフォルトの名無しさん** · 2018/12/18(火) 18:43:12.10

yield 文って、generator function から呼び出された普通の関数の
中で使うとどうなる？

エラーになるか、それとも、あたかも、親の generator function
の中から yield 文が実行されたかのように動作するかどちら？

書き方は間違ってるかもしれないけど、こんな感じの事やったらどうなる？

function *func1() {
yield 1;
func2();
yield 3;
}
function func2() {
yield 2;
}

console.log( func1().next() );
console.log( func1().next() );
console.log( func1().next() );

**デフォルトの名無しさん** · 2018/12/18(火) 18:52:16.34

エラーになるかどうか知りたいの？
コンソールに張り付けろよ

**デフォルトの名無しさん** · 2018/12/18(火) 19:07:53.94

var aaa = func1;
console.log( aaa.next() );
・・・

みたいに修正してから、やってみたら func2() 内の yield でエラーが出た。

**デフォルトの名無しさん** · 2018/12/18(火) 19:08:58.50

>>703
そんな方法があったとは・・・

**デフォルトの名無しさん** · 2018/12/18(火) 19:31:11.55

function* func1() {
yield 1;
yield* func2();
yield 3;
}
function* func2() {
yield 2;
}

俺のESP能力が高ければこれが助けになるだろう。

**デフォルトの名無しさん** · 2018/12/18(火) 19:42:52.51

>>706
それだと、func2() も　generator function になるよね。

自分が思っていたのは、もし、普通の関数でも
yield が使えれば、JS でも、SetEvent() と WaitForSingleObject()
みたいな同期オブジェクトを作れるんじゃないかということだった。

そうすれば、wasm を使って、Windows プログラムも移植できるの
ではないかと思った。

**デフォルトの名無しさん** · 2018/12/18(火) 20:07:42.22

>>707
それは何の為に？
WebAssembly(wasm)なら移植の必要すらなく動かせる（はず）だろ。
それ以前にGraalVMなんてのも出てきたみたいだが。
> JavaScriptだけでなくあらゆる言語をブラウザで扱えるように、GraalVMをChromiumにリンクすることを考えた学生が1人います。
> https://www.infoq.com/jp/news/2018/05/oracle-graalvm-v1

>>705
インタプリタがある言語(≒スクリプト言語）なら通常のデバッグ方法だ。

**デフォルトの名無しさん** · 2018/12/18(火) 21:15:58.80

>>707
普通の関数でyieldが使えてもそれはジェネレータ関数ができること以上のことができるようにならないだろう
結局処理は同期的で待ち合わせには使えないのだから
async関数でというのなら分かるがそれはもうasync generatorがある

**デフォルトの名無しさん** · 2018/12/18(火) 23:58:38.14

やっぱ、数学ができない人にはわからないんだと思う。
ちなみにおいらは数学は主席。
今のwasmは、sleepはできるが、SetEventやMutex などを
待つことができないので、
>WebAssembly(wasm)なら移植の必要すらなく動かせる（はず）だろ。
これは違う。

すまんが、何度説明しても分からん人には分からん。
日本語の問題ではない。句読点の問題でもない。数学の問題なんだ。

**デフォルトの名無しさん** · 2018/12/19(水) 00:02:06.41

ああ、この前の数学君か
元気だな、頑張れ

**デフォルトの名無しさん** · 2018/12/19(水) 06:35:13.60

WASMはもう実験的にSABとAtomicsサポートしてるでしょ
何を知ったげに言ってるんだか

**デフォルトの名無しさん** · 2018/12/19(水) 08:43:58.69

数学くんは虚学の悪いとこ取りしたような人だね。

**デフォルトの名無しさん** · 2018/12/19(水) 09:41:58.49

>>712
wasm は、emscripten_sleep(millisecond) をサポートしてるので、もともと問題の根は浅い。
でもあなたの言ってることはSetEvent()やMutex()などの同期オブジェクトとは直接関係
ない。それに proposal 段階で、実装報告は見当たらないんじゃないの。

**デフォルトの名無しさん** · 2018/12/19(水) 10:08:12.65

【数学首席のオイラが書く(言葉の美しさは知らん)】

atomic fence は、二つのスレッドが同時に読み書きすることを防ぐ目的で使うもの。
たとえば、グローバル変数 a に「1足す」場合、CPUは、それをいったん(内部)
レジスタなどに読み取ってから、1足し、最後に同じグローバル変数 a に書き戻す。
この際、二つのスレッドがほぼ同時に「読んで」しまった場合、合計で「2」を足して欲しいのに、「1」しか足されなくなってしまう。それを防ぐために、ある同時に「読む」ことすら防ぐフェンスのようなものを用意するためのもの。だから、専用APIとして、
InterlockedIncrement() があったり、CPU自体にもマシン語レベルでLOCK修飾なるもの
があったりする。
一方、SetEvent() などのイベント発生を「待つ」ことは、この仕組みだけでは不十分で、
次のような単純なやり方では CPU がフルパワー状態になり、電力の無駄使いになる。
ちなみに、このように (HLT 命令を使っていない) BUSY LOOP では、CPU の電力消費
が何十倍にもなることがある（だから、sleep()命令は特殊な実装を行ってる）。：

ATOMIC_FENC　g_fence;
BOOL　　　　　g_bEvnet = 0;
void mySetEvent() // スレッドBが使うとする。
{
　　g_bEvent = 1;
}
void myWaitForEvent() // スレッドAが使うとする。
{
　　// 以下ループで、CPUがフルパワー状態になり電気の無駄使いになる：
　　for ( ;; ) {
　　　　BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
　　　　if ( !g_bEvent ) {
　　　　　　g_bEvent = 0;
　　　　　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
　　　　　　break;
　　　　}
　　　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
　　}
}

**デフォルトの名無しさん** · 2018/12/19(水) 10:09:02.19

>>715
[続き]
そこで今度は、myWaitForEvent()のループを次のように書き換えたとする：
　　for ( ;; ) {
　　　　BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
　　　　if ( !g_bEvent ) {
　　　　　　g_bEvent = 0;
　　　　　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
　　　　　　sleep(100);　　// 100(ms) 待つ。
　　　　　　break;
　　　　}
　　　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
　　}
この場合は、電力消費はかなり抑制されるが、スレッドBで mySetEvent()が呼ばれて
から、スレッドAのmyWaitForEvent()がそれを知って、ループから脱出するまでに、
最悪100(ms)の遅延が発生してしまう。だから、OSは、WaitForSingleObject() API
などの専用の同期メカニズムを用意しなくてはならない。Emscriptenにはまだそれ
が整備されていない。

**デフォルトの名無しさん** · 2018/12/19(水) 10:11:23.08

>>715
【修正】

void mySetEvent() // スレッドBが使うとする。
{
　　BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
　　g_bEvent = 1;
　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}

**デフォルトの名無しさん** · 2018/12/19(水) 10:12:13.28

>>716
【修正】

誤：if ( !g_bEvent ) {
正：if ( g_bEvent ) {

**デフォルトの名無しさん** · 2018/12/19(水) 10:14:39.02

>>715
【sleep()を使う場合の最もましなコード】
（それでもどうしても遅延が発生する。）

void mySetEvent() // スレッドBが使うとする。
{
　　BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
　　g_bEvent = 1;
　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}

void myWaitForEvent() // スレッドAが使うとする。
{
　　// 以下ループで、CPUがフルパワー状態になり電気の無駄使いになる：
　　for ( ;; ) {
　　　　BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
　　　　if ( g_bEvent ) {
　　　　　　g_bEvent = 0;
　　　　　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
　　　　　　sleep(100);　　// 100(ms) 待つ。
　　　　　　break;
　　　　}
　　　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
　　}
}

**デフォルトの名無しさん** · 2018/12/19(水) 10:15:59.44

>>719
【修正】
誤：// 以下ループで、CPUがフルパワー状態になり電気の無駄使いになる：
正：// 以下ループで、最悪100(ms)の遅延が発生する。

**デフォルトの名無しさん** · 2018/12/19(水) 10:17:28.95

>>719
【再修正】

void myWaitForEvent() // スレッドAが使うとする。
{
　　// 以下ループで、最悪100(ms)の遅延が発生する。
　　for ( ;; ) {
　　　　BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
　　　　if ( g_bEvent ) {
　　　　　　g_bEvent = 0;
　　　　　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
　　　　　　break;
　　　　}
　　　　EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
　　　　sleep(100);　　// 100(ms) 待つ。
　　}
}

**デフォルトの名無しさん** · 2018/12/19(水) 10:46:30.85

いや、もうAtomicsAPIがChromeでオリジントライアルで使えるでしょ
もう解決してる問題に対して何をイキっちゃってんの
いくら数学の理論構成や計算ができようと意味はないよ
そんなのは機械でできることだから
正しい問題と前提を認識できて初めて数学という道具は有益に使えるんだから
君がやってるのはただ思考力の無駄遣い
まあ君の頭だからどう無駄に使おうと勝手だけど、スレ汚しは勘弁してね

**デフォルトの名無しさん** · 2018/12/19(水) 13:13:50.30

>>722
なるほど、Atomics の wait() と notify() の事か：
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics/wait

分かった、すまんかった。
しかし、海外のサイトを検索しても、この関数のことは一切発見することが出来なかったんだよ。
await や async や、その他の便利ラッパクラスみたいなものより、こっちの関数の方が重要だ。

初見だが、多分、notify() と wait() が、Win32API の SetEvent() と WaitForSingleObject() に大体
対応していて、それがあればスレッドの同期に関してはほとんどの用途では足りると思う。
効率の良い(電気もCPUパワーも無駄にしない) sleep() もこれらを使えば実装できてしまうだろう。

**デフォルトの名無しさん** · 2018/12/19(水) 14:57:22.19

またWindowsのAPIに固執してるの？
いい加減に理解しなよ。Windowsとwebは無関係だって。

**デフォルトの名無しさん** · 2018/12/19(水) 17:02:01.51

マルチプラットフォーム環境として、wasm や JVM や CrossBrdige(FlashCC) など
を調査してるから、Windowsアプリが移植できるかどうかに興味があるんだ。

**デフォルトの名無しさん** · 2018/12/19(水) 20:13:23.94

Windowsアプリが移植できるかと、同じAPIを持ってる事は無関係だし、
事実同じAPIも持ってないよね。
なのに見立てる理由がわかんない。

**デフォルトの名無しさん** · 2018/12/19(水) 21:13:53.09

基本的にLLVMに変換可能なプログラムなら移植できるけど
OS特有のAPIやライブラリ使ってちゃそりゃそのまま移植できるはずがない

**デフォルトの名無しさん** · 2018/12/20(木) 01:35:15.77

だからそれをやっちゃおうかな、っちゅう話ですわ。

**デフォルトの名無しさん** · 2018/12/20(木) 08:29:03.69

やっちゃおう、にどれだけ価値があるかわからんけどね。
そこまで言うなら、前回のIMEだって、やっぱりIMEを移植すべき問題じゃん。
同じAPI使うってのは、wasmでのWin32API互換ライブラリを作るって夢を語ってるって事なのかな？

簡単な道ではないと思うけど。
WINE何年かかってんよって話。

**デフォルトの名無しさん** · 2018/12/20(木) 12:51:09.87

WasmでというよりJSででしょ
現状Web API叩くのはJSからしかできないのだから

**デフォルトの名無しさん** · 2018/12/21(金) 02:52:57.38

foo =function(){}とか
bar = ()=>{} とか
エディタがDocコメ認識してくれないことが多くてなあ…

**デフォルトの名無しさん** · 2018/12/21(金) 03:02:08.56

jsdocって言語機能が名前から想像するよりはるかに異なるjava用のjavadocの単なるメクラポーティングだしなぁ…
js用にもっと相応しいドキュメント仕様が普及してもよかっただろうに世の中うまくいかんのう…