2011年12月22日木曜日

Android Galaxy S2にプログラムがインストールできない?

しばらくAndroidのこと書いてませんでしたが、先月くらいにGalaxy S2のシステム更新(2.3.4→2.3.5)した頃くらいから、eclipseでプログラム作ってみても、Galaxy S2にインストールできなくなってました。(Windows & Macとも)
理由がわからないうちに、Googleの方でSDKの更新が進み、ディレクトリ構成が大幅に変わってわけわからない状態に・・・ あらためて調べなおしてみたら、Windows側はどうもUSBでGalaxyが認識ができなくなってる。(Macは認識できてるようだけど、いまいち動きがあやしい)さらに調べて、Samsungの「韓国語」のHPに新しいUSBドライバがDLできるようになってるとの情報が・・・ 行ってみたんですが、わからん。さらに見ると、どうもjp.samsungmobileというHPがあるらしいんですが、普通にいくと、そこは移動したとでてきますが、googleで、”jp.samsung”+galaxyで調べてHitしたところにいったら見れるページがあり、そこから新しいUSBドライバ(1.4.4.0)が落とせました。(24MBでしたが、これ実行したところwindows updateが動いた・・・ 何やってるんだ?)それでも、これで無事eclipseからプログラムをGalaxyにインストールできるようになりました。
それでもMacの方はまだダメなんだよな~~~

2011年12月3日土曜日

(日本語)テキストエディタの問題

普段簡単なメモを書いたりするのには、テキストエディタ(サクラエディタ)を使っています。行末コードや、日本語コードの自動変換(たまに失敗しますが、そのときは強制的に変換)など便利につかってました。ところが昨日、これに非常に苦しめられました。

WebGLを見てたんですが(Learning WebGL)、そこのサンプルのページをローカルに保存します。

こんな感じで表示されます。(最初、ちょっといやな気がしたんですよ。途中に半角空白+ハイフン+半角空白なんて)これをChromeで表示しようとしてもうまくいきません。なんで?とおもってサクラエディタで中身を確認しようにも何もでてきません???次は、メモ帳で見てみますと、JavaScriptが入っている同名のフォルダ名のとことが文字化けしています。
なんか中点になってる!?色々悩んですが、このHTMLのcharsetが、ISO-8859-1(通称、ラテン-1)なんですが、調べたらASCIIではなく欧米のドイツ語等、ウムラウトなどの特殊記号が含まれているコードです。それをメモ帳やサクラエディタは日本の文字コードに強制的に変換してしまうので、表示がおかしくなってしまったようです。上記ファイル名はWindows7(64bit)のせいかハイフンが心持ち長く見えますが、WidnowsXPだと、本当にハイフンと区別がつきません。サクラエディタだと、おそらくファイル名の解釈のところで、ここがオプション指定と勘違いしてしまったんでしょう。ファイル名を変更してやれば中身はみえましたが、ハイフンのところは空白になってました。
Windows7(64bit)だと、システムとして一応この文字コードが認識できるらしく、サクラエディタで開くこともできるし、ローカルで見ることもできますがエディタで編集ができません。
散々、困ったあげくVisualStudioで開くとうまく開いてくれて(ただ保存時に強制的にUnicodeと勘違いされてしまいます)、なんとか修正できました。(結局、Linuxで修正しました)
何か適当な欧米のテキストエディタさがすかしないといけないけど、Aptanaならうまくいくんだろうか?

2011年11月26日土曜日

Widnows7の起動が時間がかかる(-_-メ)

昨年かったばかりのWidnows7(64bit)も当初は起動が速くて快適だったんですが、一年にしてなんかやたら起動に時間がかかるようになりました。HDDのデフラグとか、起動時のスタートアップで動くプログラム(スタートアップフォルダ内にショートカットが作られます)とかありますが一向に改善しません。

どうも最近のプログラムは昔のようにスタートアップのフォルダないにショートカットを作るんではなく、直接Widnowsの制御ファイルに修正加えちゃうようです。直接実行(スタートメニュー内に入力欄があります。WidnowsXPだと「ファイル名を指定して実行」になります。)で”msconfig”を実行します。すると以下のようなWindowがでてきて、起動時の設定を変更できます。


すると、あるわあるわ・・・ 何でこうも自分のプログラムをスタートアップに入れたがるアプリばっかなんだ。(これまでインストールしたプログラムが大抵なにかしらのプログラムを起動時にデーモンを動かすよう仕込んでました)アプリ系のは片っ端からオフにしてやったら、やっと以前のような速度で起動するようになりました。(大抵はまずければなんか言ってくるか、アプリ起動時に必要なものを起動してくれますが、たまにアプリ起動が失敗するものもでてくるかもしれないので、そのあたりは自己責任ということになります)

2011年11月23日水曜日

AndroidでOpenGL(ESですけど)

AndroidでOpenGLによるプログラムの書き方を調べています。正確には組み込み用のOpenGL ESですが、OpenGLとそんなに違いはありません。というか、そこまで詳しくOpenGLを理解しているわけではないですが、一通りOpenGL、およびOpen InventorをSGI上でc++によりプログラムしてみたことあるので、関数は知っています。ただAndroidだとどのclassのどのメソッド上にOpenGLの各関数を実装したらいいのかがわかりません。(Androidのアプリはステートマシンのようなもので、状態遷移のたびにCallされる関数が決まっているようですから、その順番にあわせて必要なOpenGL関数を実装していかないといけません。

ところで、基本としてAndroidのアプリ上で画像を描くには、まずアクティビティ(Activity:画面)を生成して、そこに描画領域を指定します。この指定方法に2つの方法があり、CanvasとSurfaceViewです。Canvasはアプリケーションスレッド上で動作するのに対し、そこと並行した別スレッド上で動かすSurfaceViewというような感じです。そして、OpenGL ESはSurfaceView上で動きます。

処理速度的にあSurfaceViewは別スレッドで動くので高速に動くように見えますが、アプリが動いているときは当該スレッドが当然動いているので、別スレッドとして動くSurfaceViewではどうしてもCanvasには勝てません。

追記:
ChromeのNative clientという技術があります。chroniumのベータ版という実用化までは先が長い技術なんですが、急展開して日本のスクエニがこれでゲームを作りchrome storeで販売を始める予定だと。技術の内容的にchrome上でc,c++のコードを動かすSDKだとか、、、セキュリティどうやって確保するんだ?何か色々注意点が書かれてましたが(早いコードを書くのに注意する点とか)そこのWebGLを使う上での注意点がかなりコード細かく記載されていました。読んで見ると、なるほどと思える事が多くてためになります。AndroidでOpenGL ES使う時も注意した方がいいような話です。


後で削除するか、大幅修正するけどとりあえずメモ

2011年11月21日月曜日

Androidの開発環境:MacBookAirではダメだった・・・??

作ったアプリがどうしてもエミュレータで実行できない(eclipseからエミュレータにインストールされない)ことを書きました。しかしいくらなんでもこのキャッシュの強さは異常に思い始めました。javaだから動作が「もっそり」するのは仕方ないにしても、ファイルの更新が全然システム(この場合はeclipseやエミュレータ)に伝わらないのはおかしすぎます。マシンを何度も再起動しました。

ふと考えたんですが、自分が持っているMacBookAirは初期型です。(マイナーはしてますが)HDDは持っておらず、初期のSSDを積んでいます。初期のSSDは書き換え回数が厳しく、いろんな技を使っていますが、その中でも強力なバッファを設定してキャッシュを構成していたはずです。もしかして、Mac OSの方で特殊なことをしていて、それとeclipseの相性が悪いんでないか?(要は、ファイル更新の情報がなかなか伝わらない)単にバッファを大きく積んでいるだけなら、MacBookAirの終了の速さ(2,3秒で電源が落ちます)はおかしいんですが、どうも何かやってるんじゃないかという気がしてきました。(新しいMacBookAirなど最近のSSDは性能が改善されていると聞いているので、また話が変わっているかもしれません)
試しに、Windows7をつんでいるノートPC(普通のHDDです)にAndroid開発環境をもう一揃いそろえてみました。そこにMacBookAirで入力したプログラムをUSBで持ってきて、動かしてみると・・・ファイルの更新が少し遅れますが、ちゃんと伝わります!やはり、初期型のSSDのためにファイルシステムが何か特別なチューンがしてあるようです。う~ん、MacBookAirではAndroidの開発はあきらめるしかないですね。

追記:
その後、Windows7のマシンでも、ちょっとファイルを修正した後、どうしても再ビルドをしてくれない事態にあいました。メニューのからクリーンを選択して、プロジェクトのbin以下が削除されても再ビルドしてくれません。わけがわからず実行してみたら、さすがに再ビルドしてくれました。(エミュレータが動いて、アプリの更新に30秒くらいかかりましたが、特に再起動しなくても更新してくれただけMacBookAirよりましです)時々、eclipseのファイルキャッシュと同期がとれていませんというワーニングをMacBookAirのときは見ましたし、どうにも動きの予想がつきません。慣れれば、これはこれでいいんだろうか?有名なツールだし・・・

結論:
このクリーン、MacBookAirで試してなかったんでやってみたら、どうやら確実に修正できそうな手順が見つかりました。

①ソースを修正する。
②一度、当該プロジェクトをクリーンする。(選択したプロジェクトのみで行い、クリーン後すぐ再ビルドのオプションを選択してもビルドはなぜかされず。)
③実行、或いはデバッグを行う。(これで再ビルドが確実に行われます)
④Androidのエミュレータを起動する。(Windows7では自動的に実行してくれましたが、Macでは手動で行う必要がありました。たまたまかもしれませんが。)
⑤Windowsの方は30秒くらい待ってると、更新したパッケージがエミュレータにアップロードされ動きます。但しMacの方はだめで、一度アンインストールしてからエミュレータを起動、eclipseから起動しても中々アップロードしてくれないので、手動でインストールする。

Macでは特にエミュレータでアプリが動いている状態で終了すると、その状態をずっと覚えているようで、アプリの更新が働きません。(何もワーニングらしきものが出てこないのでわからない)そのため、特にMac側ではエミュレータでアプリを停止するなり、削除することが必要なようです。Macの方がやはりキャッシュが強い気持ちがしますが、それでも処理速度は速いです。古いCore2の方が、コア単体のクロックが速いせいか、あるいは単にOSの軽さからくるのかわかりませんが。それでもMacで開発できるならこちらの方が快適なんでいいです。

2011年11月20日日曜日

Androidのアプリをエミュレータで実行できない

このところAndroidアプリの勉強をしています。プログラムはeclipseでつくり、エミュレータで動作を確認、その後実機テストを行うときはGalaxy S2へインストールしています。
ところで以前にも書きましたが、eclipse自体やエミュレータもjavaで作られているせいかやたらと強力なキャッシュが効いていて、なかなかソースの変更がバイナリに反映されなかったり、エミュレータで実行できない(DLされない?)ことがあります。最後はマシン自体の再起動なんですが、今回それでもだめな自体が起きました。どうしてもエミュレータで実行できません。(eclipseの実行構成からちょくにアプリを選択して、エミュレータを起動してもダメです)やむを得ないので、ネットでアプリのインストール方法を探してみました。そうしたら"adb"コマンドというのがあることがわかりました。

・インストール方法
エミュレータを動かしておいて、以下のコマンドを端末から実行します。

> adb install apkファイルのパス

なお、再インストールするさいアプリが作成したデータを残しておいてアプリだけ再インストールする場合は"-r"オプションをつけます。

> adb install -r apkファイルのパス

・アンインストール方法
ついでなので削除する方法も記しておきます。(エミュレータで直接削除してもいいんですが)

> adb uninstall パッケージ名

先ほどはapk自体を引数に与えましたが、今度はパッケージ名です。なお、アプリが作成したデータは残したい場合は"-k"オプションをつけます。

> adb uninstall -k パッケージ名

なお、以前開発環境を設定したときは環境変数でPATHに/Applications/android-sdk-macosx/toolsを設定しておきましたが、端末から動かせません。調べてみると、なんとadbコマンドは/Applications/android-sdk-macosx/platform-toolsの方に移動したとテキストファイルが残されていました。今回はちょくにフルパスいれて実行しましたが、環境変数に追加しておかないと。

2011年11月13日日曜日

Androidのサンプルがビルドできない

Androidのプログラミングの勉強で、とにかく今は多数のサンプルを動かしてみて動きを診ているところです。センサーの動きを見てみたくて、ちょっと長いサンプルをDLしてきてビルドしてみたところいくつかのメソッドが「スーパークラスのメソッドをオーバーライドする必要があります」と言ってきます!?いやいや何もそこは自分でさわってないぞ、しかも解決法おとしてリコメンドされるのが「@Override注釈を除去します」??? それっていいのか?
一晩悩みましたが、やっと理由がわかりました。JDK1.5と1.6でOverrideの仕様がかわり、1.5ではインターフェースのメソッドはOverrideアノテーションできなかったのが、1.6からはインターフェースのメソッドでもOverrideアノテーションが使えるようになったとのことです。まあアノテーションなんで、リコメンドどおり注釈を削除してしまってもいいんですが、これでは本末転倒です。
自分が作業に使っているPCにはJDK1.6が入っていますが、なぜ1.5として認識されてしまっているかというと、eclipseのプロジェクトの設定のところで指定できるところがあり、デフォルトが1.5になってしまっているんです。プロジェクトのところで右クリックして「プロパティ」を選択、JAVAコンパイラーのところでバージョンを選べます。
これを1.6にすれば無事ビルドもできて実行できました。

2011年11月12日土曜日

Androidのログ出力

Androidにもログ出力機能(クラス)があります。以下の様な感じです。


Log.i("HELOO", "called MyView constructor");

この場合、"i"なんでINFOになります。種類には以下があります。

ERROR  エラー
WARN  警告
INFO   情報
DEBUG  デバッグ
VERBOSE

見方はdmmsを直接起動するのと、eclipseから表示ウインドウを開くのと2通りありますが、eclipseの場合だと「ウインドウ」→「ビューの表示」→「その他」→「Android」「LogCat」(なぜかLogCatが2つあり、しかも一つは使用するなと書かれます??)で以下の様なウインドウがでます。(もちろんAndroidとはUSBで接続しておきます)
なんか、いっぱい表示されます。これでもINFOだけにフィルタかけてるんですが(画面の中央くらいに"HELOO"がでてます)、いろんなアプリがLogを出力しているようです。

2011年11月4日金曜日

Androidの開発:R.javaが生成されない!?

まだまだサンプルみながら、動作を確認している段階ですが、ある時から気づいたのがなんかlayout以下に自動生成されていたR.javaが生成されなくなっていました。そのため、ビルドしてもエラー、訳がわかりません。(最初の頃は勝手に生成されていた)
色々、調べてると結構悩んでいる人が多いらしくヒットはするんですが、どうも状況が違う。(res以下で、大文字まじっていると問題がでるとか色々ありました)ただどれも共通しているのが、ビルド時にwarningがでてるらしい。でも今悩んでいるのは、最初のプロジェクト生成時に、R.javaができないこと。(こんな感じで、gen以下に何も生成されません)


色々見ていると、そもそもR.javaはレイアウトの変更によっても自動的に更新が本来はかかるらしい。そこで思いついたのが、自分が自動ビルドのオプションはずして、手動にしたこと。そこで、プロジェクト生成して、R.javaはないけどかまわずそのままビルドしてみたら、勝手に生成してくれました。(ビルドしたところ、無事R.javaを生成してくれました)

ただ、この前悩んでたときは、プロジェクト生成後、ビルドするまえに色々ソースの修正してたら最初のビルドでR.javaを生成してくれませんでした。もしかしたらwarning出てたのかもしれません。よく注意していないと。

2011年11月3日木曜日

chromeブラウザの印刷機能(プレビュー含む)

Windows, Mac, Linuxでも愛用しているchromeですが、印刷機能がかなり貧弱でした。それが夏前くらいにいつの間にかプレビューがやっとついてました。(どうも、6、7月くらいについたらしいです)その後、8月くらいに「PDF出力」がついてるのに気づきました。
それまでは別のadd-onをつけないといけなかったのが、自前でPDF出力機能をもったようです。(おそらくそれを使ってプレビューを実現してたんでしょう)しばらく使ってみてたんですが、どうも出力PDFの品質が悪く、しかもファイルサイズが大きいです。(印刷設定がメニューにありません)おまけに、HPに日本語が混じってると、印刷がまともにできません。(出力は何事もなく終わりますが、その後出力ファイルをAcrobat Readerで見てみると、HPが真っ白です)しばらく待ってましたが、未だに日本語HPはだめだし、印刷設定もできません。しかたなく、今はshift+Ctrl+Pで、印刷機能を呼び出してそこでAcrobat Distillerを選択、印刷設定をしています。どうもデフォルトがイメージとしてしか出力できないようです。

2011年10月30日日曜日

AndroidでAR(人工現実)

さてAndroidの開発環境ができたので、早速ARのアプリをインストールしてみます。NyARToolKit for Androidというのがあり、DLしてきました。ビルドしてみるとエラーがでます!?エラーの箇所を見てみると、コメント部分が文字化けしています。文字コードの解釈ミスですね。(ファイルはUTF-8ですが、SJISと誤認識しています)試しに一つのファイルの文字コードをUTF-8に設定すると、そのファイルのエラーは消えました。なので、プロジェクト全体のプロパティを文字コードUTF-8にしてビルドしました。(自動ビルドだとキャッシュの影響がわかりにくいので、手動にしてます)OpenSourceでは当たり前の警告は一杯でましたが、無事動きました。さすがにGalaxy S2 1.2GHz x2の威力で、サクサク動きます。(マーカーがカメラ内に2個入っても、アニメーションしてくれます)

2011年10月29日土曜日

UbuntuにAndroid開発環境を構築

今度はLinux(Ubuntu)でAndroid開発環境を構築してみます。ターゲットPCは余ってたネットブックPC(Atom:N270 1.6GHz)です。前回のMacBook Airに比べると非力感は否めませんが、一昔まえなら普通の能力です。WindowsXPも普通に動いていました。
さてUbuntuというディストリビューションですが、このところ個人ユーザーからは結構人気があるようですが、実は自分はあまり好みでなかったりします。ただRedHatが商業ベースに移行してしまい、Fedoraは実装が挑戦的すぎて、実験や実用には向きません。実用性を重んじるならCentOSというところですが、さすがにstableすぎてパッケージのVerがちょっと古いです。文句ばかりいっても仕方が無いので、はやりにのってUbuntuでトライです。
Macとちがって注意するところは以下の2点です。

  1. javaがLinuxのくせにSun Javaじゃありません。Oracleに買収されたのに腹を立てたのかOpenJDKがデフォルトで入っています。インストールするにはデフォルトではオフになっているリポジトリで「Canonicalのパートナー」をオンにしないと、インストールすらできません。(インストール後、複数のjava環境からSun Javaを選択することを忘れずに)
  2. eclipseのパッケージはUbuntuにも用意されているんですが、独特のカスタマイズがしてあるらしく日本語化等で問題を起こすことが多いので、eclipseのHPからDLしてきて個人環境に展開して使ったほうがいいです。

準備に半日くらいかかって(Android SDKの構築でパッケージのDLに時間がかかります)、いざ実行ですがAndroidのEmulatorに異様に時間がかかります。Macでも絵がでるまで30秒くらいかかりましたが、その比じゃありません。しかもeclipseの動きも恐ろしく鈍く、自動で動いている構文チェックで問題ない所でエラーをしばらく表示し続けていました。Emulatorもあまりの遅さにHelloAndroidが起動するのに時間がかかりすぎて、TimeOutのダイアログが表示されるしまつ。(我慢してれば起動しますが)
これはダメですね。とても実用に耐えません。元々、eclipse自体javaでできていてそんなにキビキビ動く方ではなかったんですが、色んなプロセスを動かしている感じで、メモリも相当くっています。メモリをたくさん積んだ64bitのWindowsが必要そうですが、Androidが32bitなのでちょっと設定に注意が必要です。どうしたものか。

追記
翌日、MacBookでシステムアクティビティ見ながらeclipse動かしてみましたが、Androidの開発環境動かし始めたらメモリ800MBくらい消費しているようです。これはメモリ1GBのネットブックでは無理だ。

2011年10月28日金曜日

MacのAndroid EmulatorでWarning、NSQuickDrawViewが出続けます

NSQuickDrawViewのWarinigがeclipseのAndroid Emulatorでよくでます。(たまに出ない時もある)動作的には動くようですが、たまに画面がおかしくなるときもあります。
気になってぐぐってみましたが、どうもMacのEmulatorでAudio関係のAppleのデバイスドライバ(?)で出力されるようです。英語のメーリングリスト見ると、2008年の頃から言われ続けて、いつかは修正されるだろうと、Warinigだから気にするな、と言われ続けていますが未だに修正されていません。
他にもEmulatorの動作見てるとあやしいところがあるし・・・、Ubuntuで環境作って試してみるかな。

MacにAndroid開発環境を構築

Docomoが3メーカーの最後に2011年冬春モデルを発表しましたが、つまらない結果でした。iPhoneは予約しても何時になるかわからないとのことで、すぐ入手できるGalaxy S2を購入してきました。

それで早速Androidの開発環境を構築ですが、何となく放置気味だったPCのMac Book Airに作りました。構築方法は各所で公開されているので、基本的にやった項目だけ書いときます。


  1. MacのJavaバージョン確認(WindowsなんかだとMSのがデフォルトで入っているので、Sun(今はOracle配下(;_;))のJDK入れないといけません)
  2. eclipseをインスト^ール。(古いのが入ってたので、最新のIndigoをインストール)
  3. eclipseの日本語化。(別に無理にしなくてもいいけど、なんかの時に検索に便利だから)
  4. Android SDKのインストール。
  5. eclipseのソフトウェアインストールで、Android ADTのインストール。(Androidのバージョンを選ぶんですが、ネットからDLしてくるんでAllなんてやると時間が大変なことになります。途中、色んなメーカーからのDLも入ります)

これで終了です。No5では2,3回eclipseの再起動が入りましたが、例によってHelloAndroidを作ってみて、Galaxy S2にも入れてみて動作を確認しました。
eclipse.iniでメモリ確保量をデフォルト(なんと初期が40MBしかない)から256MBにしたんですが、あいかわらず動作のろいですね。またAndroid Emulatorの起動が遅く、最初30秒くらいかかったのには驚きました。(一応Core2Duoの2.13GHz、SSDだからもっと速いと期待してたのに)

あと、eclipseのせいなのかjavaのせいなのか(おそらくjavaだと思います)強烈なキャッシュがきいていて、ソースを変更してもすぐには反映されません。特にEmulatorの方には反映が遅い気がします。再起動しても、すぐだと反映されない時がありました。確実なのはシステム再起動なんですが、毎回そんなことやってられないのでどうしたものか。(プロジェクト→自動ビルドをはずしたほうがいいんだろうな)

2011年10月17日月曜日

「おサイフケータイ」の調査

今更ながらスマホが欲しくなりました。今使ってるのは、3,4年前にかったDocomoのパナソから出てた、とっても薄いガラケーです。(力加えたら、折れそうw)
ただ前からスマホに興味はあったんですが、問題なのは日本製のスマホにはどうも興味が出ず、iPhoneかサムスンがいいんですが、「おサイフケータイ」機能がありません。これ一度使い出すと、もうコンビニなんかで普通の財布出す気になりません。(これのおかげで、小銭地獄から解放されましたヽ(^。^)ノ)
日本製のスマホなら「おサイフケータイ」ついてるのがあるんですが、どうにも面白みがなくまたiPhoneが最初欲しかったんですが、繋がらないケータイほど意味がないものはなくて、Docomo以外使う気になれません。(最初、iPhoneが日本に来る時DocomoとSoftBankで争いましたが、官僚的なDocomoではジョブズの出してきた条件飲まないよな)
ただ、どうにも我慢ができなくなりふと思ったのが「おサイフケータイの機能使うのに、携帯の契約している必要があるのか?」です。元々、自分はこの携帯は代金を購入時に全額支払い済みです。この携帯の契約解除して、本体だけ持っていればお金のチャージをする方法があれば使えるのでは?と考えました。調べてみると、Edyチャージ機かコンビニで入金できるそうですが、自分の付近にはチャージ機なんて見たことないし、コンビニでチャージなんてしたことない・・・ できるんか?ところで、自分はPasmoの利用状況を見るためにFelicaリーダーを購入してあり、Edy ViewerもPCに入れてあります。ただ、Ver2だったんですが、ネットで調べたら今はIE6以上を使えば、ブラウザでEdy Viewer3.0が使えて、そいつはなんと入金までできちゃうんですね。これで入金の問題はクリアしました。ということで、実験です

1.まずEdyのロックを外します。(普段はロックしていて、使うときだけアンロックしてます)
2.携帯の電源切って、Edy Viewerで利用状況の確認をしてみたら使えました。OK
3.次に携帯の電池を抜いてみたんですが、Edy Viewerで認識されません。NG
4.お次は、携帯からSIM(FOMAカード)を抜き、携帯の電池だけセットして(但し、携帯の電源はOFF)Edy Viewerで利用状況を確認したら見ることができました。OK
5.試しにこの状態で(PCから)入金してみたら、入りました。OK
6.最後に、SIMを携帯に差してから電源をON。携帯で残金を確認したところ入金されていました。OK

以上のことから、どうも携帯のバッテリが多少使われるようですが、SIMは不要のようです。(現状の電話メーカーはSIMの方にFelicaの機能を入れたいと画策しているという話を聞いていたので、今回の実験を思いつきました。)これなら今の携帯を解約して、スマホにしても問題なさそうです。(スマホを次に買い換えるまでには、スマホの方にもNFCが普通にのり、日本でも使えるようになってることを祈って・・・)

20111024追記
その後、携帯を変えたんですがEdyがエラーで使えなくなりました。これだけ念入りに実験したのに・・・、ドコモshopにいって話をしたら703(903)以降の機種では何らかの時にパケット通信が発生して、解約すると使えなくなると。(自分のは705)電源切ってまで試してみたのに、意味がないーーー 仕方ないからEdyカードでも買うか。

後で冷静に考えたら、中古で売ったときにそれ買った人が使っちゃうとか面倒なことが起きそうなんで携帯解約したら自動的にロックするかどうにかするようにしたんでしょうね。

2011年10月4日火曜日

Windows8 β試してみた

Windows8のβが公開されたので動かして見ました。
といってもいきなり生のPCを用意するのも怖いので、最初はVMPlayerでやろうとしたんですが、64bitの32bit版もどちらもダメ!(ぐぐったら、VMWareでは動かした記事があったんですけどね)
しかたないのでVirtual Boxで試して見ました。こちらは問題なく64bitでも動作。(但しhost OSはWindows7 64bitです。32bitで動くかは不明。)特に1ページレビューしか見ずに触って見ましたが、どうもよくわかりません。四苦八苦してログアウトとシャットダウンはわかりましたが、最後でこけました。まあ、βだし、仮想環境だし・・・・(あと、Windows Live ID要求されたのはちょっとびっくりしました。そんな記事見た記憶なかったので。まあ使わないけど、一応持っていますが。)

2011年10月1日土曜日

WindowsXPの動きを速くする

古いDynaBookで、思い入れの強いやつがあります。ビデオチップにTridentを積んだ(これしか製品化は聞いてません)、とても薄いやつです。バッテリもへたり、買い直したんですが更新を繰り返すうちにどんどん遅くなりました。どうも更新情報を起動時に読み込んでいるようです。(メモリが512MBなので、足りなくなるようです)どうしたものかと思っていたんですが、M$のHPに更新情報の管理データがおかしくなった場合の対処ページがあります。


これを行うと、動きが速くなるという話がありました。試してみたところ、確かに速くなるようです。ただ、Windowsはよくも悪くもタフにできてて、こういうデータは消しても自動的に再構成してくれます。しばらく様子を見ないとなんともいえませんが、とりあえず手順をメモしておきます。

1.スタートメニュー→コントロールパネルから管理ツールを起動する



2.自動更新のサービスを一旦停止する(v6の場合で説明がされている)

 注:最後の方のXPだと「自動更新」という日本語名になってたりします

3.以下の場所にあるファイル(フォルダ)を削除する


4.自動更新のサービスを再開する


これを行うと、たった512MBしかメモリがなくても快適に動作するようになりました。(使用メモリがこれまで512MBを起動直後から超えていることが多かったのが、200MBちょっとに激減しました)しばらく動かしてると、削除したファイルとフォルダがまた作成されています。消したときは100MB以上あったんですが(まさかこれがメモリに読み込まれていたのか!?)、最初は小さなものです。また遅くなったら、見てやらないといけないですかね?(Windows7でも同じようにいけるとか・・・でもセキュリティとか厳しくなってるから、少し厄介になってるかな?)



2011年9月24日土曜日

VisualStudio コンパイラの動作について

WindowsでVC++のプログラムの動きを見ていて気づきました。


プログラムが動作するための定数テーブルをバイナリファイルから読み込むプログラムの動きがどうも安定しないので、デバッグしてみました。
当該プログラムはバイナリで「複数」のテーブルデータが格納されており、いったんファイルをすべて読み込み、それをテーブル毎にアドレス計算してmemcopyでテーブル毎に分割して配列に格納しなしてます。
問題はバイナリファイルの定義が構造体の集まりになっており、構造体内の各部のサイズ計算が意図したものとことなり、memcopyでバイナリでコピーしてしまうとバイトがずれているようです。(メモリアクセスする場合は、当該CPU、OS、コンパイラによるアライメント、IA32だと4バイト単位、1IA64やx86_64なんかだと8バイト単位くらいになります。(x86_64は注意が必要です。Linuxだと4バイト単位のアライメントでデフォルトは行われます。OSが32bitか64bitも因子として関係してきますから)

ちょっと実験してみました。プログラムは以下の通りです。

#include <iostream>

// 基本的な構造体
struct {
double w1;
double w2;
} st1;

// 1byteを間に入れてみる
struct {
double w1;
bool dummy; // アライメントを崩す変数を定義する
double w2;
} st2;

void main()
{
std::cout << "Hello World!!" << std::endl;

std::cout << "st1 size = " << sizeof(st1) << std::endl;

std::cout << "st2 size = " << sizeof(st2) << std::endl;

}


これをVS10で設定をデフォルトにて実行した結果を以下に示します。

Hello World!!
st1 size = 16
st2 size = 24

bool変数(必要なのは1bitなんですが、通常のコンパイラは1byteにします)を間に一ついれただけですが、アライメントを調整するため8バイトかけてます。
次にコンパイルの設定で、「コード生成」→「構造体メンバーのアライメント」という項目があり、ここを「規定値」{デフォルトあ8)を「4バイト(/Zp4)」にします。

Hello World!!
st1 size = 16
st2 size = 20

見事にアライメントが4バイトにされ、bool dummyの後には3倍とパディングされました。
VC++ではオプションが「Zp]のようですが、「Zp1」なんてオプションもありました。ちょっと無茶苦茶なコードに(実行時間がかかる)展開されそうですが試してみました。

Hello World!!
st1 size = 16
st2 size = 17

本当に余分なパディングは一切しないようになっています。
やはり高級言語でmemoryのアドレスへの配置を意識しなければいけないようなコードを書くと、維持性で問題を起こします。
Linuxだとこの辺りはCPU、およびOSが32bitか64bitで固定だったと思います。(アライメントは4バイトか8バイトしかない。M$はなんで1バイトのパックまでできるような柔軟性を持たせるんだ!!組み込みのプログラムを書くときしか使わないだろうから、VS-Embededというバージョンを作るなり、そういう属性のプロジェクトをできるようにして、そこでだけ許可するようにしてくれ!)
ちなみにVCには構造体、個々にパックをいくつで(コンパイルを)行うかを指定する#pragma pack指定があり、さらにチューンすることがプログラマに許されています。
(こったプログラムを容易に作れるのと、高い維持性を持たせるのは難しいです)

2011年9月18日日曜日

protocol bufferのサイズ制限について(protobuf-2.1.0)

C++のオブジェクトをシリアライズ化するのに便利なgoogle protocol buffer(PB)を使ってます。ある時、プログラムの実行記録に使っている時、以下のWarningがでてきました。


libprotobuf WARNING google/protobuf/io/coded_stream.cc:462] Reading dangerously large protocol message.  If the message turns out to be larger than 67108864 bytes, parsing will be halted for security reasons.  To increase the limit (or to disable these warnings), see CodedInputStream::SetTotalBytesLimit() in google/protobuf/io/coded_stream.h.


よくわかりませんが、PBの扱えるサイズがセキュリティ上の問題から64MBだよと言ってるらしいです。この時のログは40MBくらいでした。様子を見ると、どうも制限がかかるのは「入力」バッファのサイズのようです。(考えてみればあたりまえですが、デコードするとき一度メモリ上に読み込むはずで、そこにMAX制限がかかってます)
ソースコードを見てみましたが、ばっちりlimitが入ってました。

coded_stream.cc:

namespace {

static const int kDefaultTotalBytesLimit = 64 << 20;  // 64MB

static const int kDefaultTotalBytesWarningThreshold = 32 << 20;  // 32MB  ←警告を出すサイズまで定義されてます。


このサイズを変えればリミットと変えれるのかなと思って少し調べたら、入力ストリームに以下のメソッドがありましたが、コメントを見ると他のコードを混乱させるので、使うのはやめたほうがよさそうです。

void CodedInputStream::SetTotalBytesLimit(
    int total_bytes_limit, int warning_threshold){
  // Make sure the limit isn't already past, since this could confuse other
  // code.

ぐぐってたら、同じようなシリアライズ化のライブラリにMessagePackというのがありそちらのほうが高速だというのがありました。ちょっとそれとも比較してみると。

・制限のチェックをしているのはInputです。
→実装上、protbuf-2.1では入力データをmemcopyしてからデコードしているので64MBの制限がかかります。protbufと似たようなライブラリのMessagePackは入力の実装がmemcopyではなくポインタコピーで済ませているので入力(デコード)がprotbufより速い。しかし最新のprotbuf-2.4.1のInputの実装を調べてみたらmemcopyからポインタコピーになっていました。
2.1で制限として定義されていた変数名も2.4.1ではなくなっており、おそらく64MBの入力サイズの制限はないと思います。(これ間違いだった!!)

・しかし物理的な上限は発生します。
入力チェックのメソッドと思われるところで、入力ポインタ(current_point)のチェックをしているところがあり、真っ先にINT_MAXと比較しています。
当たり前ですが、ポインタはメモリアドレスを表わしていますから最大の値はINT_MAXになります。
またやっかいなことにこのINT_MAXは当該ライブラリが実行されるOSのアーキテェクチャに依存します。
つまり32bit OSの場合には物理的に4GBが最大になります。(ロギング等、実行は64bit linuxでやり、読み込みが32bit Windowsのプログラムなんかだったりするとうっかりこの制限にひっかるので注意!)

まあ、こんな大きなサイズのファイルをめったに作成しないでしょうが念のため


実験してみました。単純に同じデータをどんどん追加していく試験プログラムを作ります。(ファイル名:tttに追記していきます)


[ examples]$ ./add_person_cpp ttt
[ examples]$ ls -l ttt
-rw-r--r-- 1 hoge hoge 29561520  9月 16 15:50 ttt ←tttのサイズはまだ32MB未満です
[examples]$ ./list_people_cpp ttt|tail
  E-mail address: rinrin.hoge.com
  Mobile phone #: 2222
Person ID: 200
  Name: rinrin
  E-mail address: rinrin.hoge.com
  Mobile phone #: 2222
Person ID: 200
  Name: rinrin
  E-mail address: rinrin.hoge.com
  Mobile phone #: 2222
[examples]$ ./add_person_cpp ttt
[examples]$ ls -l ttt
-rw-r--r-- 1 hoge hoge 33661520  9月 16 15:53 ttt ←tttのサイズが32MBを超えました!
[examples]$ ./list_people_cpp ttt|tail
libprotobuf WARNING google/protobuf/io/coded_stream.cc:462] Reading dangerously large protocol message.  If the message turns out to be larger than 67108864 bytes, parsing will be halted for security reasons.  To increase the limit (or to disable these warnings), see CodedInputStream::SetTotalBytesLimit() in google/protobuf/io/coded_stream.h.
  E-mail address: rinrin.hoge.com
  Mobile phone #: 2222
Person ID: 200
  Name: rinrin
  E-mail address: rinrin.hoge.com
  Mobile phone #: 2222
Person ID: 200
  Name: rinrin
  E-mail address: rinrin.hoge.com
  Mobile phone #: 2222
[examples]$

読み込むファイルが32MBを超えると、warningがでました。(ただ、まだ正しく読めてます)
またこれ以降、追記時に一度読まないといけないのでwarningがでるようになりました。

[examples]$ ./add_person_cpp ttt
libprotobuf WARNING google/protobuf/io/coded_stream.cc:462] Reading dangerously large protocol message.  If the message turns out to be larger than 67108864 bytes, parsing will be halted for security reasons.  To increase the limit (or to disable these warnings), see CodedInputStream::SetTotalBytesLimit() in google/protobuf/io/coded_stream.h.

ただ、まだ正しく読めます。


新しいprotobuf-2.4.1を試そうと考えたが、そもそもprotobufの実装が違うんだからlib内の関数のエントリー名を違えば、protocが生成するヘッダーだって異なってくるのが当たり前。(libだけすげかえれば・・・・なんて甘いことはだめだった Orz)
以下のように強引にヘッダーの場所やライブラリの場所を、2.4.1に指定して(システムにはすでに2.1.0がインストールされていますが、まだこの形態をVerUpしたくない)リビルドします。

[examples]$ c++ list_people.cc addressbook.pb.cc -I/opt2/home/maeda/protobuf-2.4.1/src -lpthread -L/opt2/home/hoge/protobuf-2.4.1/src/.libs -lprotobuf -o list_people_cpp

また実行前にLD_LIBRARY_PATHを追加して、2.4.1のdllを認識させます。

[examples]$ ldd ./list_people_cpp
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003a76000000)
        libprotobuf.so.7 => not found ←認識できていない!!
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003a7b800000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003a75800000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003a7b400000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003a75400000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003a73c00000)
[examples]$ echo $LD_LIBRARY_PATH
/opt/intel/Compiler/11.0/084/lib/intel64:/opt/intel/Compiler/11.0/084/ipp/em64t/sharedlib:/opt/inte\
l/Compiler/11.0/084/mkl/lib/em64t:/opt/intel/Compiler/11.0/084/tbb/em64t/cc4.1.0_libc2.4_kernel2.6.\
16.21/lib:/opt/intel/Compiler/11.0/084/lib/intel64:/opt/intel/Compiler/11.0/084/ipp/em64t/sharedlib\
:/opt/intel/Compiler/11.0/084/mkl/lib/em64t:/opt/intel/Compiler/11.0/084/tbb/em64t/cc4.1.0_libc2.4_\
kernel2.6.16.21/lib:/usr/local/lib:/usr/local/lib64:/opt2/qtcreator-2.0.1/lib:/usr/local/lib:/usr/l\
ocal/lib64:/opt2/qtcreator-2.0.1/lib
[examples]$ setenv LD_LIBRARY_PATH /opt2/home/hoge/protobuf-2.4.1/src/.libs:${LD_LIB\
RARY_PATH}
[examples]$ ldd ./list_people_cpp
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003a76000000)
        libprotobuf.so.7 => /opt2/home/hoge/protobuf-2.4.1/src/.libs/libprotobuf.so.7 (0x00002ad95\
96e8000) ←dllを認識した!!
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003a7b800000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003a75800000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003a7b400000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003a75400000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003a73c00000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x0000003a76400000)
[examples]$

試してみたらダメ!!同じwarningが出ます。2.4.1の実装を調べたら、2.1.0から消えた64MBの閾値を格納する変数が別の位置にしっかり定義されていました。

    google::protobuf::io::CodedInputStream decoder(&input);  // has initializer but incomplete type
    decoder.SetTotalBytesLimit(100000000, 60000000);

とやって強引にlimitを変更しようとしましたが、最初のdecoderを宣言するところでコンパイルエラーがでます。(引数に入れているインスタンスがinitializerを必要としていると、言ってきました)
どうもコメントにあるように、このメソッドは使っちゃだめなようです。(googleのところも散々調べてみましたが、特殊な入力の時だけこのSetToalBytesLimit( )は働くようですが、それでもunusualだと書いてました)

PBの最初のところに、「これはRPCのデータを送るために作られた」、「ネットワークで大きなサイズのデータを送るのは問題がおきる」と書いてありましたので、PBをログ記録に使うのはそもそも用途が間違っているようです。