Google NaCl プログラミング 2mol

1 ：2011/02/25 〜 最終レス ：2013/09/20

GoogleのNaCl環境でプログラミングする人のためのスレ
Chromeブラウザーは7から--enable-naclオプションを付けて起動するとNaClが有効になります。
※ Chrome 10.x 以降推奨
Native Client SDK : ttp://code.google.com/intl/en/chrome/nativeclient/
Examples: ttp://code.google.com/intl/en/chrome/nativeclient/docs/examples.html
More Examples: ttp://code.google.com/p/naclports/source/browse/#svn%2Ftrunk%2Fsrc%2Fexamples
前スレ
http://hibari.2ch.net/test/read.cgi/tech/1291875057/

2 ：

ttp://sourceforge.jp/magazine/11/02/22/104206
　米Googleは2月18日、C/C++で実装されたネイティブコードをWebブラウザ上で実行できる
「Native Client Software Development Kit（SDK）」の最新版を公開した。
Windows、Mac OS X、Linuxに対応する。

3 ：

JavaApplet というよりは ActiveX だよね
ttp://slashdot.jp/it/08/12/10/0836211.shtml
ttp://slashdot.jp/it/10/03/20/0554238.shtml

4 ：

Native Client SDK : ttp://code.google.com/p/nativeclient-sdk/
NaCl ports : ttp://code.google.com/p/naclports/
Gallery: ttp://naclports.googlecode.com/svn/trunk/src/gallery/index.html

5 ：

NaCl に興味があるなら、インストールして試してみると良いよ
Google が開発しているプログラム実行環境（Native Client :
C/C++, Native Activity : C/C++, Dalvik : Java, V8 : JavaScript、
Go : Go、Unladen Swallow : Python）の中でどれが一番長生き
するか調べて、ブログにでも載せておいてくれると助かるわ

6 ：

206 デフォルトの名無しさん [sage] 2011/02/23(水) 00:30:05.97 ID: Be:
    かってに、google に甘い期待をしているんだけど、
    ttp://sourceforge.jp/magazine/11/02/22/104206
    これとかを見ると、google 的には、
    C++ は Web アプリみたいにして、
    Android に持っていくつもりなのかな。
    プログラマのヘマでセキュリティーホール作られるよりは、
    制限あっても、sandbox 内で…って感じで。
    Javaが選ばれた理由も、そんなんじゃなかったっけ？

7 ：

207 デフォルトの名無しさん [sage] 2011/02/23(水) 02:12:51.53 ID: Be:
    Android 2.3 以降の Native Activity も sandbox 内で動くみたいね
    NaCl と融合する可能性はあるのかな

8 ：

212 デフォルトの名無しさん [sage] 2011/02/23(水) 10:55:37.75 ID: Be:
    >>206
    面白そうだけどChromeでしか動かないって
    ChromeOSのサブプロジェクトかなんかか

9 ：

214 デフォルトの名無しさん [sage] 2011/02/23(水) 13:06:31.99 ID: Be:
    >>212
    FirefoxとかOperaでもすぐ使えるようになるのでは？
    http://slashdot.jp/it/08/12/10/0836211.shtml

10 ：

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

11 ：

Nixysaという半自動でNPAPIのコードを書いてくれるツールが使えるかも。
http://code.google.com/p/nixysa/
基本的にはいきなりNaClというよりまずNPAPIを使ったプラグインを開発できるようになったほうがよさげ。
多分プラグインとして動けばNaCl化は難しくない。

12 ：

2ch関連スレ。chromiumブラウザー
http://hibari.2ch.net/test/read.cgi/software/1278083626/l50

13 ：

chromiumブラウザーのデザインドキュメントがかなり役に立つ。
https://sites.google.com/a/chromium.org/dev/developers/design-documents

14 ：

17 デフォルトの名無しさん [sage] 2011/01/05(水) 21:24:56 ID: Be:
    あ、こっちにスレあったのね。
    NativeClientって、当初のx86コード利用って方針からポータビリティを重視して
    LLVMのビットコードを使うようになるんだよね？
    それって、Zero/SharkのJavaVMと比べて何が違うの？
    というか有利なの・・・？
    JVMのネイティブコードキャッシュが出来る機能を突き進めた方が幸せにならない？
    ・・・か。
    自社だけでコントロール出来ない物は改変しちゃえってことだもんなぁ。Dalvikみたいに。
18 デフォルトの名無しさん [sage] 2011/01/05(水) 21:48:04 ID: Be:
    そうなの?
    最近追っかけてないからよく知らないけど、それは朗報だな。
    LLVMのビットコードで送りつけて、現地でマシン語にコンパイルする方式は俺的にグッジョブだわ。
    昔それを考えていた。

15 ：

>>1 乙

16 ：

前スレ落ちてたんだね。スレ立て乙です(^_-)-☆

17 ：

前スレってレス20くらいで落ちてた気がするので
今回も過疎ってると落ちるかもね

18 ：

じゃあ勉強がてら練習ソースうｐする

19 ：

wktk

20 ：

>>1
　　 n ノノﾉハヽ
　　(ﾖ川´・�D・)＜乙です
　　　Y 　　 　　つ

21 ：

2molとは粋な計らいを・・・

22 ：

これがこのスレでの初めての書き込みなのに、俺が書いたレスが既に張ってあるから、
もう書く事無いよ。NaCl/ARM が Android で動くとかすればなあ。

23 ：

そうだね

24 ：

NaClって分子じゃないのに何でmolで数えるんだろう

25 ：

逆にどう数えろと…

26 ：

［訂正記事］グーグルのNative Client、CPUに依存しない互換性は将来のバージョンにて 2010年3月21日
ttp://www.publickey1.jp/blog/10/native_clientcpu.html

27 ：

GoogleのNative ClientでWebアプリケーションのパフォーマンスを改善する
作者 Abel Avram , 翻訳者 笹井 崇司 投稿日 2010年4月16日 午後3時8分
ttp://www.infoq.com/jp/news/2010/04/Google-Native-Client

28 ：

Google が頑張って IE と Safari と Firefox 向けに NaCl の Plug-in を作ったとして、
これが普及する芽はあるのかなあ。iPad / iPhone 向けには Plug-in は作れない訳だし、
JavaScript がこれだけ力を持つと、ひっくり返せるものなんだろうか。

29 ：

GoogleがNative Clientを刷新。が、最後までやり遂げるだろうか？
作者 Dionysios G. Synodinos , 翻訳者 南 伸二 投稿日 2011年2月23日 午後7時42分
ttp://www.infoq.com/jp/news/2011/02/google-revamps-native-client

30 ：

Native Client: A Technology for Running Native Code on the Web
Monday, December 08, 2008 | 12/08/2008 11:58:00 AM
ttp://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html

31 ：

ポータブルにならないなら
普通にexe配布した方が良いお
Native Clientの仕組みはどうなっているのか？
ttp://d.hatena.ne.jp/yaneurao/20081211

32 ：

いまさら劣化ActiveXもどきか。

33 ：

ActiveXというよりJavaでしょ

34 ：

>>33
いや、JavaとActiveXの公約数。

35 ：

ActiveXのように速いJava
Javaのように安全なActiveX

36 ：

Java じゃなくて Java Applet な

37 ：

っつーかjavascriptで充分だろ

38 ：

NaCl の話を聞く度に O3D が思い出される
あれも最初は Plug-in でやろうとしたけど、結局は JavaScript でも
十分な速度が出るという結論だったんだよね

39 ：

ほしゅ

40 ：

すげえなこれ10の24乗コ目のスレなのか

41 ：

1モルは6.02×10^23です。
2モルだからといって24乗に階乗を変更することはしません。

42 ：

1mol 6.02×10^23 が正しければ
2mol 1.204×10^24 も正しいと思うんだけど
釣りなの？

43 ：

アボガドロ数は化学ではあまり使わんなああ。

44 ：

組成比で重量％とｍｏｌ％はどっちも良く使うよ

45 ：

おまいら NaCl の話しろよ

46 ：

有効数字って知らないの？

47 ：

10年以上前に出てきたActiveXのさらに劣化した技術だからなあ。

48 ：

ほしゅ

49 ：

ほ

50 ：

ブラウザでエディタが動く時代が来るのか
viとかメーラーとか移植されそうだな
あ、googleってクライアントメーラーってやらないのかな

51 ：

Qt4 on Android の方が面白そうだからあっちいく

52 ：

ノシ

53 ：

NaCl最近動きないね。
みんな注目してないのか

54 ：

ブラウザの中でネイティブを動かしたいニーズが無くなってしまったからな。FlashとSilverlight共々逝く気がする

55 ：

Nacl・・・おれはあえてナックルと呼ぶぜ！

56 ：

>>53
時代は JavaScript を拡張して行く方向だと思うよ
何が哀しくてブラウザ上で C++ なんか使わないといけないんだろうね・・・

57 ：

JavaScriptが良いとは思わないけどなあ
サンドボックス内部でC++（ネイティブコード）を使うのが一番言いい。
WebGLとかダメでしょ、あれ

58 ：

別に自分の好みを通すのは好きずきなんじゃないの。
時代は WebGL の方に進んでるから、気が向いたらこっちに来なよ。

59 ：

>>56
C++のコードがjavascriptから呼べるんだから便利だよ

60 ：

>>59
C++ を書きたい人が書く分には良いんじゃないの
既存のコードをそのまま動かしたいとかね
それでもフルパワーの C++ が使える訳ではないし、テストや
メンテナンスの手間を考えると、かなり敷居が高いと思うよ

61 ：

Googleのやることって、特徴は無料ってだけで、今更ってのが多い。

62 ：

あげとくか

63 ：

やっとGoogle Chrome 10.0がUbuntu/Debianに回って来た。
ちょっと遊んでみるかな?

64 ：

hosu

65 ：

日本オワタ

66 ：

放射性NaCl

67 ：

雨には放射能が含まれていると危険だから
必ず傘をさすようにってお天気で毎回言った方が良い

68 ：

>>67
放射性物質だろ。水は陽子と電子だけだから放射能を持つことはない。

69 ：

水素や酸素にも同位体はありますよ
同位体がなぜ放射能を持つかどうかは良くわかってない

70 ：

HもOも放射性同位体の半減期短いのばっかりじゃんw
雨が危険、っていうのは、小学生でも知ってるように雨粒は空気中の埃を核にして
形成されるからだと思うけど。
今回の件で放射性物質の埃がある程度上空に排出されたのは間違いなからね。

71 ：

真水で冷却出来ずに塩水使ったのが間違いだったね
高温でイオン化したナトリウムが水と反応して爆発したんだよ

72 ：

どんなトンデモ化学だよそれ

73 ：

73

74 ：

原発がんがれ

75 ：

高吸水性ポリマーで汚水流出止めようとしてるみたいだけど塩分があると効果ないんだって
ttp://www.kyoto-be.ne.jp/sagano-hs/exam/rika_jyunbishitu/photo/add_NaCl.wmv
http://www.kyoto-be.ne.jp/sagano-hs/exam/rika_jyunbishitu/023.htm

76 ：

ほ

77 ：

.

78 ：

Tcl、GoogleのNative Clientに対応した「NaTcl」を発表
http://slashdot.jp/developers/11/04/15/181223.shtml
凄いんだか凄くないんだかさっぱりわからんw
Googleは今でもNaClをプッシュしてるの？

79 ：

こんなスレあったのね
WebKit党Safari派だがぐぐるも好き、LLVM注目中なので記念カキコ
ときどき見に来る
/.Jで出たの知って、悶々としてたので書かせてくれ
>>78
NaTclって物質ないじゃんね
もうちょいましな名前はなかったのかと
といっても、ささっと対案は出てこずｗ

80 ：

サーバー側コーディング不要のGoogle App Engine開発環境「jsonengine」（1/2）：CodeZine
http://codezine.jp/article/detail/5690?p=1
サーバー側コーディング不要のGoogle App Engine開発環境「jsonengine」（2/2）：CodeZine
http://codezine.jp/article/detail/5690?p=2

81 ：

GAEは携帯認証がな…。
GAEにも、NaCl入るようにならないかな

82 ：

ん？
鯖は関係ないんじゃない？

83 ：

うん。直接関係ない。
だが、ブレスト的にというか、無理やりくっつけて考えてみた
NaClってのは、きちんとサブセット化されたELFバイナリ、
サンドボックス、RPCで成り立ってる
これを、GAEが受け入れれば、言語制限ってものが取り払われるんじゃないか
Perlやりたい？NaClでPerlビルドすればいい
RubyだろうとLUAだろうとおなじこと

84 ：

GAE と何の関係が？

85 ：

Tcl、GoogleのNative Clientに対応した「NaTcl」を発表
http://slashdot.jp/developers/11/04/15/181223.shtml
> スクリプト言語TclをGoogleのNative Client環境で実行可能な「NaTcl」が発表された。
> NaTclを使用することでTclをWebブラウザ上で実行可能となり、Tclプログラムで
> Google ChromeのDOM(Document Object Model)に直接アクセスできる。これにより、
> JavaScriptの代わりにTclでWebアプリケーションを作成することが可能となる。
> また、Natice Client向けのTk、「NaTk」もまもなくリリースされるとのこと。
これでTcl/Tkの新しい本が出るようになるかな？

86 ：

chrome://plugins
に、NaClが出てくるけど、ここからも有効化できるのかな？

87 ：

>>85
多分できる。
試しに有効にしてみたら動いた。

88 ：

sdkのバージョンが0.3になってた　Chrome12のためだけみたいだけど

89 ：

NaClって名前がいいな

90 ：

かそ

91 ：

基盤技術過ぎて、華はないなｗ
なんとなく見てるんだが、Chrome OS のRPCにも使えるようになるんだよね、きっと

92 ：

スゲー興味有るんだけど誰も使ってなさそうで怖い

93 ：

今GPU使える？せめてシェーダー言語だけでも走らせる事ができりゃいいんだけど。
あとは自作するから。

94 ：

Unity Technologies: Notes on Native Client & Pepper Plugin API
http://blogs.unity3d.com/2011/06/02/notes-on-native-client-pepper-plugin-api/

95 ：

ActiveXの劣化コピー

96 ：

ActiveXはNaClのサブセット

97 ：

ActiveXは、よく脆弱性持ち込んでたような、、、

98 ：

NaClはよくは知らんがActiveXは完全信頼モデルなのがいかんかったのだろ？
NaClはプロセス分離とかで部分信頼モデルもどきぐらいにはするつもりじゃないの？

99 ：

hosh

100 ：

MSがWebGLはセキュリティが駄目だと言ったから
NaCl使ってOpenGL使うのが流行るんじゃね？

101 ：

WebGL は、セキュリティの問題は ARB で対応する予定でしょ

102 ：

http://shaver.off.net/diary/2011/06/17/a-three-dimensional-platform/

103 ：

「Chrome」の徹底的な改修を開始したグーグル--セキュリティ向上を目指す
http://japan.cnet.com/news/commentary/35004398/
> Googleが「Native Client」と呼ばれる安全性の高い基盤の上で、
> 「Chrome」を徹底的に作り直す作業を開始したとの情報を、米CNETが入手した。

104 ：

Native Clientって全然話題にならないけど
プロジェクトとして生きてるの？

105 ：

ChromeOSもChromeもJSからプラグインぐらいまでは移す計画してるんじゃない？
いまんとこ、セキュアなネイティブサンドボックスなんて、脱研究室レベルではGoogleしかできてないけど、第一線のプロジェクトなことは間違いないとおもうよ。
ここ数年でものになるなら、ARM版がすでにあるのでスマートフォンやタブレットでの電力改善が一番大きい。
x86とARM以外ではLLVMでユニバーサルって話だから汎用性もあることにはなっている。

106 ：

す

107 ：

じ

108 ：

>>102

ゴミが散らかってんじゃねえよ

109 ：

ほｓ

110 ：

ネイティブサンドボックスって、いまや普通。

111 ：

ウェブアプリは JavaScript で割と満足なんだけど、ネイティブコードのニーズってあるのかな?

112 ：

ソース隠しかな

113 ：

>>111
Java屋とか.NET屋とかからは、JavaScriptは使えば使うだけ生産性落とすって言われてるけどもね。
動的な型付けとか、ソースコード配布な辺りとか、テストしにくい辺りが。
かといって、ネイティブコードがいいかというと良くないけども。

114 ：

>>111
Flash Playerそのものを動かすとか。
マルチメディア系のプログラムを動かすとか。
メンドいデプロイを楽ちんにするとか。

115 ：

JavaScript 自体が、でかくて重いプログラムを走らせるような設計になっていない。

116 ：

ブラウザ上ででかくて重いプログラムを走らせ様と考えるのは勘弁してくれ
JavaScript だと重いタスクはサーバ側に丸投げするだろ

117 ：

あー、でも最近はそうでもないか
JavaScript の処理速度はかなり上がったから、割と何でも気軽に JavaScript で実装出来てるわ
JavaScript で実装した他の言語のランタイムや、OS の仮想マシンも幾つかあるよね

118 ：

>>117
http://jsbin.com/ubiyay/3/edit#preview
WebGLのスレにあったヤツだが、ここまで遅いと話しにならんだろ。
>>116
そんな処理サーバーに投げたらサーバー死ぬだろ。
クライアントは1台じゃないんだから。

119 ：

>>118
>そんな処理サーバーに投げたらサーバー死ぬだろ。
どんなサーバのどんな処理かの前提も無しに面白いことを言うね

120 ：

>>118
WebGL 普通にサクサク動くけど?
http://syllab.fr/projets/minecraft/minecraft.html

121 ：

>>118
WebGL 普通にサクサク動くけど?
http://alteredqualia.com/

122 ：

>>119
>ブラウザ上ででかくて重いプログラム
がするような処理じゃないのか？

123 ：

>>122
具体的にどんな処理?

124 ：

>>116　に聞けよ。

125 ：

>>124
『君は』どんなプログラムを前提にして話してたの?

126 ：

>>123
マジメな話、Google MapをGoogle Earthに置き換えるとかだろ。
あと、youtubeの動画編集をyoutube内でするとか。
てか>>114-116の流れ見れば具体的な話が解ると思うけど。

127 ：

>>126
考えてみたけど、動画の編集は NaCl で作っても簡単には行かないと思うわ
ちょっとエフェクト足す程度なら JavaScript でも出来そうだし、ガシガシ
編集するなら制限の無いローカルアプリの方が圧倒的に良いし、微妙な感じ

128 ：

スマホアプリのほとんどが、ブラウザで実行させると遅すぎて使いにくいから、ローカルというかネイティブというかになっている。

129 ：

Fedora13で
native_client_sdk_0_4_907/build_tools/nacl_sdk_scons/make_nacl_env.py
を使ったらbuild環境展開できるのかと思って実行してみたらこんなメッセージが出てきた
Traceback (most recent call last):
File "make_nacl_env.py", line 15, in <module>
from SCons import Script
ImportError: No module named SCons
sconsコマンド自体は入ってんだけど何でだろうか？

130 ：

こんな感じかな。
□ JavaScript の場合
編集したい Youtube 動画のサムネイルを、サーバ側で切り出して、ブラウザ上に並べる。
そのサムネイルに対して、予め幾つか用意してあるエフェクトを指定したり、キャプションを
入力したり、編集したい内容を指定。編集内容をサブミットすると、サーバ側で合成。
→　実際の処理は全てサーバ上で行われるので、動画データ自体をやりとりする必要は無い。
→　ローカルの環境への負荷は低いのでタブレットとかスマホでもオケ。
□ NaCl or ブラウザプラグインの場合
編集したい Youtube 動画を NaCl 上のプログラム内のメモリにダウンロード。
ブラウザ上で編集、プレビュー等を済ませ、完成したらアップロード。途中で作業を
中断する場合は、編集中のデータをサーバにアップロード。
→　通信量多い、ローカルのCPU負荷高い、編集の自由度は高い。
□ ローカルアプリの場合
メモリもファイルシステムも使い放題なので、好きなだけ自由に編集して、気が済んだら
Youtube にアップロード。
→　素材も好きなだけ使えるし、処理時間の掛かるエフェクトも好きなだけ使えるので
　　編集の自由度は最も高い。
→　動画サイトに載せたくない個人的なムービーも当然作成出来る。

131 ：

ネイティブクライアントを邪気にしてないか？
サーバーに負荷がかからずシームレスな編集ができるってのは重要でしょ。
ただでさえエンコまちで数十分またされる動画サイトは多いわけだし。
ネカフェとかクライアントツールがない場所でも手直しができるも利点でしょ。
あと、クライアントのリソースを自由に使えるのは許可さえすればネイティブクライアントでも
できる訳だし殊更スタンドアロンアプリで強調する事じゃないよね。

132 ：

>>131
真面目に動画編集をするなら、ファイルシステムにアクセス出来ないのは結構致命的じゃないの。
・メモリに入り切る処理しか出来ない（テンポラリデータをファイルに待避したり出来ない）
・ローカルにある素材（サウンドファイルとか別の動画とか）にアクセス出来ない
Youtube に上がってる数十 MB の動画を加工するだけなら NaCl でも充分だとは思うけど、
それにしても、音声を差し替えたいと思ったら先にデータをアップロードしておかないと
いけないのは面倒でしょ。

133 ：

現状テンポラリが作れなくてもそのうち使えるようになるでしょ。
アルファ版状態の現状で用意されてないAPIをネイティブクライアントの
欠陥とみなすのは早計。もしかしたら、googleはブラウザをOS化する可能性も有るわけだし
#まぁ、既にネットブック用のブラウザOS作ったし時間の問題だと思うけど。

134 ：

無い物は無いよ
何で現状無いのかを考えれば、今後も自由にはならないと思うけどね

答え）サンドボックスが売りだから

135 ：

テンポラリデータがセキュリティホールになるかいな。
容量だってユーザーで制限できるだろうし。
ファイルアクセスだってアップロードダイアログと同じように作れば実績もあって十分だし。

136 ：

タヌキの皮が何枚になろうがどうでもいいから具体的な開発の話をしてくれ。
とりあえず >>129 の辺り他の人はどうしてる？

137 ：

>>135
夢を見るのは構わないけど、現状は JavaScript 経由で WebStorage を使うとか言ってるレベルでしょ?
あんまり時間が掛かると、ホントに Google Earth が JavaScript で実装される時代になるよw

138 ：

>>136
Python の問題っぽいから Python スレで聞くと良いと思われ

139 ：

>>137
Javascript経由しなくてもできなくはねぇなぁ。
プログラムをこうしてやればいい。限定的にstdioなんかが使えるようになる。
toolchain/bin/nacl-sel_ldr -a test.nexe

140 ：

それを『誰が』やるのか考えた方が良いよ

141 ：

このコマンド打つのはプログラマー。
実行許可すんのはブラウザのユーザーだけど？
Flashと同じじゃん。

142 ：

>>137
流行るか廃れるかなんてどうでもいい。使うのは俺だ。

143 ：

うん、広く使ってもらう為の話じゃないなら好きにしていいよ

144 ：

最初、googleはWebGLとJSで3Dレンダリングするのは速度でないから(WebGLは)いらないという立場だったけど、
今は、速度に問題ないとして推進する立場。
NaClも開発進めてるけど用途は減っていってる。
自分は、Webで動くAndroidアプリ実装や言語エンジンがほしい。

145 ：

米Googleは米国時間2011年7月20日、同社が開発中の技術を試験公開するサイト「Google Labs」の
活動を停止する意向を明らかにした。同社製品への取り組みを優先するためとしている。
　同社Research and Systems Infrastructure部門上級バイスプレジデントのBill Coughran氏は
「早期プロトタイプをGoogle Labsに投じることにより多くを学ぶことができたが、目の前にある
莫大な機会を最大限利用するには、これまで以上に集中することが極めて重要だ」と説明している。
　Google Labsの終了により、開発中の多くのプロジェクトは中止となり、一部の技術は既存製品に
統合される。また、Google Labsで手がけているAndroid向けアプリケーションは、同社のモバイル
アプリケーションストア「Android Market」で提供することになる。
　なお、各製品内で新機能を実験提供する「Gmail Labs」や「Maps Labs」といった試験チャネルに
ついては変更する予定はないという。
　Coughran氏は、「6月にSNS『Google+』のフィールドテストを早期開始したことが示すように、
当社はGoogle Labsを支えていたスピードとイノベーションを今後も推進していく」と付け加えた。
　Google+はSNS大手「Facebook」に対抗して立ち上げたプロジェクトで、6月28日より招待制で
試験運用を行っている（関連記事：Google、Facebook対抗のSNS「Google+」を発表、
「現実世界の人間関係を再現」）

146 ：

>>144
>NaClも開発進めてるけど用途は減っていってる。
Google が持っている開発ターゲット環境は、Go もあるし JavaScript(V8/Traceur) もあるし
Java(Dalvik/GWT) もあるから、どうしても話題が埋もれちゃうよね

147 ：

>>133,137
JavaScript経由でFileAPIのテンポラリストレージを使えば今でも1Gまでは保存できるよ。
ttp://code.google.com/p/nativeclient/issues/detail?id=566
を見るに、NaClから直にファイル使えるようにする気はあるらしい。

148 ：

NaCLで
CからopenGL使ってるさんぷるがまったくみあたらない
ヘッダはあるけどまだ使えないの？

149 ：

>米Googleは米国時間2011年7月20日、同社が開発中の技術を試験公開するサイト「Google Labs」の
>活動を停止する意向を明らかにした。同社製品への取り組みを優先するためとしている。
エエエエェェェェ〜。 NaClどうなんの〜？

150 ：

>>149
冷静に考えて、どうなると思う?

151 ：

Qt ほどひどくはならないんじゃない？

152 ：

何がどうしてひどくなると思うの?

153 ：

ひどくなるかは知らんけど、SDKの開発は止まりそうな気がする。
ヤル気があるようにみえんし、リリース製品で本格稼働してる機能でもないし。

154 ：

つ http://src.chromium.org/viewvc/native_client/

155 ：

>>152
ひどくならいんだから
ひどくなるとは思ってない

156 ：

つ　ほど

157 ：

GoogleLabsはWebサービス寄りの話だし、NaClの開発に関係するサービスも無かったかも。

158 ：

http://code.google.com/intl/ja-JP/chrome/nativeclient/docs/releasenotes.html
SDK 0.5 (28 July 2011)
SDK 0.4 (20 June 2011)
SDK 0.3 (17 May 2011)
SDK 0.2 (19 April 2011)
SDK 0.1 "Arctic Sea" (17 February 2011)
0.5以降は、Chrome14以降に対してバイナリ互換の予定だって。
バイナリAPIが決まったなら、firefoxへ移植も有り得るのかな？

159 ：

毎月0.1上げてるのをみると、年末には1.0の発表したいのかもしれない。

160 ：

>>149
Google Code Labsとは別みたい。
http://code.google.com/intl/ja-JP/labs/

161 ：

http://code.google.com/intl/en-us/labs/
おっと、日本語のトップページは更新されてなかった

162 ：

毎月上がる理由は、Chromeが1ヶ月ごとにバージョン上がるのにあわせただけだった。
今後は、どうなるんだろう。

163 ：

firefoxのバージョンアップあほすぎ

164 ：

>>13
Chromeのプロジェクトページに、NaClのプロジェクトページができてた。
https://sites.google.com/a/chromium.org/dev/nativeclient
今後の開発ポイントは、下位レイヤーの残り（OpenGLとLLVM）と、Webアプリケーション開発キットだと。
・試験的なOpenGL ES 2.0 サポート(Chrome 15目標)
https://sites.google.com/a/chromium.org/dev/nativeclient/how-tos/guide-to-experimental-3d-support
・PNaClのリリースロードマップ（リリース目標8/1〜）
https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/release-roadmap
・c_salt: a Web Application Development Kit
https://sites.google.com/a/chromium.org/dev/nativeclient/sdk/sdk-experimental/c_salt-design

165 ：

うっしゃぁまだ無事か。これで投げ出さずに済みそうだ。
関係ないがautotoolに手こずる。コンパイラをどうやって切り替えるんだ？

166 ：

>164
LLVMの話はARMとx86以外かと思ったら、
・もともとx86で高速なネイティブサンドボックス化ができるところがプロジェクトの開始点
・AndroidやChromeOSとARMさんの方でやれる方がモバイルバッテリーで高効率ということでポイント高い
・ARMネイティブつくってみたけど、なんかしっくりいかない
・LLVMならARM最適化できそう
ってことなのね。

167 ：

おもいっきり違った。
LLVMは、x86でガッツリ開発して
それからARMもって話なのね。

168 ：

ちょっと巡回してみたけど、まだかかるみたいだね。
https://groups.google.com/group/native-client-discuss/browse_thread/thread/68aeb10fd0ad763e?pli=1
Issue 135: NaCl runtime for ARM
http://code.google.com/p/nativeclient/issues/detail?id=135
> We are actively working on bringing NaCl to ARM, through the PNaCl effort.
> We currently target ARM "classic" and are working on a Thumb2 model we hope
> will be ready soon.
> We're also discussing internally how we could go forward on Android, but a
> number of issues currently remain to be resolved.
LLVM版のPNaCl使って、とりかかるけどChronium/Android(ARM)のNaClまでまだまだ障害があるよと。

169 ：

Ubuntu 11.04 Desktop (日本語/32bit) でChrome Unstable (14.0.835.18 dev)でNaCl有効にしても
>>1のexamplesが一つも動かないんだけれどそういうものなんだろうか?

170 ：

まだ、Chrome13用みたい

171 ：

Chrome14がstableリリースされる２ヶ月後には、
14以降対応でnexeを放置できるようになるのか。

172 ：

>>170
These Native Client applications cannot run in Google Chrome version 13.

173 ：

だれか14か15で動いてる？
winの15だと有効にしてても、プラグインがありませんとなって動かない

174 ：

winの14なら動くよ。pluginsとflagsの両方がONならば。ubuntuが動かない。

175 ：

ubuntuの14,15でも動いてる。about:flagsでenableした後、chromeの再起動が必要だった。

176 ：

解説記事: GoogleがNative ClientをChrome 14に実装, いよいよ次世代...
http://jp.techcrunch.com/archives/20110811chrome-native-client/

Androidで実装されたら本気出す

177 ：

android は jna があるしな…また別系統
chromeos 早くきてくれ！

178 ：

>>175
8/9の時点ではstable/bata/unstableのどれでも動かなかったが、今はubuntuでも動くみたいだね。

179 ：

>>176
実装っていうか10月のversion14からデフォルトで有効になるってことだね
ただWeb Storeに登録しなきゃいけないのが何気にうざい

180 ：

いずれは Android でも使える様になるんだろうけど、Safari や Firefox みたいな
主要ブラウザで採用される日は来るのかなあ

181 ：

永遠に来ないよ
Gの囲い込み

182 ：

これローカルでエミュレートできないのかな。
単に*.nexeを実行したらセグフォで落ちるし、
Wiki見てnacl64-ncvalで動かせるかと思ったら、
libcrypto.soが無いっていうし。

183 ：

無いならaptで入れればいいじゃないか

184 ：

今どき OpenSSL が入ってない環境ってあるんだな・・・

185 ：

VMでテストすりゃええが

186 ：

VM?
LLVMのlliの事かと思って lli a.nexe したら当然のごとくシグニチャが違うと言われた

187 ：

>>184
openssl入っててもlibcrypto.soは入ってない。
64bit環境だからかはしらんけど。

188 ：

CL6.0 64bitだと、/usr/lib64/libcrypto.so.1.0.0
Cent5.6 64bitだと、/lib64/libcrypto.so.0.9.8e
だった。

189 ：

それがどうかしましたか？

190 ：

>>189
187さん？

191 ：

NaClがサンプル(examples)ですら動かねぇでやんの。
Fedora13 64bit
Chrome 13
about:flagsによるnative client有効化済み

192 ：

うちは動いてる

193 ：

>>191
devtoolsのコンソールには何かでてる？

194 ：

>>193
こんな感じ。
NaCl module load failed: manifest: has unrecognized top-level property "program".
本家のコミュニティー調べたら Chrome 14にすればとか書いてあるけど、
14にしても同じだったってなリプライもあるんだよな。それにLinuxじゃ14って
まだじゃない？

195 ：

about:flags
about:plugins
両方有効にした？

196 ：

両方有効状態

197 ：

>>194
NaClのバージョン違い。
Chrome14のNaClとそれ以前のではmanifestが変わってて互換がないよ。
どのOSでも13が安定板、14がβ版、15が開発版。
β版を入れるか、来月半ばあたりまで待てば動くはず。

198 ：

なるほどありがと。
って事は、あれかNaClのmanifestが古い開発キットさがせば
ベータ版の14入れなくても動くってことか。

199 ：

ほ

200 ：

win/osxならchrone canary buildとchrome（チャンネル一つ）が同時に起動出来るから、
canary(15)とstable channel(13)入れておけばいいと思う。
#最近osx版が追加された

201 ：

OSXで動くとか言ってる人がいるけど
SDK0.5のrelease notesに書いてあるクラッシュの問題は解決したの?
Windowsでさえなんだか不安定だというのにMacで本当にちゃんと動くのか不安だ

202 ：

LLVMベースだから、どっちかってとWindowsの方が外野臭いけどね。
Unix Likeな感じ。

203 ：

LLVM版は開発中
nexeがpexeになるだったかな。

204 ：

まだまともに動かないのかよこれ。
今のWebは糞遅いjsが跋扈してかなわん。

205 ：

おまえは一生重い重い言ってろ

206 ：

いつから tcl が早い言語ってことになったんだｗ
tcl もふつうに処理の遅い言語ですよお父さん…

207 ：

画面更新が上手くいかん
IMageDataがローカル変数なのがマズイのか？
DidChangeViewのなかでしてるのがマズイのか？
WM_PAINTみたいなタイミングをどっかで待たなきゃいけないのか？
はたまた何か抜けてる？
namespace Nacl = pp;
virtual void DidChangeView( const Nacl::Rect &position, const Nacl::Rect &clip )
{
        Nacl::ImageData
                image( this, PP_IMAGEDATAFORMAT_RGBA_PREMUL, position.size(), true);
        Nacl::Graphics2D
                graphics( this, clip.size(), true );
        for( int i = 0 ; position.size().height() > i ; ++i )
        {
                static_cast<uint32_t*>( image.data() )[i] = 0x55555555;
        }
        graphics.PaintImageData( image, Nacl::Point() );
        graphics.Flush( Nacl::CompletionCallback() );
}

208 ：

自己解決
BindGraphicsを呼び出してなかっただけだったわ

209 ：

LLVMでも使えるのにSIMDライブラリが使えん。
GPUで何とかしろってことか。

210 ：

めんごめんご。やっぱSSE使えたわ。-msseオプション入れてなかっただけだったわ

211 ：

次期SDKのベータ来たな
ttp://code.google.com/intl/ja-JP/chrome/nativeclient/docs/beta-sdk.html

212 ：

Manifest変えるのは勘弁してくれ

213 ：

NaCl ABIが決まった後の開発の中心はPepper APIってやつなのか

214 ：

http://code.google.com/intl/ja-JP/chrome/nativeclient/docs/compiling.html
http://code.google.com/intl/ja-JP/chrome/nativeclient/faq.html
>You must load the correct .nexe file for your machine's specific instruction set architecture (such as x86-32 or x86-64).
>You can ensure you're loading the correct .nexe file by building a separate .nexe for each architecture, and using a .nmf
>manifest file to let the browser select the correct .nexe file. Note: the need to select a processor-specifc .nexe will go
>away with PNaCl (Portable Native Client).
なるほど…確かに面白そうだ

215 ：

http://src.chromium.org/viewvc/chrome/trunk/src/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_enable_feature.txt?revision=96510&view=markup
集約させたい気持ちも分からんでもないが
少々、いやだいぶ敷居は上がっていってる気もしないでもない
いいぞもっとやれと云うべきなのかｗ

216 ：

Native Client プラグインは使用できません
とか出るな sdkベータ $httpd.cmd 5103
dev channel の chrome 15 以降で動くと書いてあるような気はするのだが…（汗

217 ：

>>195
そうか plugin は初めからonになってるけど flags はデフォじゃonになってなかったからか�d

218 ：

googleはjavascript、dartにnaclと新しいものを生み出すはいいが、
結局のところ、戦略的には何を使わせたいんだ？

219 ：

golang と gae を忘れちゃ駄目だぞ
君の心に feeling haert!
って明日だね dart の発表…

220 ：

いまのところ、一般向けはflags:offになってて
chrome storeで、追加したウエブページ（試した）やプラグイン（試してない）で、有効になる流れみたい。

221 ：

gaeとgwtは糞

222 ：

clangの中の人が頑張って、native clientでobjective-cが動かないかな

223 ：

>>218
ブラウザとOSの統合じゃね。
最終的にブラウザがOSを食う形で。
Nacl つかってみると、ファイルアクセスも使えるし、
オーディオもグラフィックも、サーバーとの通信もできる。
イベントも自前で処理できるし極小なOSとしては充分じゃね。

224 ：

はやとちりした。ごめん。

225 ：

Wiki作ってみた。まだ全然書けてないけど興味のある人は協力よろ。
Google NaClであそぼう
http://www18.atwiki.jp/nacl

226 ：

どんまい

227 ：

プレス向けの広報はないけど、10月下旬からgonacl.comというサイトが出来たり
公開版発表してから思った以上に開発よりのコンテンツ作成に力入れてるね。
http://www.gonacl.com/
開発者へ http://www.gonacl.com/dev/index.html
コミッターへ https://sites.google.com/a/chromium.org/dev/nativeclient
SDKサイト http://code.google.com/intl/en-US/chrome/nativeclient/docs/technical_overview.html
デモ http://www.gonacl.com/dev/demos.html

228 ：

http://www.gonacl.com/dev/supported_software.html
ミドルウェアやツール類
gonaclのdevトップのニュースとミドルウェアなどみてると、思ったよりchrome storeに各種ゲームが登場しそう。
tclがあるのはCAD/CAMを移植して欲しいのかな。
そしてocamlがあるのは何故だろう。

229 ：

もともとはtclがブラウザに載るって計画があった気がするので、
tclの作者をリスペクトしてだと思ってたよ

230 ：

ocamlがあるのは関数型が金融での使用例が多いからかしら？

231 ：

地味に開発は進んでるんだな
http://japan.cnet.com/news/service/35011743/
　カリフォルニア州マウンテンビュー発--3年間の沈黙を経て米国時間12月9日夜、Google本社で、
ウェブのセキュリティを高め、ブラウザのパフォーマンスを著しく向上させる同社の新テクノロジが初めて公に披露された。

232 ：

既出かもしれんけど、このBastionってゲームNaCl対応らしいけどよく出来てるよね。↓
http://www.youtube.com/watch?v=VZAuKkv4eZE
Linuxでぬるぬる動く。

233 ：

いいですねー。久々にこういうゲームプレイしたくなった

234 ：

□エニがゲーム提供するんだっけ？

235 ：

Chrome以外で動かすためのプラグインとか
まだ無いんだろうな
普及したら使うのに

236 ：

ないけどオプソだからすぐ作れるだろ

237 ：

Gの思う壺

238 ：

SPDYはFireFoxのnightlyに入ったが
NaClのABIは春にFIXしたけど
ARMやPNaClはこれからだし、Papperもまだ先。
なにかしらの対応ソフトが出て安定してからのような気がする。
もしかすると、ここ一年でそうなるのかもしれないが。

239 ：

【ウェブアプリケーションという不幸 】
現在、多くのプログラマ（素人）がウェブアプリケーションというものがベストな正しい方向だと勘違いしている。
ソフトウェアの作るにおいてそのアプリケーションに応じた状態遷移を実装するというのは基本中の基本である。
その点においてウエブブラウザというある状態遷移が実装されているアプリケーションの上に
また別のアプリケーションを実装するのは論外である。
そこまでするなら普通にアプリケーションを実装してダウンロードして使ってもらえばいいのである。
ウェブアプリケーションとは虚構にしか他ならない。
ウェブアプリケーションを作ろうとしているあなた。
今すぐ普通のアプリケーションとし設計し始めてはいかがだろう。
そうすればきっと後悔しないですむ。
HTMLやHTTPを悪者にはしていない。
TCP/IPができあがり、その応用として、ファイルを送ったりするようになった。
ファイルの中身のテキストにデータ構造をもたせ、それはつまりツリー構造なわけだが
その実装としてのハイパーテキスト、つまりHTMLという送る側と送られる側で決め事（プロトコル）
をつくり、画像や音楽など表現の幅を広げることは当然の成り行きだっただろう。
そして、その送る側としてのHTMLファイルサーバ、つまりWebサーバ、送られる側としてのプロトコルの解釈・表示系としての
ブラウザというアプリケーション。
ここまではいい。
だが、そこから先が素人の発想というか、いそがばまわれを忘れた者の愚かな発想。
つまりブラウザ上で、アプリケーションを動かすという発想なのである。
ブラウザというのは、おくられてきたステートレスな通信内容の一瞬の表示手段でしかない。
つまりアプリケーションのためのひとつのパーツなのである。
Windowsでいえば、コントロールのひとつ。（実際WebBrowserというコントロールがある。）
JavaならWebClietnだ（これは、ブラウザではないが。）。
包含関係が逆なのである。
ブラウザ上にアプリケーションを作るのは愚かなブームである。

240 ：

プラットフォームから独立したアプリケーションを持つというのは
非常に効率の良い投資になり、上記の意見はあまり利口ではない
速度の問題はあるが、マルチコア化等のハードの進化とNacl等で
解決されるから柔軟性、移植性の方がはるかにこれからは優先される

241 ：

ブラウザOS時代のプラグインのあり方、くらいに思ってるけどね

242 ：

よく考えるとJavaのやり直しっぽいなNaCL

243 ：

逆にクロスプラットフォームでセキュアなC/C++が有り得るならJavaなんて要らんかったんや

244 ：

ActiveX, Java, Flash, Silverlight

245 ：

これで電脳めがねの世界に近づくな。
やっぱ世界を構築する言語はc++じゃないと

246 ：

保守

247 ：

Ubuntu12.04でaptからchromium 18.0インストールしたんだが、
about:pluginsにNaClがない。
NaCl製のアプリ起動してみても、NaClプラグインが見つからないだのLoading NaCL pluginで止まったりだのして使い物にならん。
about:flagsには「Web Storeのアプリ以外でもネイティブクライアント機能を使う」みたいのしかない。ちなみにこれ有効にしてももちろん動かない。
一体どういうことなんだってばよ。コンパイル時に省かれたってことかね？

248 ：

iOS版Chromeでもちゃんと動いた？
ベースがWebkitなので不安なんだけど

249 ：

そもそもARMに対応してないんじゃないか

250 ：

前スレ落ちてたはずなんだが
復活してるっぽい？
【Goggle】 Native Client 【】
http://toro.2ch.net/test/read.cgi/tech/1229000936/

251 ：

標準マンセー！俺ら勝ち組！JS勉強しとけば人生勝利！
って言ってるやつ、全員死亡フラグ立ててるよね(´・ω・｀)
jQueryでちょこちょこ動きつけて喜んでる程度のやつとか、
その逆にJSやCSSの糞ノウハウ貯めこんで最先端気取りのJavaScripterとか実にヤクイ
ピンチが危ない
どう考えてももっと効率のいい開発手法で一掃されるだろ。
他言語からのコンバート系とか（Angry BirdsのHTML5版はJava製だし、
最近Mozillaが過去のC++ゲーの移植やってるよな）Unityとか。
FlashもHTML5出力に取り掛かってるようだから
頑張ってSWF解析して再生してるソシャゲ屋さんあたりも涙目になるかも

252 ：

JSはゴミだが、誰も使ってないNaClよりはマシだろｗ

253 ：

> 他言語からのコンバート
余計筋が悪いものに乗り換えるとかありえないからw

254 ：

>>251
c++やjavaから比べればjsの方が開発効率ヨサゲ
プログラムを書いてる本人が分からなくなることは、
引数と返り値の型で、後で付け加えたり変更したりの修正であっちこっちに意識が飛ぶ
理想的なのは動的言語でプログラムを書いて、型チェックをしてくれるツールが付いてくること
誰か型チェックする魔法の検査ツールを作ってくれよ

255 ：

>>254
Pepper APIとnexe生成の際に結構面倒見てくれるんじゃなかった？ あとはサンドボックで。
Googl/Oでは、ポータブルバイナリPNaClは年内と言ってたし、更にその辺り改良されるはず。じゃなきゃ前に進めない。
ゲーム業界じゃ、GaikaiがIOでデモってたし、そのGaikaiはSCEに買収されたし、前から噛んでたSamsungはスマホ連携でGaikaiゲーム降らせるとアナウンスずみ。
携帯ゲーム機はスマホに潰されたし、PCもOSも問わないフレームワークは開発やメンテ、運営のコストを大きく下げられるのでメリット大。
ちょい先の動きになるかも知れないが、備えたほうがいいと思う。

256 ：

>>254
pythonはデコレータでチェック出来る

257 ：

html5とnode.jsは零細web屋たちへの一筋の光。
naclによるゲーム開発なんて、ソシャゲ屋と大手が潰しあうのを見て楽しむためにある
何よりも、5,6年ほど前のPHP,perl,python,rubyが一番にヤクかった。emacs,vimブームもヤクかった。

258 ：

ゲームが走るってのは、ベンチみたいなもんだろ
ゲームが走れば、だいたいのことはできそうなもんだからね
NaClの意義は、ブラウザOSのネイティブレイヤになることかと
RPCとかも実装されているのは大きい

259 ：

>>254
プロトタイプベースの言語推しといて型チェックの話をするのは矛盾を孕んでいるというか、ナンセンスというか
ObjectはObjectでしかないわけだし

260 ：

>>258
昔から、quakeが動くのがベンチだよ

261 ：

>>259
最初にインスタンスを生成したとこからオブジェクトの要素なんて変更しないでしょ
最初は文字列で、途中からdoubleになってたりなんて、すごく嫌。
インスタンスの生成箇所から、後のkey/valueをチェックしてくれる魔法のツールが欲しいのん

262 ：

>>251
どうでもいいが、Flashの後釜はSVGであってHTML5ではない
SVGアニメーションデモ
http://ie.microsoft.com/testdrive/Performance/FishIETank/Default.html
http://ie.microsoft.com/testdrive/Default.html

263 ：

>>261
全然噛み合ってないしよりナンセンスな話をしてるよあんた

264 ：

ocamlのRecordで事足りる
NaClにも移植されるだろ

265 ：

こういうスレって最初は物珍しくて伸びるけど、その内飽きて放置される運命
たまに誰かが上げてちょっと伸びるけど、そのくらいで終わる。

266 ：

>>265
あちこちに書き込んじゃってどうしたの
その言い回し気に入ったの？

267 ：

>>266
何か知らんが俺の書き込みを気に入って拡散しているアホが居るらしい

268 ：

クライアントのjavascriptだとソースモロ見えだからNaCl使うんだろ？
あとChrome OS用

269 ：

ソースモロ見えだから嫌って言う人だいぶ減ったな。
初心者がたまに2chで言ってるぐらい？

270 ：

ソースモロ見えが嫌だからNaCl使う

271 ：

難読化されたJavaScriptってネイティブコードよりよっぽど難解だと思うけどなぁ
例えばこういうコードが何百行も続いてるやつを読む気になる？
aaa=(((0x4435,7.)>=(.61,9.12e2)?(1,4.033e3):(266,7.1e1)),((0x97<=.1?7.616e3:2.176e3),(.39<8e0?document:2032)))

272 ：

>>271
それは解析する人次第だしなー
ただ、jsのほうが改ざん自己検出能力は劣ると思う
NaCLってコード署名周りどうなってるんだっけ？

273 ：

>>271
いや普通にツールで整形できますんで

274 ：

>>273
どのツールなら出来るか書いてよ

275 ：

273じゃないけどそれくらいググれよ。
デバッガも使えばクリティカルな場所を探すのは容易くなる。
コードが見えて、アルゴリズムが盗まれるなんて野暮ったい話じゃないぞ。

276 ：

整形するだけのツールなら山ほどあるけど、整形するだけじゃ意味ないよねって話だぞ。

277 ：

>>276
仰ってる意味が

278 ：

>>276相手なら綺麗に整った生コードでも十分そうだな

279 ：

>>277-278
話にならんな。
>どのツールなら出来るか書いてよ

280 ：

こんなスレにいてググることもできないのか
それとも、あることを認めた上と取れる>>276をなかったことにしたくて話を戻したのか

281 ：

煽りたいだけの青いお年頃

282 ：

ゲームだの何だので海外じゃ盛り上がってるのになぜ国内では盛り上がらないのか

283 ：

国内はドカタとPHPerしかいない

284 ：

日本はスマホ関連が活発なので、UnityのWebPlayerに流れてるイメージがある。

285 ：

ブラウザでゲームという話も、JSやらFLASHの変換やらはスマホ中心で回ってる気がする。

286 ：

ほ

287 ：

CPUさえ同じならOS関係なくネイティブコードが動くのがいい所
でもAndroidではまだ動かない

288 ：

元々超高速なサンドボックス環境がx86で作れるというところから出発したけど、
x86では、flashなど既存のプログラムがサンドボックス環境で動くのに役立ったというところで区切りがついたような気がする。
ARMのnacl実装も作ったみたいだけど、
今後の開発の中心は、それぞれのCPUで超高速なサンドボックスよりも、LLVM使ったポータブル(PNaCl)なサンドボックスに向かうみたいだね。

289 ：

いうてもLLVMがXplatformじゃなくて滞ってんでしょ
別にCPU毎に実行file用意する現状で良いと思うがねぇ
何ならosx見たいに各platformの実行codeを
1つの実行fileにまとめても良い。

290 ：

AndroidはMacみたいなファットバイナリで配布できるね
で、その機種のCPU向けのコードだけがインストールされる

291 ：

過疎

292 ：

◆電波王の顔写真が公開されるプログラム◆
１．メモ帳に↓をコピペする
　　for(;;){ WScript.Echo('このウィンドウは永久に消えません。m9（＾Д＾）プギャー'); }
２．ファイル名を↓で保存する
　　電波王顔.avi .js
これだけでOK！

293 ：

桐島、Rubyやめるってよ
http://htn.to/9GrwNV

294 ：

asm.jsでオワコン化？

295 ：

方向性が全く別だし

296 ：

C++のコードはどちらにもコンパイル(変換)できるようになるんじゃないかな？

297 ：

NaClはもともとx86で高効率にサンドボックス化が可能というところから始まったのだが、
x64,armと対応進めるうちにサンドボックスのためllvmのvm使ったpnaclが最終目標となってしまった。
そのようにVM使ってポータブルにした場合、メモリアクセスに特化したasm.jsよりメモリアクセスが遅くなる可能性もある。

298 ：

せっかくNativeを謳ったNaClなのにVMなんかにして
JavaAppletやActiveXと何が違うんかって話だよな

299 ：

axというよりは、月光？

300 ：

>>298
llvmとvmを一緒にすんなよあほ

301 ：

pexeは、バイトコード動かすのではなく、一回バイナリコードにコンパイル(llc?)して実行するらしい。

302 ：

実行直前のAOTってのもなんだかなーと、おもうけど、lli(VM)で動かすんじゃないみたい。

303 ：

http://blog.kmckk.com/lite/archives/2435798.html
llvmのバイトコードは、ほぼ機械語と一緒なのか。

304 ：

asm.jsはあかん
ただでさえC++はコンパイルに時間がかかるのに
そこからasm.jsコードへの変換の遅さがただごとではない
PNaClもSIMD使えないなどというし、
大体どちらもAOTコンパイルに時間かかるのが原理上不可避
結局ブラウザではネイティブコードは二級市民ってこったな。
JSそのものを捨てないことには話にならんというGoogleの判断
案外正しいんじゃねーのか。

305 ：

>>304
LLVMとWebGLを勉強しなおしてこい

306 ：

>>305
勉強しなおしてこいｗｗｗｗｗｗｗｗｗｗ
俺が何を言っているかまったく理解していないんじゃないの？

307 ：

C++→（Clang）→LLVM→（Emscripten）→asm.jsコード
　　　　　　　　　　　　　　　　　　↑
　　　　　　　　　　　　ここ。これが死ぬほど遅い。
C++１行書き換えても全部再コンバートだからな。
比較的小さいライブラリ等ならともかく、大規模プロジェクトに使えるかこんなもん。
ウェブの連中はまるでreadyに届いていないものをreadyだreadyだ宣伝するのやめろよマジで。
ほとんど詐欺師

308 ：

完全詐欺師

309 ：

asm.js を擁護するわけではないけど、 relooper 切れば死ぬほど遅くはないような。
ところで、 PNaCl って開発に異様に時間がかかっている気がするのだけど、
一体何に苦戦している（た）んだろう?

310 ：

http://chrome.blogspot.jp/2013/09/a-new-breed-of-chrome-apps.html
http://itpro.nikkeibp.co.jp/article/NEWS/20130906/502868/

311 ：

http://news.mynavi.jp/news/2013/09/06/057/
http://internet.watch.impress.co.jp/docs/news/20130906_614308.html

312 ：2013/09/20

>>307
開発サイクルでの修正箇所は、c++によるコンパイルまでじゃないの?
本当に大規模な開発を行うのなら開発環境ぐらい整えそうなもんだけど