Google NaCl プログラミング 2mol
■ このスレッドは過去ログ倉庫に格納されています
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/
>>59 C++ を書きたい人が書く分には良いんじゃないの 既存のコードをそのまま動かしたいとかね それでもフルパワーの C++ が使える訳ではないし、テストや メンテナンスの手間を考えると、かなり敷居が高いと思うよ Googleのやることって、特徴は無料ってだけで、今更ってのが多い。 やっとGoogle Chrome 10.0がUbuntu/Debianに回って来た。 ちょっと遊んでみるかな? 雨には放射能が含まれていると危険だから 必ず傘をさすようにってお天気で毎回言った方が良い >>67 放射性物質だろ。水は陽子と電子だけだから放射能を持つことはない。 水素や酸素にも同位体はありますよ 同位体がなぜ放射能を持つかどうかは良くわかってない HもOも放射性同位体の半減期短いのばっかりじゃんw 雨が危険、っていうのは、小学生でも知ってるように雨粒は空気中の埃を核にして 形成されるからだと思うけど。 今回の件で放射性物質の埃がある程度上空に排出されたのは間違いなからね。 真水で冷却出来ずに塩水使ったのが間違いだったね 高温でイオン化したナトリウムが水と反応して爆発したんだよ 高吸水性ポリマーで汚水流出止めようとしてるみたいだけど塩分があると効果ないんだって 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 Tcl、GoogleのNative Clientに対応した「NaTcl」を発表 http://slashdot.jp/developers/11/04/15/181223.shtml 凄いんだか凄くないんだかさっぱりわからんw Googleは今でもNaClをプッシュしてるの? こんなスレあったのね WebKit党Safari派だがぐぐるも好き、LLVM注目中なので記念カキコ ときどき見に来る /.Jで出たの知って、悶々としてたので書かせてくれ >>78 NaTclって物質ないじゃんね もうちょいましな名前はなかったのかと といっても、ささっと対案は出てこずw サーバー側コーディング不要の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 GAEは携帯認証がな…。 GAEにも、NaCl入るようにならないかな うん。直接関係ない。 だが、ブレスト的にというか、無理やりくっつけて考えてみた NaClってのは、きちんとサブセット化されたELFバイナリ、 サンドボックス、RPCで成り立ってる これを、GAEが受け入れれば、言語制限ってものが取り払われるんじゃないか Perlやりたい?NaClでPerlビルドすればいい RubyだろうとLUAだろうとおなじこと 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の新しい本が出るようになるかな? chrome://plugins に、NaClが出てくるけど、ここからも有効化できるのかな? >>85 多分できる。 試しに有効にしてみたら動いた。 sdkのバージョンが0.3になってた Chrome12のためだけみたいだけど 基盤技術過ぎて、華はないなw なんとなく見てるんだが、Chrome OS のRPCにも使えるようになるんだよね、きっと 今GPU使える?せめてシェーダー言語だけでも走らせる事ができりゃいいんだけど。 あとは自作するから。 ActiveXは、よく脆弱性持ち込んでたような、、、 NaClはよくは知らんがActiveXは完全信頼モデルなのがいかんかったのだろ? NaClはプロセス分離とかで部分信頼モデルもどきぐらいにはするつもりじゃないの? MSがWebGLはセキュリティが駄目だと言ったから NaCl使ってOpenGL使うのが流行るんじゃね? WebGL は、セキュリティの問題は ARB で対応する予定でしょ 「Chrome」の徹底的な改修を開始したグーグル--セキュリティ向上を目指す http://japan.cnet.com/news/commentary/35004398/ > Googleが「Native Client」と呼ばれる安全性の高い基盤の上で、 > 「Chrome」を徹底的に作り直す作業を開始したとの情報を、米CNETが入手した。 Native Clientって全然話題にならないけど プロジェクトとして生きてるの? ChromeOSもChromeもJSからプラグインぐらいまでは移す計画してるんじゃない? いまんとこ、セキュアなネイティブサンドボックスなんて、脱研究室レベルではGoogleしかできてないけど、第一線のプロジェクトなことは間違いないとおもうよ。 ここ数年でものになるなら、ARM版がすでにあるのでスマートフォンやタブレットでの電力改善が一番大きい。 x86とARM以外ではLLVMでユニバーサルって話だから汎用性もあることにはなっている。 ウェブアプリは JavaScript で割と満足なんだけど、ネイティブコードのニーズってあるのかな? >>111 Java屋とか.NET屋とかからは、JavaScriptは使えば使うだけ生産性落とすって言われてるけどもね。 動的な型付けとか、ソースコード配布な辺りとか、テストしにくい辺りが。 かといって、ネイティブコードがいいかというと良くないけども。 >>111 Flash Playerそのものを動かすとか。 マルチメディア系のプログラムを動かすとか。 メンドいデプロイを楽ちんにするとか。 JavaScript 自体が、でかくて重いプログラムを走らせるような設計になっていない。 ブラウザ上ででかくて重いプログラムを走らせ様と考えるのは勘弁してくれ JavaScript だと重いタスクはサーバ側に丸投げするだろ あー、でも最近はそうでもないか JavaScript の処理速度はかなり上がったから、割と何でも気軽に JavaScript で実装出来てるわ JavaScript で実装した他の言語のランタイムや、OS の仮想マシンも幾つかあるよね >>117 http://jsbin.com/ubiyay/3/edit#preview WebGLのスレにあったヤツだが、ここまで遅いと話しにならんだろ。 >>116 そんな処理サーバーに投げたらサーバー死ぬだろ。 クライアントは1台じゃないんだから。 >>118 >そんな処理サーバーに投げたらサーバー死ぬだろ。 どんなサーバのどんな処理かの前提も無しに面白いことを言うね >>119 >ブラウザ上ででかくて重いプログラム がするような処理じゃないのか? >>124 『君は』どんなプログラムを前提にして話してたの? >>123 マジメな話、Google MapをGoogle Earthに置き換えるとかだろ。 あと、youtubeの動画編集をyoutube内でするとか。 てか>>114-116 の流れ見れば具体的な話が解ると思うけど。 >>126 考えてみたけど、動画の編集は NaCl で作っても簡単には行かないと思うわ ちょっとエフェクト足す程度なら JavaScript でも出来そうだし、ガシガシ 編集するなら制限の無いローカルアプリの方が圧倒的に良いし、微妙な感じ スマホアプリのほとんどが、ブラウザで実行させると遅すぎて使いにくいから、ローカルというかネイティブというかになっている。 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コマンド自体は入ってんだけど何でだろうか? こんな感じかな。 □ JavaScript の場合 編集したい Youtube 動画のサムネイルを、サーバ側で切り出して、ブラウザ上に並べる。 そのサムネイルに対して、予め幾つか用意してあるエフェクトを指定したり、キャプションを 入力したり、編集したい内容を指定。編集内容をサブミットすると、サーバ側で合成。 → 実際の処理は全てサーバ上で行われるので、動画データ自体をやりとりする必要は無い。 → ローカルの環境への負荷は低いのでタブレットとかスマホでもオケ。 □ NaCl or ブラウザプラグインの場合 編集したい Youtube 動画を NaCl 上のプログラム内のメモリにダウンロード。 ブラウザ上で編集、プレビュー等を済ませ、完成したらアップロード。途中で作業を 中断する場合は、編集中のデータをサーバにアップロード。 → 通信量多い、ローカルのCPU負荷高い、編集の自由度は高い。 □ ローカルアプリの場合 メモリもファイルシステムも使い放題なので、好きなだけ自由に編集して、気が済んだら Youtube にアップロード。 → 素材も好きなだけ使えるし、処理時間の掛かるエフェクトも好きなだけ使えるので 編集の自由度は最も高い。 → 動画サイトに載せたくない個人的なムービーも当然作成出来る。 ネイティブクライアントを邪気にしてないか? サーバーに負荷がかからずシームレスな編集ができるってのは重要でしょ。 ただでさえエンコまちで数十分またされる動画サイトは多いわけだし。 ネカフェとかクライアントツールがない場所でも手直しができるも利点でしょ。 あと、クライアントのリソースを自由に使えるのは許可さえすればネイティブクライアントでも できる訳だし殊更スタンドアロンアプリで強調する事じゃないよね。 >>131 真面目に動画編集をするなら、ファイルシステムにアクセス出来ないのは結構致命的じゃないの。 ・メモリに入り切る処理しか出来ない(テンポラリデータをファイルに待避したり出来ない) ・ローカルにある素材(サウンドファイルとか別の動画とか)にアクセス出来ない Youtube に上がってる数十 MB の動画を加工するだけなら NaCl でも充分だとは思うけど、 それにしても、音声を差し替えたいと思ったら先にデータをアップロードしておかないと いけないのは面倒でしょ。 現状テンポラリが作れなくてもそのうち使えるようになるでしょ。 アルファ版状態の現状で用意されてないAPIをネイティブクライアントの 欠陥とみなすのは早計。もしかしたら、googleはブラウザをOS化する可能性も有るわけだし #まぁ、既にネットブック用のブラウザOS作ったし時間の問題だと思うけど。 無い物は無いよ 何で現状無いのかを考えれば、今後も自由にはならないと思うけどね 答え)サンドボックスが売りだから テンポラリデータがセキュリティホールになるかいな。 容量だってユーザーで制限できるだろうし。 ファイルアクセスだってアップロードダイアログと同じように作れば実績もあって十分だし。 タヌキの皮が何枚になろうがどうでもいいから具体的な開発の話をしてくれ。 とりあえず >>129 の辺り他の人はどうしてる? >>135 夢を見るのは構わないけど、現状は JavaScript 経由で WebStorage を使うとか言ってるレベルでしょ? あんまり時間が掛かると、ホントに Google Earth が JavaScript で実装される時代になるよw >>136 Python の問題っぽいから Python スレで聞くと良いと思われ >>137 Javascript経由しなくてもできなくはねぇなぁ。 プログラムをこうしてやればいい。限定的にstdioなんかが使えるようになる。 toolchain/bin/nacl-sel_ldr -a test.nexe このコマンド打つのはプログラマー。 実行許可すんのはブラウザのユーザーだけど? Flashと同じじゃん。 >>137 流行るか廃れるかなんてどうでもいい。使うのは俺だ。 うん、広く使ってもらう為の話じゃないなら好きにしていいよ 最初、googleはWebGLとJSで3Dレンダリングするのは速度でないから(WebGLは)いらないという立場だったけど、 今は、速度に問題ないとして推進する立場。 NaClも開発進めてるけど用途は減っていってる。 自分は、Webで動くAndroidアプリ実装や言語エンジンがほしい。 米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+」を発表、 「現実世界の人間関係を再現」) >>144 >NaClも開発進めてるけど用途は減っていってる。 Google が持っている開発ターゲット環境は、Go もあるし JavaScript(V8/Traceur) もあるし Java(Dalvik/GWT) もあるから、どうしても話題が埋もれちゃうよね >>133 ,137 JavaScript経由でFileAPIのテンポラリストレージを使えば今でも1Gまでは保存できるよ。 ttp://code.google.com/p/nativeclient/issues/detail?id=566 を見るに、NaClから直にファイル使えるようにする気はあるらしい。 NaCLで CからopenGL使ってるさんぷるがまったくみあたらない ヘッダはあるけどまだ使えないの? >米Googleは米国時間2011年7月20日、同社が開発中の技術を試験公開するサイト「Google Labs」の >活動を停止する意向を明らかにした。同社製品への取り組みを優先するためとしている。 エエエエェェェェ〜。 NaClどうなんの〜? ひどくなるかは知らんけど、SDKの開発は止まりそうな気がする。 ヤル気があるようにみえんし、リリース製品で本格稼働してる機能でもないし。 >>152 ひどくならいんだから ひどくなるとは思ってない GoogleLabsはWebサービス寄りの話だし、NaClの開発に関係するサービスも無かったかも。 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へ移植も有り得るのかな? 毎月0.1上げてるのをみると、年末には1.0の発表したいのかもしれない。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる