【wasm】ブラウザでC++。Emscriptenを語ろうat TECH
【wasm】ブラウザでC++。Emscriptenを語ろう - 暇つぶし2ch100:デフォルトの名無しさん
19/09/12 22:35:47.25 Uy9QyXie.net
>>40
トンでもねぇ色彩センスwww
さすがに草不可避wwwww

101:デフォルトの名無しさん
19/09/13 10:13:11.78 wKEqF87n.net
NG かどうか試してみる
URLリンク(nowsmartsoft.atwebpages.com)

102:デフォルトの名無しさん
19/11/18 16:14:21.51 Vzii0sJA.net
C++をソースとするwasmとPWA(Progressive Web Application)化できる
ことを実際に確認することが出来た。Chrome+Win7の組み合わせで
wasmアプリをローカルにインストールできてデスクトップにアイコン
を作成することができる。アイコンをクリックすると、ある種の
nativeアプリの様な雰囲気で起動できる。

103:デフォルトの名無しさん
19/11/18 16:14:54.06 Vzii0sJA.net
C++をソースとするwasmをPWA(Progressive Web Application)化できる
ことを実際に確認することが出来た。Chrome+Win7の組み合わせで
wasmアプリをローカルにインストールできてデスクトップにアイコン
を作成することができる。アイコンをクリックすると、ある種の
nativeアプリの様な雰囲気で起動できる。

104:デフォルトの名無しさん
19/11/18 16:15:25.78 Vzii0sJA.net
age

105:デフォルトの名無しさん
19/11/18 19:53:09.11 Vzii0sJA.net
URLリンク(yutakaaoki.github.io)
ここに wasmアプリが置いてあるが、Chromeで訪れると アドレスバーの右の方に
「インストール」という文字が現れ、しばらくすると、○で囲った + 記号に変わる。
そこをクリックすると、PWAとしてローカルPCにインストールできる。
または、右上の縦に3つの点があるボタンを押してみると、
『「PWA NWSTK」をインストール...』
というメニュー項目が出来ているので、そこをクリックしても同じ機能が働く。

106:デフォルトの名無しさん
19/11/20 09:18:48.73 Zp1gFICP.net
Mozilla、Fastly、Intel、Red HatがWebAssemblyをターゲットに「The Bytecode Alliance」
URLリンク(news.mynavi.jp)

107:デフォルトの名無しさん
19/11/20 12:43:45.81 vKT/00gf.net
>>101
URLリンク(yutakaaoki.github.io)
ここにおいてあるものは、全部PWAに対応してみた。
Windowsならインストールできると思う。
AndroidやiPhoneなどでも出来るか試して欲しい。

108:デフォルトの名無しさん
19/11/20 12:51:31.62 vKT/00gf.net
>>103
まだ本当の意味でのソースではないけど、
URLリンク(github.com)
以下の
URLリンク(github.com)
などに index.htmlや、*.wasm, *.js, manifest.json などは置いてある。
wasmアプリの作り方、PWAの作り方、wasmとPWAの組み合わせ方、に興味のある人は
参考までに。

109:デフォルトの名無しさん
19/11/20 13:48:41.27 pcdm34G4.net
で、これで何ができるの?

110:デフォルトの名無しさん
19/11/20 14:49:34.93 vKT/00gf.net
>>105
・セキュリティーが凄く強いアプリ。信用できないようなサイトからインストール
 しても、レジストリには読み書きできないし、システムフォルダや他のアプリの
 フォルダには、人間がマウスやキーボードなどから実際に指示しない限りは書き込めないし、
 読み込むことも出来ない。変な場所にインストールされたり、スタートアップ起動などに
 勝手にされることも無い。
・アプリの体験版をインストールすることなく、普段のウェブ閲覧の延長線上に
 試せるのでユーザーは遊び半分で気軽に試すことが出来る。また、掲示板などから
 リンクを張った先がすぐにアプリとなっている。その後、デスクトップや
 ホーム画面にアイコンを追加し、単独アプリの用に振舞うことが出来る。
・なぜか全てがウェブに移行するようになっており、「いつもウェブが勝つ」。
・iPhoneやiPad用のアプリが無料で開発出来る可能性がある。今までは、
 それらをターゲットに開発するには、Mac実機がどうしても必要となり、
 かつ、AppStoreに登録しないと配布することも出来なかったが、AppStoreは
 年会費も必要で、生涯にわたってずっとコストが掛かかり続けていた。
・ブラウザが互換性を保つので、PCで試して動けば、AndroidやiPhoneでも
 近い動作になる可能性が高い。
・Chrome, FireFox, Safari, Edge, Opera なども wasm に対応している
 (ただし、ツールキット側がテストはしておく必要はある。)。

111:デフォルトの名無しさん
19/11/20 15:00:00.13 AFHj5vY6.net
Java Appletと何が違うの?

112:デフォルトの名無しさん
19/11/20 15:00:41.97 vKT/00gf.net
>>106
【追加】
・画面が、Ctrl+ +, Ctrl+ -で好きなように拡大縮小できるので、近視や老眼などで
 目が悪い人でも好きな文字の大きさで読むことが出来る。それがWebアプリでも、
 PWAアプリ化したものでも出来る。
・ツールキットも含めてサイズがとても小さい。ブラウザさえ使える状態であれば、
 DLLやランタイムのインストールが全く不要。demo1は、*.htmlや*.js, *.wasm全て
 合わせて 150KB、demo-Mountainは、153KB。JavaランタイムもQtランタイムも
 MFCのDLLも何も要らない。

113:デフォルトの名無しさん
19/11/20 15:11:39.18 vKT/00gf.net
>>107
・Java Appletは、訴訟トラブルのせいか、ChromeもFireFoxが対応しなくなって
 しまった。
・wasm は、C++ が使えるので、GC を使わないプログラムが出来、
 メモリが多く使うウェブアプリを作ろうとした場合に、体感速度が非常に
 違ってくる。Javaだと、GCが走ると一分間停止するようなことがあった。
 wasm と C++ の組み合わせだと、このようなことが起きないので、
 プログラムした通りの一定の速度が維持できる。
・Java は、逆コンパイルするとほぼ元ソースに戻せてしまう性質があった。
 それを防ぐには曖昧化などが必要であり、手間や(ツール購入の)コスト
 が掛かった。曖昧化するためにコンパイル時間が増大した。
・Javaが有料化したという話がある。これについては諸説あるのでよく分からない。

114:デフォルトの名無しさん
19/11/20 15:14:47.33 vKT/00gf.net
>>109
・Java Applet より起動が速い。

115:デフォルトの名無しさん
19/11/20 15:18:23.10 vKT/00gf.net
>>110
・wasm内部からは、EM_ASM()構文などで自由にJavaScriptが使えるので、
 XHRやfetch()などを自由に使ったAjax流儀のプログラムが行える。
・簡単に HTML 要素と共存できる。
・ブラウザの画面を拡大したような場合に、JavaAppletだと追従するのが
 難しく、できないことはないがタイムラグが生じ易かった。
 Ctrl+ + での拡大も、JavaApplet 部分だけは置いていかれるようなことに
 なったので、対応したければ独自に工夫する必要があった。

116:デフォルトの名無しさん
19/11/20 15:54:16.93 vKT/00gf.net
>>111
・iOSでは、もともとJavaが使えないと聞いている。
・Androidは、基本がJavaではあるが、実際には、Google独自実装となってしまって
 おり、 Sun/OracleのJavaで昔からの標準の Swingなどを使ったものは動か
 せない。これが訴訟問題になった最も大きな原因の一つらしい。

117:デフォルトの名無しさん
19/11/20 19:15:30.47 vKT/00gf.net
>>108
ツールキットに用意されて無い機能を追加したい場合、JavaScript として書けば
よいのであらゆるプラットフォームへ迅速に対応できる。
他のツールキットの場合は、iOS/Andorid/Win/Mac/Linux など用にそれぞれ
書く必要がある。

118:デフォルトの名無しさん
19/11/21 15:21:55.41 0fDEV4Sz.net
PWAは、頻繁にアップデートしたいアプリに向いている。

119:デフォルトの名無しさん
19/11/21 16:02:31.75 0fDEV4Sz.net
PWA化後のデスクトップのアイコンが、物凄くいろいろなことをやっても古いまま
全く更新できなく立った。
どうしよう。

120:デフォルトの名無しさん
19/11/24 12:10:37.33 Tuk9Q29U.net
Safariで動いていたよ。
ホーム画面への追加のボタンも出ていた。

121:デフォルトの名無しさん
19/11/26 01:08:23 t9NWfcZD.net
PWAだとストアの審査が要らない。通常、iPhoneのアプリは、iPhone流の
インターフェースを持って無いと審査に通らない(Appleに脅威をもたらすと
考えられるだけで審査に通らない可能性もある。YahooゲームやLINEゲームが
AppleにBANGされた歴史もある。)。PWAの場合はそんなことはなく自由
なので、PCやAndroid、iPhoneで完全に同じインターフェースにすることもできる。
そうすれば、開発も楽になる。

122:デフォルトの名無しさん
19/11/26 01:16:04 t9NWfcZD.net
PWAの場合、ブラウザとnative風アプリの操作感が統一できるのでユーザーは
安心して使える。WindowsとiPhoneで同じインターフェースのアプリになる。
今まではAppleの審査のためにそのようなことは出来なかった。Windowsに慣れて
いるが、iPhoneを使っている人にはWindows流インターフェースの方が好まれる
可能性があるにも関わらず。

AppleはiPhoneらしさを強要するが、逆にどのプラットフォームでも同じ操作感
であることには、開発者のみならずユーザーにもメリットがある。

123:デフォルトの名無しさん
19/11/26 01:22:29 t9NWfcZD.net
Appleは審査が厳しいが、自社がそのアプリが出てくると(競争に負けて)業績が
落ちそうだと判断するともっともらしい理由を付けて審査を通さなかったり、
長く時間をかけて手間をかけさせたりする可能性がある。PWAだとその心配が無い。
ただし、PWA専用のダウンロードサイトを作ろうとすると、そのサイト自体に
規制がかかったことがあるそうだ。Appleはまるで中国や北朝鮮のようだ。

124:デフォルトの名無しさん
19/11/26 01:24:58 t9NWfcZD.net
>>118
URLリンク(blogs.adobe.com)
1. より一貫したデザインを提供できます。3つの異なるデザインをiOS、Android、
 レスポンシブサイトとそれぞれ用意する代わりに、PWAの場合はすべての環境に
 対応する1つのアプリをデザインします。これはアプリ開発にかかる時間を短縮
 するだけでなく、デザインの一貫性にも繋がります。デザイナーは、1つのガイド
 ライン作成に集中でき、より有意義に時間を使うことができます。

2. 複数チャネルの組み合わせが容易です。ユーザーは、どんなデバイスから
 アクセスしても一貫性のある体験を求めています。あるデバイスで使い始め、
 他のデバイスに切り替えて再開することは自然な動作です。帰宅途中の通勤電車で
 ショッピングカートに目に付いた商品を入れたあと、自宅のPCからきちんと商品を
 確認して購入手続きを完了できるような機能はどうでしょうか?PWAであれば
 最小限の投資で実現できるでしょう。

125:デフォルトの名無しさん
19/11/27 01:56:02.82 T7KqQ5kC.net
独自GUIを乗せることで使い勝手で他のアプリと差別化できるかも。

126:デフォルトの名無しさん
19/11/27 01:59:18 T7KqQ5kC.net
>>121
今までなら独自GUIはAppleの審査に落ちる可能性があったが、PWAなら
自由になる。それでAppleの伝統を超えた使い勝手のGUIシステムを備えた
アプリを提供できれば他のアプリと差別化できる可能性が出てくる。

127:デフォルトの名無しさん
19/12/06 02:20:17 ZSKvcFXv.net
Webアプリの場合、URLのパラメータによって、プレイ中のゲーム画面
にいきなりリンクすることが出来るようになる。これで、ゲーム画面の「シェア」
が出来る。例えば、RPGで経験値、体力、魔力、所持アイテム、地図上の座標、
タワーの階層、的の位置などを全部URLのパラメータに直してしまえば、
そのシーンを他の人にシェアして、そこからプレイし始めてもらえる。これは、
native ゲームにはなかった特徴。blob や base64 による URL 化などを使えば
データをURL化することは難しくはない。URLが長くなりすぎる問題はある
かも知れないが。

128:デフォルトの名無しさん
19/12/06 02:24:38 ZSKvcFXv.net
>>123
RPGなどでセーブデータが大きすぎてURL化に適さない場合は、
サーバー上にシーンを圧縮セーブしておいて、その識別番号をシェアする手もある。
ユーザーが各自で無料ストレージサービスを借りて、そこにセーブしておいて、
それをシェアする手もある。

129:デフォルトの名無しさん
19/12/06 02:45:16 ZSKvcFXv.net
インストール型のゲームだと、URLを書くだけで一瞬で動いている場面を他人が
見ることはできない。しかし、ウェブゲームだとそれが出来る。ただし、
この場合、ゲームサイズを小さく作ることが重要になる。その意味で、
サイズがコンパクトになるwasmと、コンパクトなサイズのゲームライブラリが
重要となる。

130:デフォルトの名無しさん
19/12/06 02:50:45 ZSKvcFXv.net
ゲーム全体のデータが巨大だとしても、1つのシーンを見るために必要なデータは
ごく少ない。その意味で、プログラム部分(コード)部分のサイズさえ小さければ、
ポリゴンやテクスチャやマップのデータは巨大でも良い。大部分のデータは
サーバー上に置いて置けばいいのだから。これで、ゲームシーンを快適に
シェアできるようになる。これが、ブラウザゲームならではの新しい価値。

131:デフォルトの名無しさん
19/12/06 02:56:52 ZSKvcFXv.net
インストール型ゲームでも動いているゲーム画面をシェアすることも不可能ではないが、
それには、同じゲームをインストールすることが前提となる。
一方、ブラウザゲームでは、例えば、2ch/5ch にリンクアドレスのURLを
入れるだけで、一秒後には、そのシーンを見られて、プレイも出来る。

132:デフォルトの名無しさん
19/12/08 12:57:08.43 hM3Qn2JU.net
テニスゲーム:
URLリンク(yutakaaoki.github.io)

133:デフォルトの名無しさん
19/12/10 08:37:25 jvY2kg1T.net
WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ
URLリンク(www.publickey1.jp)

134:デフォルトの名無しさん
19/12/10 14:13:47.04 uv70k2ai.net
ブラウザの中でのwasmは、現状、ローカルファイルシステムには自由にはアクセス
できないが、その場合、mongoose.exe, Ruby, Python などでローカルサーバー
を起動すれば、ブラウザ内のwasmプログラムから cgi プログラムを起動できるので
ローカルOSのAPIは何でも利用できるようになるので、ローカルファイルシステムにも
自由に読み書きできるようになる。もし、このサーバープログラムが十分に高速なら、
DirectInput などを利用してフォースフィードバック付きのジョイスティックも
wasmゲームから使えるようになる。

135:デフォルトの名無しさん
19/12/10 14:26:39.38 48kVELqA.net
ローカルサーバーをnode.jsで書くの流行ったな

136:デフォルトの名無しさん
19/12/10 14:28:32.93 uv70k2ai.net
>>130
ちなみに、mongoose.exe は、BSD/MIT 系ライセンス。
サイズは100MBを超えてしまっているが、Luaを無効にしてソースから
ビルドし直すと、すると、サイズが1MBくらいになる。

137:デフォルトの名無しさん
19/12/10 14:36:55.20 uv70k2ai.net
mongoose.exe + CGIプログラム を配布すれば、ある種の Java仮想マシンJVMの
代替になる。JavaのSwingでGUIアプリを作る場合も JVM のインストールが必要に
なるが、それが、mongoose.exe + CGI プログラム。しかし、JVMよりサイズが
小さいのでインストールが容易。

138:デフォルトの名無しさん
19/12/10 16:23:17 uv70k2ai.net
>>129
それとは直接関係ないけど、海外のサイトで昨日、目にしたのは、Googleは、
MicrosoftからOSの制御力を奪おう(無くそう)としているという見方。
PWAを発案したのもGoogle。
IntelやMozilla、RedHat、Fastlyも、別方向でwasmを拡大しようとしているので、
恐らく一社がコントロールしようとしてもwasmの勢力拡大は止められない
思われる。PWAに関しては微妙で Appleは渋々対応している感じでは有るが、
対応しないとむしろ不利になると経営判断している可能性もある。
分からないが。

139:デフォルトの名無しさん
19/12/12 19:22:14.47 Z8SHCwDj.net
5chの広告に表示されている「ビビッドアーミー」などのG123なるものを
やってみたら、少なくともWebGLが、昔のPC-9801の最後期レベルよりも高速な
グラフィックをかけることがはっきり分かった。と言うか恐らく、初期のPlayStation
よりは緻密で速いと思う。
また、Fragment Shader は再帰的関数呼び出しでも何でも書けるようで、
レイトレーシングでも何でも出来ることがわかった。つまり、WebGLを
使ったブラウザゲームは、レイトレーシングやパストレーシングレベルの
3Dグラフィックを使ったものでも何でもできるようだ。
また、Chrome には、FileSystem API だけではなく、native file systema API なる
実験的拡張がある。これはデフォルトでは disable だが、enable にすれば、
本当に native のファイルシステムのディレクトリ内のファイル一覧を取得したり
自由に読み書きできるようになるらしい。
Wasmもある程度速いし、もはや、nativeアプリは要らないかも。
Webアプリは、Win/Mac/Linux/iOS/Android 全てに共通で、
「1バイナリ」で Write Once, Run Anywhere がほぼ実現しているので
ブラウザをOSとみなした場合、WindowsやiOS, Android のどれよりも
シェアが大きい。これは native アプリの時代が終焉するかもしれない。

140:デフォルトの名無しさん
19/12/12 19:26:35.52 Z8SHCwDj.net
>>135
訂正。
使ったGPUは、エントリーモデルの(ビジネス用の)劇安 Intel CPU に内臓の
Intel HD グラフィックのもの。それでさえ、初期 PlayStation レベルを
超えたグラフィックが描けているようだった。

141:デフォルトの名無しさん
19/12/13 00:07:05.15 wVkcEFxk.net
PWAは自社に不利になるはずなのに何故、Appleも採用したかについて。
PWAはGoogleが推進しているものだが、Googleは、検索エンジンを
iOSのデフォルト検索エンジンにしてもらうために、毎年Appleに
一兆円を払っている。ところが、このカネの流れのために、
AppleもGoogleの意向を無視できない状況になっているのではないか
と考えられる。

142:デフォルトの名無しさん
19/12/13 10:10:45.11 V90d9jYd.net
板違い
マ板池

143:デフォルトの名無しさん
19/12/30 11:57:40.01 WPyQm6xM.net
アップル、Mac App Store外アプリの「公証」要件を厳格化。2020年2月3日から
URLリンク(japanese.engadget.com)

144:デフォルトの名無しさん
19/12/30 12:16:48.85 WAqdspci.net
登録済でも放置されてるものは消えるのか
胸熱

145:デフォルトの名無しさん
20/01/05 08:50:18.44 FwkgyDD/.net
ブラウザでゲームのマップ作れて操作するのは見たことあるよ。
もう今ブラウザ主流?
ただいちいちサイトに繋いだりサーバーにアクセスするから普通のアプリよりは不安要素あるけど。セーブもしたりできるしな。
何でブラウザでやるのかがわからない。

146:デフォルトの名無しさん
20/01/05 16:24:57.29 UrHjpLCo.net
>>141
ある外国の学者が言ったそうだ。
「存在する技術はぎりぎりまで使われる」
と。
典型的な例は、HDDの容量が以前では考えられないほど増大しているのに、テレビ録画など新しい使い方が見出されていつまでたっても不足していること。
ユーザー目線で考えたときのブラウザでやるメリットは、
・インストール作業が要らないこと。もし起動が十分速ければ、次々とゲームを試すことも出来る。
・理論上は、URLに状態やセーブ番号などを含ませておけば、そのURLを掲示板などに張っておくだけでプレイ場面を世界中の人に見て貰えること。
・プログラムがブラウザのサンドボックス内から外に悪さが出来ないので、たとえ野良アプリであってもマシンにあく栄起用を与える可能性が低いこと。
・iOS/Android/Windows/Mac/Linux など全く違うOSでも全く同じ使用感でゲームが出来ること。
・Appleの独自規制に引っかかることもないので開発者の自由な発想のゲームで遊ぶことが出来る。

147:デフォルトの名無しさん
20/01/05 18:19:27.95 UrHjpLCo.net
URLリンク(www.businessinsider.jp)
*アップルは、国境を超えて表現を規制する力を持っている。
アップルのガイドラインでは、性的な表現について、次のような記載がある。
「Webster辞書で『美的または情緒的な感覚ではなく、性的興奮を引き起こすような、性器または性行為の明確な記述または表示』と定義される、あからさまに性的またはわいせつなコンテンツ」
欧米や日本、イスラム教徒の多い中東など、国、地域ごとに「わいせつ」の考え方には違いがある。
しかし、デベロッパーに対しては、アメリカのアップルが決めたガイドラインが一律に適用されるため、「ローカルルールは存在しない」と言われる。
6〜7年ほど前、ゲームの世界でも、ガラケーからスマホに一気に移行する波が訪れた。そのころには、アップルの基準に合わせるため、露出度の高い女性キャラクターの服装を描き直す作業に追われたという。
ゲーム会社の幹部のひとりは「アップルは、国境を超えて表現を規制する力まで持った。しかし本来は、国や企業がそれぞれの文化や戦略に合わせて考えるべきことなのでは。現状では、毒っけのあるコンテンツはつくれない」と話す。

148:デフォルトの名無しさん
20/01/07 18:36:15.80 f028J8AQ.net
昔の chip8 という CPU エミュレータが一瞬で起動しちゃう:
URLリンク(blog.scottlogic.com)
URLリンク(colineberhardt.github.io)
二番目のリンク先で、start というボタンをマウスでクリック後、wキーを押すとブロック崩しの様なゲームが動き出す。
キーボードのqで左、eで右にラケットが動く。

149:デフォルトの名無しさん
20/03/11 16:21:40.05 QRZvOF73.net
URLリンク(yutakaaoki.github.io)
MessageBox が出せるようになった。
C++のプログラム中で
nexMessageBox("タイトル文字列","メッセージ文字列", MB_OKCANCEL);
などとすると、ボタンが押されるまでその場で停止する。
JSやブラウザ、Wasmでは、本来、「その場で待機」することは出来ないので、
nwsc の bsync, bwait, bresume 機構を用いている。

150:デフォルトの名無しさん
20/03/11 16:24:14.20 QRZvOF73.net
>>145
なお、JSとC++の組み合わせる際に、ちょっとした問題があって、今のところ、トータル200個以上のWindowを生成すると異常を来たすので、決して、ダイアログを何度も生成しないでね・・・。
理論上は直せるけれど、まだ直せてない。

151:デフォルトの名無しさん
20/03/11 19:28:39.62 SBKaA+2H.net
STLが使いたい。

152:デフォルトの名無しさん
20/03/11 20:30:36.35 QRZvOF73.net
>>147
以下は他のコンパイラを使う場合は関係ない話だけど。
コンテナ類は、C++ nexでも本家C++以上に便利になるように独断と偏見で独自サポートしている。
STLは、templateをかなり深く使用していると思われるので、C++ nex側のそれに追いつけなければ、そのままではSTLのコンパイルは難しい。
なお、今のところtemplateを簡単に使えるようにしたtemplなるものを C++ nexでもサポートしているが、本家C++のtemplateも徐々にサポートしていく予定。

153:デフォルトの名無しさん
20/03/27 04:03:07.14 VaiYZBCN.net
Wasmアプリは次のようなことで需要がありそうだ:
・nativeアプリの場合、ストレージの容量制限でインストールできない事があるが、
 Wasmならブラウザ内で動くのでその心配は少ない。
・nativeアプリの場合、インストールするのに新しいVersionのOSを要求されること
 があるが、Wasmなら、余り関係ない。

154:デフォルトの名無しさん
20/03/27 04:06:39.29 VaiYZBCN.net
>>149
nativeアプリの場合、Win7で動いていたものがWin10で動かなかったり、逆に、Win10を要求されたり
する。
Androidアプリの場合も、バージョン○○以上が必要条件などとあったりする。
ところが、Wasmアプリの場合、余りそういうことは無い。
ブラウザのバージョンが有る一定以上のものでありさえすれば、OSの種類やバージョンに関係なく動く可能性が高い。

155:デフォルトの名無しさん
20/03/27 04:51:51 VaiYZBCN.net
アプリストアにはアプリが多すぎて、まみれてしまう。
ウェブアプリなら、検索エンジンからダイレクトに探せるのでアプリストアよりは、まみれる度合いがましになる。

156:デフォルトの名無しさん
20/03/27 05:08:06.41 VaiYZBCN.net
・WasmやPWAが、TwitterやLineなどでshareし易いことは、
 企業にとってはのどから手が出るくらい価値がある。
 nativeアプリだと気に入ったアプリを友達にシェアしにくいが、
 WasmアプリだとURLだけですぐにシェアできる。これはアプリの普及や
 宣伝にとって意義は大きい。
・PC/Mac/iPhone/Androidで見た目や使い勝手が同じであることは、
 アプリのブランド価値を高める。
 これは、コンビニが全国で同じレイアウトと品揃えであることで
 安心感と利便性を高めることで勝ち残ってきたことと通じるものがある。

157:デフォルトの名無しさん
20/03/27 05:14:54 VaiYZBCN.net
企業にとっては、プラットフォームごとにビルドし直さないでよいことだけでも
価値は大きい。
マル�


158:`プラットフォーム対応なのに最終プログラムが1種類だけで済むことは メンテナンス性は劇的に向上する。 nativeアプリをマルチプラットフォームに対応させる場合、OSごとにビルドされた 最終プログラムのバックアップだけでも慎重を要し、生産性が下がる。 開発時にはいちいち、各プラットフォームごとにビルドする時間と手間、 テストが必要で、その時にトラブルも出易かった。例えば、 新しいバージョンのAndroidが出てきたら、新しいAndroidSDKをインストール しなくてはならないが、それでツールキット側のバージョンが合わなくてトラブル が発生し、その解決のために一週間以上も無駄になることもあっただろう。 Wasmなら、最終プログラムは一度ビルドするだけで済むのでそのようなトラブルが 生じないし、テスト工数も激減する。



159:デフォルトの名無しさん
20/04/13 18:12:02 iwZw4XGM.net
MDI Child Window に対応 :
URLリンク(yutakaaoki.github.io)

160:◆QZaw55cn4c
20/04/13 21:47:32 fZC6wvDm.net
>>153
で、ブラウザごとにデバッグするわけですか…

161:デフォルトの名無しさん
20/04/13 23:46:07 iwZw4XGM.net
>>155
HTML5は他企業も含めた共通規格なので、一度決まった仕様は比較的安定して動作するため、ツールキット側が一度デバッグしてあれば、そので動くアプリは1つのブラウザで動作チェックしさえすれば、ツールキットがサポートしているどのブラウザでも動作し易い。

162:デフォルトの名無しさん
20/04/14 00:37:46 ESEtnroG.net
HTML5はGoogleの規格なので、Googleの都合でいかようにも変わると思います。

163:デフォルトの名無しさん
20/04/14 01:07:56.72 tGjJf6XN.net
>>157
確かにFireFoxのMozillaもGoogle傘下にあるようなものだし。
でも、SafariやEdgeもあるので、今まで動いていた古い仕様が動かなくなる可能性は割と低そうという希望的観測がある。

164:デフォルトの名無しさん
20/04/14 01:12:20.23 tGjJf6XN.net
でも、実行プログラムがindex.htmlとmain.wasmなどの1種類で、
プラットフォームごとにビルドし直さなくて良いというのは安心感はある。

165:
20/04/14 19:22:31.95 42R+WK0w.net
>>156
write once, run anywhere といわれていた Java JVM も、蓋を開けてみれば write once, debug anywhere となってしまった現実をご存知ですか?

166:
20/04/14 19:23:13.73 42R+WK0w.net
>>159
でもデバッグは各ブラウザ毎にしないといけませんね…

167:デフォルトの名無しさん
20/04/15 14:42:27 mfdeAm0A.net
>>161
やはり、「XX OS対応」と書くためには、XX OSでテストする必要はあるでしょう。
ただ、ビルド回数が少なくて済むことは時間の節約になりますし、
他の事で手一杯の忙しいときに、あるプラットフォーム向けのビルドだけ
(起きるはずも無い)エラーが起きてその対応に追われる心配も無いです。

168:デフォルトの名無しさん
20/04/15 14:46:20 mfdeAm0A.net
>>162
1. Win/Android/iOS/Mac/Linuxで最終テストは必要。
2. しかし、ソース修正後、ビルドは一度だけでよい。
3. 2.により、仕上げの段階で1箇所修正するだけで5つのプラットフォームごとに
 5回ビルドして5回テストする、という効率の悪い事態は起きない。

169:デフォルトの名無しさん
20/05/25 03:25:23.82 Q3BVyDlx.net
あがれ

170:デフォルトの名無しさん
20/05/28 17:15:51 1yt8qEqJ.net
懸念事項だったローカルファイルシステムへのファイル保存について、
今後の Edge Browser では何か進展が有るらしい。

Native file system access
Up until now websites were not allowed to save files in a specific location on the user device.
This meant that online photo editors required users to upload the photo they wanted to edit and then download it to their device, while a native one would have just given the option to replace the existing one.
Starting from Edge 86 (version 83 is the latest one at the time of writing) developers will be able to replace all files the user selects in a session, thus enabling productivity apps on the web to even more useful.

171:デフォルトの名無しさん
20/05/28 17:47:36.62 1yt8qEqJ.net
>>165
どうやら、PWAアプリを起動時に指定したファイル群に、ユーザーにファイルダイアログで毎回選択させること無くいつでもアプリがプログラム的に書きこめるようになるらしい。

172:デフォルトの名無しさん
20/07/14 00:20:51.75 cduOb3hQ.net
age

173:デフォルトの名無しさん
21/03/11 04:16:55.67 +SL5WZRG.net
wasmからGPU使うにはWebGL呼び出しになりますか?

174:デフォルトの名無しさん
21/03/20 23:25:10.94 j+8OkN/E.net
>>168
WebGPU は使ったことは無いが、WebGL 以外に WebGPU もある。
Wasmはそれ自体では副作用や入出力は行えないので、やりたいときはJSを
使うことになるので、GPUを使いたい場合は、JSでGPUを使う方法を調べる
ことになる。Wasmは、EM_ASM 文などの中に書いた JS コードを呼び出す
ことで副作用や入出力を行う。

175:デフォルトの名無しさん
21/07/10 01:15:43.14 dgZojN/o.net
Wasm ならどんな言語でも同じだろ

176:デフォルトの名無しさん
21/09/14 18:18:01.42 Wng5bteL.net
age

177:デフォルトの名無しさん
22/02/04 02:46:38.22 tMDf8XuC.net
age

178:デフォルトの名無しさん
22/06/21 12:20:06.79 TERGIQkG.net
WebAssemblyを普及させたい
☆WebAssembly総合
・Wasmer - The Universal WebAssembly Runtime
URLリンク(wasmer.io)
-> WASI(WebAssembly System Interface)とEmscriptenに準拠したWASMを実行できるランタイム
・WAPM - WebAssembly Package Manager
URLリンク(wapm.io)
-> WebAssembly製ツール/ライブラリのパッケージマネージャー

☆C/C++
・wasi-sdk - WASI-enabled WebAssembly C/C++ toolchain
URLリンク(github.com)
-> WebAssemblyのLLVM、clangコンパイルサポート
Emscriptenとは異なりWASMバイナリのみ生成する

☆Rust
・wasm-pack - your favorite rust -> wasm workflow tool!
URLリンク(github.com)
-> WebAssemblyのrustcコンパイルサポート
Yew - Rust / Wasm framework for building client web apps
URLリンク(yew.rs)
-> WebAssembly によってマルチスレッドな Web アプリのフロントエンドを作ることができる、モダンな Rust のフレームワーク

179:デフォルトの名無しさん
22/06/21 12:28:27.45 TERGIQkG.net
最近のWebAssemblyのニュース
Publickey - Enterprise IT × Cloud Computing × Web Technology / Blog より
URLリンク(www.publickey1.jp)

180:デフォルトの名無しさん
22/06/23 17:39:28.38 fwy13iz2.net
WebAssemblyが気になるので調べてみた - Qiita
URLリンク(qiita.com)

181:デフォルトの名無しさん
22/06/23 18:38:00.25 fwy13iz2.net
WebAssembly活用プロジェクト
URLリンク(madewithwebassembly.com)

182:デフォルトの名無しさん
22/06/23 21:37:11.74 fwy13iz2.net
WebAssembly Powered Augmented Reality Sudoku
This project makes use of the WebAssembly build of OpenCV (a C++ computer vision library), Tensorflow (a machine learning library) and a solver written in Rust. It neatly demonstrates how WebAssembly allows you to write performance-critical web-based applications in a wide range of languages.
URLリンク(github.com)
SolverURLリンク(raw.githubusercontent.com)

183:デフォルトの名無しさん
22/06/24 00:36:37.46 LDIZz9eS.net
WASMとRustはVue.js/React.jsを打倒するのか? - JSへの侵略の歴史
URLリンク(zenn.dev)

184:デフォルトの名無しさん
22/06/24 00:38:27.46 LDIZz9eS.net
Typescriptの次はRustかもしれない
URLリンク(zenn.dev)

185:デフォルトの名無しさん
22/07/03 14:38:54.59 y5Z2gZOd.net
WASMのビルド作業はやたら面倒臭いが、何かビルド用ツールが出てるのかな
Linux環境じゃないとconfigureが生成できないから、プロジェクトのビルドなんてやってられないだろ
ところでWASMに64bitメモリが実装されれば可能性が大きく広がる予感

186:デフォルトの名無しさん
22/07/03 15:41:32 2unnqsUi.net
>>180
Linuxの話題は、あわしろを召喚しちまうから、やめとけ。

187:デフォルトの名無しさん
22/07/03 16:58:00.23 y5Z2gZOd.net
あわしろって誰?w
WASMのroadmapを見ると、Firefoxが一番進んでるみたいだ
何だかんだFirefoxは開発者向けとしては最先端を走り続けているんだな

188:デフォルトの名無しさん
22/07/03 17:11:46.18 6NN4RBvO.net
Linuxの掟とか唱えてる人じゃなかったっけ?

189:デフォルトの名無しさん
22/07/03 20:06:52.80 SwvkPEGK.net
age

190:デフォルトの名無しさん
22/07/03 20:29:55.44 o4Z3tiIf.net
>>182
あわしろ氏って誰?QZ より頭いいの?

191:デフォルトの名無しさん
22/07/03 23:33:33.23 C1pvOjRy.net
あわしろは、Linux 総帥
よく雑誌に記事を書いている

192:デフォルトの名無しさん
22/07/04 01:35:21.33 nNTJcKgT.net
マナーにうるさい
おまえはLinuxを使う資格がないが口癖

193:デフォルトの名無しさん
22/07/04 02:35:19.54 hEC4WOUu.net
>>177
えぐ

194:デフォルトの名無しさん
22/07/04 07:02:36.02 E8MuawGm.net
>>173
>wasi-sdk
GLESやSDL2の対応はどうなんだろ
誰かちゃちゃっと準公式サイトを作ってくれないかなw

195:デフォルトの名無しさん
22/07/05 08:37:06.79 HXH2KDmV.net
WASMではまだ並列処理が弱いのが悲しい所だな
Web Worker使えるけど、window配下オブジェクトが共有できないからな

196:デフォルトの名無しさん
22/08/05 10:52:36 WoKhwB7u.net
>>189
対応してないはず。

197:デフォルトの名無しさん
[ここ壊れてます] .net
wasm

198:デフォルトの名無しさん
[ここ壊れてます] .net
現在、Rubykaigi で、Ruby の Wasm 対応についての話しになっているらしい。
Ruby3.2から正式にブラウザでRubyが使えるようになる予定なので、
Rubyのインストールが難しい初心者にとっても楽になるとの事。
また、irb(インタラクティブRuby?)がブラウザでも動いて、対話的に計算
できるらしい。
Rubykaigiは、9/8から9/10の三日間の予定らしい。

199:デフォルトの名無しさん
22/09/08 14:13:55.50 2tFquaAS.net
Rubyは、おわこん
とKENYAも言っている

200:デフォルトの名無しさん
22/09/08 21:16:10.23 EF/qt7ve.net
Ruby on Rails 7 で、Rubyの検索数が増えているらしい。
新しい変更があると、検索数が増えるみたい
JavaScript(JS), Python の検索数が多いのは、素人が多く、難しいからかも。
逆に、Rubyの検索数が増えないのは、プロが多く、簡単だからかも
Rails 7では、Hotwire などの新機能が出たので、プロも検索したのかも
米国年収では、JSが6万ドル、Railsが9万ドルと、かなりの差がある。
素人とプロの開発者の違いかも
JSは素人や個人開発が多く、
Railsは小企業から大企業まで、プロが多いのかも

201:デフォルトの名無しさん
22/09/09 01:00:16.49 NUzzWOKg.net
rubyのwasmに需要があるかどうかは置いといて、新技術を積極的に取り入れる姿勢は評価できる
これでもっとwasmが普及するといいな

202:デフォルトの名無しさん
22/09/09 01:26:40.60 OjVwznsu.net
ブラウザ上でWasmを使うサービスやアプリならばRuby利用は遅くて重くて大きくて不利だね
だからどうしてもRubyをブラウザ上で動かしたい遊び目的だけかな
Wasm使ってプログラミングしたいならC++かRustのどちらか

203:デフォルトの名無しさん
22/09/09 02:28:27.53 n8dQNxep.net
Ruby は遅くても、可読性が高くバグらないから、高品質でプログラミングしやすい。
C++, Rust などは難しさが桁違い
ビジネスでは、Rubyよりもかなり遅れる。
他社に市場シェアを取られてしまう
例えば、SASS がそう。
Rubyで作られて、C++ で作られるまで数年以上遅れた。
次に、C++で保守出来なくなって、Dart へ移った
Rubyは可読性が高いから保守できるが、
他の言語は無理で、最終的に放置されるだけ

204:デフォルトの名無しさん
22/09/14 08:03:14.57 ZrnGb3cN.net
>>198
ところがRustはRubyに似ていて可読性が高いよ
RustはRubyとクロージャ引数の記述方法も |x| で同じだし
RustはRubyと同じようにイテレーターのメソッドチェーンを多用できるし
もちろん遅延評価されるし
Rubyよりも改善されてる点も多いからRustはRubyよりも可読性が高いよ

205:デフォルトの名無しさん
22/09/26 11:00:46.19 NmZ8KQlQ.net
>>199
Rustは俺が知ってる言語の中で、実用的な言語の中では最も可読性が低い
部類に入る。

206:デフォルトの名無しさん
22/09/26 13:14:00.63 fgpUNuss.net
>>200
Rustは可読性の高さで気に入っている
ほとんどの言語と比べてイーブンか上
Wasm記述で現実的な言語の中だと更に
可読性の低いC++は論外だから
調査研究でもRustが最も使われている

207:デフォルトの名無しさん
22/09/26 14:28:49.61 TCGzsvbI.net
可読性という人によって解釈が異なる単語じゃなくてどういう要素が可読性を高めている/低めているか説明して欲しいな

208:デフォルトの名無しさん
22/09/27 16:07:51.55 vP3LfdbR.net
この板のRustのアンチスレにも、Rustの分かりにくさについてのサンプルコード
があがってる。

209:デフォルトの名無しさん
[ここ壊れてます] .net
下手くそに書かれたコード�


210:ェ読みづらいというのは言語の問題なのかね?



211:デフォルトの名無しさん
22/09/27 20:29:03.01 ltFhtHvy.net
>>204
それはウソで、Rustはどうせきれいに書けない。

212:デフォルトの名無しさん
22/09/28 00:49:27.76 JQpGo85s.net
>>205
あなたにとってはあらゆるRustコードは綺麗には見えないということですね
好みの問題では?

213:デフォルトの名無しさん
22/09/28 01:04:38.83 JQpGo85s.net
>>205
ここじゃ迷惑だから続きはアンチスレでよろしく

214:デフォルトの名無しさん
22/09/28 15:21:20.76 01v6ubok.net
>>206
長ったらしくて煩雑。

215:デフォルトの名無しさん
22/10/02 18:22:14.52 fl0K/H95.net
Rustは抽象化されたプログラミングによって分かりやすく短く書けるね
タイプ数を少なく短く書けるという意味ではなく

216:デフォルトの名無しさん
[ここ壊れてます] .net
>>209
そうは思えないが。

217:デフォルトの名無しさん
[ここ壊れてます] .net
>>209 散々C++で痛い目をみた人が作っているからね。現実的なモノでしょうね。

218:デフォルトの名無しさん
[ここ壊れてます] .net
>>211
そうでもなかろう。

219:デフォルトの名無しさん
22/10/30 00:34:23.75 CRXE5x4x.net
オンライン FM シンセサイザ:
URLリンク(yutakaaoki.github.io)

220:デフォルトの名無しさん
22/10/30 16:23:33.75 tfYpbifo.net
age

221:デフォルトの名無しさん
22/11/08 18:21:56.35 Rs+gm7Tf.net
age

222:デフォルトの名無しさん
23/01/06 22:20:11.40 +u5r9Ozg.net
Rubyにおけるwasmランタイム実装のCRuby、バイナリサイズはstdlib込みだと25MB、brotli圧縮かけて5.0MBだってさ
微妙だけどキャッシュ込みなら5.0MBはギリ許せるのか、、?
URLリンク(logmi.jp)

223:デフォルトの名無しさん
23/01/07 16:27:35.31 /1wD2KzB.net
>>216
まだ大き過ぎる。

224:デフォルトの名無しさん
23/01/07 16:34:06.31 St5PAkDm.net
>>217
だよねぇ、、うーん

225:デフォルトの名無しさん
23/02/10 08:51:49.30 wdaGPD+T.net
キタコレ
wasmにgc搭載
URLリンク(www.publickey1.jp)

226:デフォルトの名無しさん
23/02/12 13:09:16.81 HnI2C6C6.net
>>219
これが標準化仕様になるんかね

227:デフォルトの名無しさん
23/04/20 11:24:36.10 rsMxrIXz.net
うおおおお

サーバサイドWebAssemblyに、かつてのCGIの仕組みを取り込んだ「WCGI」をWasmerが発表。すぐ起動し安全に分離されるWebAssemblyの特長が活きる
URLリンク(www.publickey1.jp)

228:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch