[読書]GNU開発ツール/西田亙

まともにプログラミングできるLinux PC環境が整ったので、C言語を再開してみようかな、と思っています。

元々Javaを始めたきっかけが、仕事で使うのがCばかりで、オブジェクト指向とかその辺りのことが全く知識として得られないからでした(ですので、実際には多分まだCの方が書いたコーディング行数は多いと思うのですが…学生時代もCオンリーでしたし)。

で、本書です。今までgccでのプログラミング経験はあるものの、あまりgccコマンドが何をやっているのか知っておらず、ldコマンドなんかも自分で叩いたことはありませんでした。事始めとして、そういった部分を学んでみようと思い、本書を購入しました。

書籍紹介より:

プログラムが誕生するまでには、４つのビルド工程が必要ですが、普段はgccコマンドが裏方でこっそりと処理しているため、私達の目に触れることはありません。その挙動は、-vオプションを与えることで明らかになります。
gcc -v hello.c を実行した際に表示される、呪文のようなメッセージ群を解読するところから、本書は始まります。

まさに自分が知りたい内容です。

本書は"コンピュータアーキテクチャシリーズ"というシリーズ全6章のうちの前半2章、だそうです。が、現時点では本書以降はまだ出版されていません。

ちなみに自費出版だそうで、購入は著者のサイト、もしくはジュンク堂ネットストアHONで注文できます(Amazon等では購入できない様です)。ジュンク堂実店舗でも扱っているところがあるようで、このページで在庫ありの店舗が確認できます。

内容としては、前述の書籍紹介引用部の通り、gccが内部で行っているプリプロセス(cc1 -E)、コンパイル(cc1)、アセンブル(as)、リンク(collect2)の動作を理解し、手動でビルドしてみよう、というものです。リンクは静的リンク、動的リンクそれぞれの方式が解説されています。

gccコマンドを手で入力したり(あるいは簡単なMakefileを手動で作成する程度)、用意された./configure && makeコマンドを叩くくらいしか経験のない私のような人は、一度体系的にこの辺りを学んでみてはどうでしょうか。

ところで、本書がターゲットとしているgccのバージョンはgcc3.3.5で、gcc2.95やgcc4.0.4のことは少し触れられているものの、Ubuntu10.04のデフォルトバージョンであるgcc4.4.3で試してみてうまくいかない箇所がありました。以下にこの部分について記載します。

p.131 実行例16 では、自分が作成したhello.oとlibc.aをリンクしてみて、これだけではリンクが不十分であるという説明があります。undefined referenceが存在するからなのですが、この結果がgcc4.4.3では大きく異なります。

このundefined referenceを解決するために、p.137でlibgcc.aもリンクするようにしています。しかし、Ubuntu10.04のgcc4.4.3ではこれだけでは不十分でした。

gcc -v -static hello.c を実行すると分かるのですが、Ubuntuのgccでは、-lc(libc.a), -lgcc(libgcc.a)の他、-lgcc_ehというライブラリもリンクされており、手動でリンクする場合にもこれを追加する必要がありました。従って、p.137 実行例21の実行コマンドは、

ld hello.o --start-group /usr/lib/libc.a `gcc -print-libgcc-file-name` `gcc -print-file-name=libgcc_eh.a` --end-group; echo $?

となります。ここで登場する-lgcc_eh(libgcc_eh.a), --start-group/--end-groupとは何ぞや？という疑問については、Googleに聞いてください…

また、p.138にcrtファイル群の説明がありますが、この中のcrtbegin.oというファイルが、当環境ではcrtbeginT.oという名前のようでした(ただし、この差異は本題とは関係なさそうです)。

coroid-server用(さきゅばす用)ffmpegのビルド手順 on Linux

なんとか環境が整えられてきましたので、以前宣言していましたLinux用ffmpegのビルド手順を記載します。

さきゅばす(と、さきゅばすを利用しているcoroid)ではコメント埋め込み用のフィル多機能をffmpegに追加している関係で、一般的な野良ビルドffmpegは利用できません。また、私が同梱しているffmpegはFAACをリンクしていないため、音質がかなり悪いです。従って、基本的には利用者自身でffmpegをビルドする必要があります。

Windows向けのffmpegは不定期ににちゃんねるのさきゅばすスレに上げられてる方がいらっしゃいます(これはcoroidでも利用できます)ので必ずしも自分でビルドする必要はないようですが、Linux向けはないため、今回、Linuxでの運用のハードルを下げられるよう、ビルド手順をまとめました。

Ubuntu10.04での手順になりますが、以前CentOS5.3でビルドしたときも概ね同じでした。ただし、ディストリビューションによってパッケージ名などは異なりますので、その点は適宜読み替えてください。

あと、なぜタイトルにcoroid-server用と銘打っているかというと、今回の手順でffmpegにリンクするライブラリが、coroidを動作させるためにあればよい、というもののみだからです。さきゅばすで用いる場合には、lameなど他のライブラリもリンクさせたほうが良いと思いますが、それらについては今回の説明には入っていません。

用意するもの

以下のパッケージをパッケージマネージャからインストールしてください。

• gcc
• g++ (これは必要なかったかも)
• autoconf
• automake
• binutils
• pkg-config
• nasm
• yasm
• subversion
• git-core

また、以下のサイト/リポジトリからそれぞれのプロダクトのソースを取得・展開しておいてください。

• faad2 (ffmpeg内部に取り込まれ不要になったようです)
  • http://www.audiocoding.com/downloads.html
• faac
  • http://www.audiocoding.com/downloads.html
• x264
  • gitリポジトリから取得します。以下のコマンドを実行してください。
    git clone git://git.videolan.org/x264.git x264
• ffmpeg
  • Subversionリポジトリから取得します。以下のコマンドを実行してください。
    svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
• coroid/さきゅばす用パッチ (2010/09/11 最新のffmpeg(r25102)に合わせて更新) 
  • http://yukihane.dip.jp/dist/imcubus/linux/20100911/patches_r25102.tar.gz

ビルド

以下、インストール先は/home/yuki/ffとして説明します。

環境変数設定

以下のコマンドを実行してください。

$ export FF_PREFIX=/home/yuki/ff (インストール先を変える場合、ここを変更)
$ export LD_LIBRARY_PATH=$FF_PREFIX/lib
$ export C_INCLUDE_PATH=$FF_PREFIX/include
$ export PKG_CONFIG_PATH=$FF_PREFIX/lib/pkgconfig

faad2

以下のコマンドを実行してください。

$ cd faad2-2.7
$ sh bootstrap
$ ./configure --prefix=$FF_PREFIX --disable-shared
$ gedit Makefile
でMakefileを開き、下記の行
SUBDIRS = libfaad common frontend plugins
からlibfaad以外を削除し、以下のようにし、保存します。
SUBDIRS = libfaad
$ make
$ make install

faac

以下のコマンドを実行してください。

$ cd faac-1.28
$ patch -p1 < ../patches/faac-1.28.patch
$ ./bootstrap
$ ./configure --prefix=$FF_PREFIX --disable-shared
$ gedit Makefile
でMakefileを開き、下記の行
SUBDIRS = include libfaac common frontend
からcommon, frontendを削除し、以下のようにします。
SUBDIRS = include libfaac
$ make
$ make install

x264

以下のコマンドを実行してください。

$ cd x264
$ ./configure --prefix=$FF_PREFIX
$ make
$ make install

ffmpeg

以下のコマンドを実行してください。

$ cd ffmpeg
$ patch -p0 < ../patches/ffmpeg1.patch
$ patch -p1 < ../patches/ffmpeg2.patch
$ ./configure --prefix=$FF_PREFIX --enable-memalign-hack --enable-nonfree --enable-gpl --enable-postproc --enable-pthreads --enable-libfaac --enable-libx264 --enable-avfilter --disable-shared --disable-debug --extra-ldflags="-L$FF_PREFIX/lib -I$FF_PREFIX/include"
$ make

以上で終了です。ffmpegディレクトリにffmpegができていると思いますので、coroid/binにコピーしてください。

しかしAndroid2.2で普通にニコニコ動画コンテンツの再生が行えるようになってるんですね。

HT-03Aには縁の無い話だとは思いますが…

さきゅばすのNicoBrowser拡張 1.4.3 不具合修正と音質改善

ダウンロードはこちらから。

いくつかの不具合修正

• 投稿者コメントの変換後削除するチェックボックス情報が保存されない
• 投稿者コメントタブ等の保存先ファイルチューザ起動ボタンが機能しない
• 入力ソース(動画、コメント、投稿者コメント)の保存先ディレクトリを同一にしてファイルを自動命名した場合、命名が正しく行われない

と、変換時のデフォルトオプションの調整

• オーディオコーデックをaacからlame(mp3)に変更(Windows Media Playerで再生できないようでしたので1.4.4で戻しました…音質改善方法はダウンロードページ下部に記述している通り野良ビルド版ffmpegを利用してください。)

を行いました。

不具合修正の3点目について、元々3種の入力ソースはそれぞれ別ディレクトリに保存することを想定していましたが、今回の対応で同一ディレクトリに保存できるようになりました。

ただし、これに伴い、投稿者コメントを自動命名した場合の拡張子は.xmlから.txmlに変わっています。

ffmpegでInvalid pixel aspect ratio 0/1

いつの頃からか、ffmpegでlibxvidを用いた場合、アスペクト比の指定(-aspect 4:3など)を行わないと、タイトルのようなエラーが出て処理が中断されるようになっています。

また、rev23043において、svn://svn.mplayerhq.hu/soc/libavfilter で開発されていたavfilterのパッチがffmpeg本体のソースにマージされたようです(フィルタの実装は依然こちらで管理されているようです)。

しかしながら、従来より、このavfilterのコードを導入したffmpegでは、-aspectの指定が効いていないような動作になっており、今回ソースがマージされたことでノーマルなffmpegでも同事象が発生するようになったようです。

今のところ対応策はこちらやこちらに記載されている通り、ffmpegのconfigureオプションでavfilterを無効にする(—disable-avfilter)、というものが挙げられています。

ところで、さきゅばす(拡張版も)ではまさにこのavfilter機能を用いてコメント埋め込みを行っていますので、--disable-avfilterするわけにはいきませんでした。ですので、以前の報告以来、ソースコードの以下の部分をコメントアウトして利用しています。

ffmpeg.c:

#if CONFIG_AVFILTER
ost->st->codec->sample_aspect_ratio = ist->picref->pixel_aspect;
#endif

わざわざCONFIG_AVFILTERでくくっているところをコメントアウトするので、何らかの不具合は出るのだと思いますが、入力と出力のアスペクト比を変えないのであれば、問題なさそうな気もします。

MinGW上でデバッグなんてやりたくなかったので今まで放置していましたが、Linuxで環境を整えたので、気が向いたら内部動作を確認してみようと思います(それとも本体にマージされ問題が認識されたので、すぐに修正されてしまうでしょうか)。

あと、本体にマージされたavfilterでは、利用オプションが-vfilterから-vfに変わっていますが、互換性確保のため-vfilterに戻す必要がありました。こちらもffmpeg.cの修正です。

余談ですが、ffmpegについ最近VP8のエンコード/デコード機能も追加されたみたいで、こちらも取り込んでビルドしてみようと思います。Android端末でも再生できるようになるんでしょうし。

[追記]vpxはfaacと同じく—enable-nonfreeオプションが必要になったようです…配布用としてはリンクできませんね。

NicoBrowser ver.0.6.1 Java5動作不具合対応

ダウンロードはこちらから。

MacOS X 10.5.8 で動作しない、と報告をもらいましたので見直してみたところ、Java6で導入された機能を使用していることが分かりました。

本バージョンは、Java6新規追加機能を削除し、Java5で動作を再度確認した不具合対応バージョンです。新しい機能の追加はありません。

MacOS Xを所有していないもので、これで正しく動作するようになっているかは残念ながら分かりません。他に問題が出るようでしたらご報告ください。

Sun(Oracle)のJava5は2009年11月にEOSLを迎えたので、そろそろJava6に移行してしまおうかな、と思っていたのですが、AppleのJava5はまだ現役なんですかね。SunのJava5はupdate22までですが、Appleのものは現在update24で(同等のバージョン管理体系なのかは分かりませんが)、つい最近もJava5向けセキュリティフィックスが出ているようですが。

FEST-Swingを利用する(8) 視覚の威力

今回は総集編、回想回です…

過去FEST-Swingに関して記述したエントリを以下に示します。

• FESTを使用してJava GUI (Swing)のテストを実行してみる
  • FEST-Swingの紹介。FEST-Swingの機能概要を、簡単なサンプルをもとにして実行してみます。
• NetBeansでFEST-Swingを利用する その1 インストール
  • 実際にFEST-Swingを利用する場合の、NetBeansでの設定方法。
  • 現在の最新とはバージョンが異なりますが、流れは変わりません。
• NetBeansでFEST-Swingを利用する その2 JavaDoc作成
  • FEST-Swingから少し外れますが、NetBeansだとソースからJavaDoc作るのが簡単ですよ、というエントリ。
• NetBeansでFEST-Swingを利用する その3 JUnitテストケース作成
  • 実際のプロダクトに対してJUnitテストケースを作成し、実行してみます。
• NetBeansでFEST-Swingを利用する その4 テストケースの更新
  • テストファーストでプロダクトの仕様変更を行う例。
• FEST-Swingを利用する(5) EDTで発生した例外をJUnitで検知する
  • GUIに対してJUnitを適用する場合に問題となる点を解説します。
  • FEST-Swing特有の問題ではなく、本質的にはマルチスレッドへJUnitを適用する場合全般に言えることだと思います。
• FEST-Swingを利用する(6) 非EDTでのSwingアクセスを検証する
  • Swingスレッドポリシーに違反するコーディングを検知する方法の説明です。
• FEST-Swingを利用する(7) EDTで発生した例外をJUnitで検知するの追補
  • (5)で説明した機能が新バージョンで取り込まれていたので、追補として紹介します。

また、上記エントリ中の参考リンクの他、以下のサイトでも日本語でFEST-Swingについて解説されています。

• Swing コードをデバッグし、テストする – IBM developerWorks
  • FEST-Swingの作者、Alex Ruiz氏の記事です。
• FEST-SwingでFestival! – アプレッソ開発チームのブログ

これら2エントリでは、冒頭でGUIテスティング自動化の必要性について示されています。これに補足して、私のGUIテスティング自動化のモチベーションは

• GUIが嫌いだ

ということにも起因します。

GUIテストを実施するに当たって、入力を人間が手作業で行うと、必然的に出力の取得も人間が行う必要があり、結果として入出力データの妥当性確認も手作業になります。テスト入出力データ(いわゆる”エビデンス”)の管理も煩雑化し、本当にテストできているのかどうかが曖昧になってしまいます。テスト作業にしても、Excelから拾った似たようなデータを同じ入力欄に入力し同じボタンを押して…と、全く面白みのない単純作業です。これが、ソフトウェアの変更が必要になる度に重なっていきます。

具体例を挙げます。下の動画はさきゅばすの画面で入力した値が正しくコンフィグに保存されるかどうかのテスト(の一部)をFEST-Swingで実行したものです。

小規模ソフトウェアのほんの一機能をテストするためだけでもこれだけの操作が必要です。業務システムでは何回のマウスクリックやタイピング、何種類のファイルの確認が必要になることでしょうか。

GUIテスティングの自動化が達成できれば、上記のようなソフトウェア開発に取って本質的でないコスト(私に言わせれば”不本意な状況”)を改善することができます。

テストの入力データはJUnitで実行するのと変わらず、バージョン管理システムでソフトウェア本体と同期して管理することができます。出力データはすぐにテストを実行し取得することができます。出力値だけでなくテスト実行手順すらエビデンスとして保存できます。

また、テストの作成と実行作業が単調ではなくなります。動画を見てみてどうだったでしょうか。自動で画面が操作される様子を見るだけでも興味がわいてこないでしょうか。FEST-Swingによるテストは、下記引用にあるJUnitのグリーンバーに相当する威力があると考えています。

不思議なもので、グリーンバーが表示されるととてもうれしい気分になり、いつの間にかゲーム感覚でグリーンバーを取得しようと必死になってしまいます。そういった状況に深くはまってしまう症状をテスト熱中症と呼ぶのですが、実際にテストにはまってしまう人の気持ちが分からないではありません。グリーンバーの威力は絶大です。
テストファーストによるソフトウェア開発の衝撃（後篇） – IBM developerWorks

次回、第6回で”次回説明する”と書いてそのままになっていたSwingのスレッドアクセスバイオレーションの話も残っているのですが、適当に作ったさきゅばすの拡張部分が結構バグっていたことが判明してしまった(参考)ので、これを題材に、モックを利用したテストケースの作成を行っていきたいと考えています。

さきゅばすのNicoBrowser拡張 1.4.2 アクセス先URL変更(暫定)対応

ダウンロードはこちらから。

ニコニコ動画サービスURLの一部が変更になったようで、従来のさきゅばすが本来の機能を実行できない(変換ボタンを押すと”xxxの情報の取得に失敗”というエラーが出る)問題に暫定対応しました。

URL変更に伴って、サーバからはHTTPステータスコード301が返されているのですが、これに対応できていません。

今回の対応は、決め打ちされていた旧URLを新URLに書き換えただけです…

NicoBrowserにも同等機能があるのですが、こちらは正常なようです。時間が無いのでちゃんと確認していないのですが、HTTP通信に利用しているライブラリHttClientがリダイレクトしてくれているんだと思います。coroidもこの機能についてはNicoBrowserを利用しているので問題なさそうです。

ScalaスケーラブルプログラミングをScala2.8RC1で読む その1

Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala) Martin Odersky Lex Spoon、Bill Venners

実は一気読みしようと思っていたのですが、全く進んでません…関数型言語なめてました。そんなわけで第一弾です。

本書はScalaバージョン2.7.2をベースにしたScala言語の解説書です。

一方、現在のScalaの最新バージョンは2.7.7で、次バージョン2.8のRC1もリリースされている状況です。また、IDEのプラグインの対応についても、NetBeans6.8では2.8RC1向けのもののみ存在し、Eclipseについても2.8向けのプラグインの出来の方が2.7向けのものより良いという話を聞きます。

ですので、せっかくなんだから2.8RC1で始めるのが良いのではないかと考え、その上で詰まったところ等をメモしていこうと思っています。

…って、公式サイト確認したら先程RC2リリースされちゃったみたいですが。

参考サイト

• 本書の正誤表
• サンプルコードのダウンロード
• Scala2.8.0 APIドキュメント

TIPS

TIPS、といっても1点だけなんですが。コードを打ち込む際、scalaコマンドでインタプリタを起動して直接タイプするとtypoしたとき悔しい思いをすることになります。それを避けるため、コードはファイルに保存し、インタプリタ上では :load <ファイル名> コマンドでロードすると良いかと思います(ちなみに私はコマンドにコロンを付け忘れていてはまりました)。

2.7.2からの変更点

11章(p.202)までしか読めていませんので、その範囲で。

初っ端でコンパイルが通らなかったので色々変わっているのかな、と身構えていたのですが、どうやらコンパイルエラーになるのはこの1点だけのようでした。

p.68 リスト3.10, p.128 リスト7.8, p.142 リスト8.1, p.144 リスト8.2で登場する、

Source.fromFile(args(0)).getLines

は、2.8では

Source.fromPath(args(0)).getLines()

というメソッドに変更になったようです。

その他、コンパイルエラーになるわけではないですが、気づいた変更点を。

p.103 表5.5

scala.runtime.RichStringクラスは無くなっています。p.90で出てきたstripMarginメソッドみたいなものは、実はscala.collection.immutable.WrappedStringクラスのメソッドになっているようです。(こういう点が「下位バージョンとバイナリ互換性が無い」という理由なんでしょうか。)

p.135 7.6節 breakとcontinueを使わずに済ませる

Scala2.8ではbreakが導入されたそうです[参考]。

p.183 10.9節 多相性と動的束縛

Array.makeメソッドはdeprecatedになり、コンパイル時に警告が出ます。

Array.make(height, line)

は

Array.fill(height)(line)

とするようです。

p.187 10.12節 above、beside、toStringの実装

Elementクラスにaboveメソッド

def above(that: Element): Element =
  new ArrayElement(this.contents ++ that.contents)

を追加すると、前述TIPSで記述した:loadコマンドを使う方法では、型が違う、と怒られてしまいます。:loadコマンドの出力を見る限り、クラスの定義は1つずつ認識しているようなので、ElementとArrayElementが継承関係であることを認識できない、つまりクラス定義内ではアップキャスト不可、ということになります。(事前にArrayElementクラスの定義をしておき、Elementクラスをextendsしていることを明示していてもNGでした。つまりこの動作はクラス定義の順に依らない。)

普通にscalacでコンパイルすると通りますので、こういったものについてはインタプリタではなくscalaコマンドでの実行が必要みたいです。

感想・疑問点など

上で登場したgetLinesメソッド、なぜgetLinesの後に”()”が必要なのでしょうか。本書p.93には、”後置演算子は、ドットや括弧を付けずに呼び出される引数なしのメソッドである。Scalaでは、メソッド呼び出しの空括弧を省略できる”とありますので、省略できそうに思われるのですが。

と思い、APIドキュメントを見てみると、引数が無い(ように見える)メソッドには3つのパターンがあるようです。

1. RichInt#toString() のように、後ろに括弧がついているもの - 空括弧メソッド(empty-paren methods)
2. RichInt#toHexString のように、後ろに括弧がないもの - パラメータなしメソッド(parameterless methods)
3. Source#getLines(separator: String = scala.compat.Platform.EOL) のように、引数を取るがデフォルト値があるもの

上述した引用文は、このうちパターン1.について述べているようです。toStringは括弧有りでも無しでも動作しました。一方、パターン2.は括弧をつけるとコンパイルエラー、パターン3.は括弧をつけないとコンパイルエラーになります。

括弧の省略をOKにするのならば、上記全てのパターンにおいて括弧つけてもつけなくてもOK、というのが統一的な動作であると思うのですが、何か意図があるのでしょうかね。ちなみに、パターン1.と2.のどちらを用いて実装すべきかの指針はp.174 10.3節『パラメーター無しメソッドの定義』で説明されています(が、toStringとtoHexStringの例を見る限り、あんまり統一されてないのかな、とも思います)。

諸々：

• インタプリタで関数を定義した時の出力(引数の部分の表示)が変わっている。
• セミコロンが省略できたりできなかったり、小括弧”()”が省略できたりできなかったり、小括弧の代わりに中括弧”{}”が使える箇所があったり、書いたり読んだりするのに慣れが必要そう。
• <- とか => とかタイピングしにくい…マイナスとイコールってShiftキー押すか押さないかだからしょっちゅう間違う。JISキーボードと相性悪いぞこれ。
• 行末のアンダーライン”_”を見るとVBを思い出しますね。用途は全然違いますが。
• Javaとの互換性というか整合性というか、そういう部分については、ScalaよりGroovyの方が重きをおいて言語仕様考えてるんだろうな、というふうに見えます。
• 部分適用とカリー化が別物、というのは理解しましたが、Groovyのは部分適用であってカリー化じゃないだろ、っていう辺りはまださっぱりです…

ループ内で変数を宣言しない方が良いのか

要するに、Javaで下記コードmyMethod1の変数iやtwiceみたいに、ループの中で変数を宣言するとmyMethod2のようにループの外で宣言するよりコストがかかるんじゃなかろうか、という疑問です。

public void myMethod() {

    for (int i = 0; i < 10; i++) {

        int twice;

        twice = i * 2;

        System.out.println(twice);

    }

}

public void myMethod2() {

    int i;

    int twice;

    for (i = 0; i < 10; i++) {

        twice = i * 2;

        System.out.println(twice);

    }

}

私のイメージは、

• (言語は違いますが)こちらに書かれているように、変数宣言するのに何らかの命令が発生するので、わずかだがコストは増える。
• ただし、そのコストは微小で、それよりも変数のスコープを限定しメンテナンス性/可読性等を保つためにループ内で宣言した方が良い。

というものでした。

で、今回2つのメソッドをjavap -cコマンドでバイトコードに変換して、実際にどういう差異があるのか見てみました。

結果、双方同一のバイトコードが生成されました。

Code:

 0:   iconst_0

 1:   istore_1

 2:   iload_1

 3:   bipush  10

 5:   if_icmpge       25

 8:   iload_1

 9:   iconst_2

 10:  imul

 11:  istore_2

 12:  getstatic       #2; //Field java/lang/System.out:Ljava/io/PrintStream;

 15:  iload_2

 16:  invokevirtual   #3; //Method java/io/PrintStream.println:(I)V

 19:  iinc    1, 1

 22:  goto    2

 25:  return

命令の意味はJava Virtual Machine Specificationにあるそうなのですが…取り敢えず概要はひしだまさんのサイト”ひしだま's 技術メモページ”やWikipediaで理解しました。

変数の宣言に対応する命令は記述されておらず、初めて変数へ値が代入される際にその変数に関連する命令が登場しています。

以上より、(処理コスト低減を目的として)変数宣言を本来のスコープより外で行うことは、全く意味が無い、コストは完全に同一である、ということのようです。

EclipseやNetBeansで、変数宣言の行にブレークポイントが設定できないのはそういう理由なんですね、と言われて、なるほど、と思いました。

[追記 2011/3/11]

最近このページを訪れる方が多くいらっしゃるようなので、前述のサイトのC言語版についてもアセンブリを見てみました。

   1: 良い例:

   2: void test(){

   3:   int a, i, j;

   4:   for(i = 0;i < 100;i++){

   5:     for(j = 0;j < 100;j++){

   6:       a = i*j;

   7:     }

   8:   }

   9: }

  10:  

  11: 悪い例:

  12: void test(){

  13:   for(int i = 0;i < 100;i++){

  14:     for(int j = 0;j < 100;j++){

  15:       int a = i*j;

  16:     }

  17:   }

  18: }

Ubuntu10.04のgcc4.4.3で、-O0オプションをつけてみても同一のコードとなりました。0xffff * 0xffff回のループでも実行速度に差異はありません。また、上記Javaで試してみたのと同様デバッガ(GDB)でステップ実行したところ、変数宣言だけの行ではストップしませんでした。

つまり、Cにおいても変数宣言をループの外で行うことはコスト的に全く意味が無いということになります(リンク先にあるとおり、Microsoft製コンパイラのデバッグオプションを付けた場合、という限定された状況では意味があるのでしょうが。そういえばMicrosoftコンパイラはデバッグ用に変数宣言時特定の初期値を代入していたような…その分のコストかもしれません)。

結論として、現在ではループ外で変数宣言を行えばパフォーマンス改善につながる、というのは都市伝説である、と言い切ってしまってもよいのではないでしょうか。

ハードディスク運が悪い その3

• ハードディスク運が悪い
• 続ハードディスク運が悪い

の続きです。

前回書いた通り、WD15EADSをWD15EARSに交換してもらいましたが、このハードディスクでも転送速度が低いままでした。その後、試しに他のPCに接続してみたところ、それなりの転送速度になりましたので、EARSはそちらのPCで使用することにしました。そのときの経緯です。

前回転送速度を計測したPC(以降、NG機と呼称)、今使用しているメインPC(OK機と呼称)で、前述したWD15EARS、及びSeagate社のST31500341ASの転送速度を計測してみました(解像度がそれぞれ違うのは、キャプチャ画像の保存方法による差異みたいです)。

NG機 – WD15EARS

NG機 – ST31500341AS

OK機 – WD15EARS

OK機 - ST31500341AS

以上の通り、うちのWD15EARSは接続するPCによって転送速度が極度に低下する場合があることがわかりました。一方、ST31500341ASはNG機でも問題なく動作するようでした。そんなわけで、ST31500341ASはOK機で使用していたのですが、これとWD15EARSを交換し、WD15EARSはOK機で使用することにしました。EARSはAFTという技術が使用されているそうで、WindowsXPで使用するのなら昔のEADSで良かったのですが…

それぞれのPCの構成を載せておきます。

	OK機	NG機
OS	Windows XP SP3 32bit	Windows7 64bit(当初はWindows XP SP3 32bitを使用していましたが、そちらも同症状でした)
マザーボード	MSI K8N Neo4 Platinum (MS-7125)	MSI K9N Neo v1.0 (MS-7260)
サウスブリッジ	nVIDIA MCP04 rev.A3	nVIDIA MCP55
BIOS	Phoenix - AwardBIOS v6.00PG W7125NMS V1.D 052206 11:35:51	AMI 1.9

これって低速病なんですかね…？

余談ですが、他のHDDでPIO病になっていたのを発見したのでついでに貼っておきます。ほとんど使用していないものだったので、今まで気づきませんでした…

JavaScriptにおけるローカルファイルアクセス権限のポリシー

JavaScript 第5版 David Flanagan

以下の記述はjQueryを利用したときに発見したものなのですが、XMLHttpRequestももちろん影響を受けますし、その他にもJDKのJavadocなどframeで別ページを開いているようなものが、別ウィンドウ(別タブ)で表示されるようになる、といった変化が動作に現れるようです。

Web系の技術って、(開発に携わっていると大丈夫なんでしょうけど、)Webに書いてあることは仕様が決まったり当時騒がれてた時の情報だったりして、現在の仕様がどうなってるのかフォローアップするのが中々大変ですね…

JavaScriptにはsame-origin policy(オライリーのJavaScript第5版では”同一出身ポリシー”と訳されている)というものがある、ってのは理解していました。しかし、これってローカルファイルについては何も言っておらず、実際はどうなっているのか疑問でした。で、今回ハマったのでそのことを。

ローカルに置いたJavaScriptの中で、jQueryのload関数でローカルhtmlに表示を挿入しようとしました。

試してみたところ、Firefox3.6.4では想定通り挿入されるのですが、Google Chrome5.0.342.9では挿入されない。same-origin policy的にはなんとなく両方ローカルファイルだから大丈夫なんだろう、と考えていましたが実際ブラウザ間に差異が出たので調べてみました。

マイコミジャーナルの記事(及び原文”Security in Depth: Local Web Pages”)によると、

ローカルファイルに対しては「Same origin policy」は必ずしも有効になっておらず、ブラウザごとに対応はまちまちだ。

ということだそうです。

で、今回問題のGoogle Chromeのポリシーの記述を見ると、

ローカルWebページからのアクセスをローカルファイルシステム上のファイルに限定[中略]。開発の利便性や現状を加味してローカルWebページにおけるJavaScriptの実行は許可

ということで、Google Chromeにおいても、ポリシー的には動作しても良さそうに書いてあります。

その後、そういうことはTiddlyWiki(Wikipediaによる解説)を見ると良いよ、と教えてもらったので、検索してみたところ、TiddlyWikiをGoogle Chromeで利用する際の問題点が書かれたページがありました。

このページに記載されている内容のうち、--allow-file-access-from-files というオプションが気になったので調べてみたところ、5.0.335.0より動作が変わったようです。日付は2010年2月になっているので、結構最近ですね。

every HTML document hosted on a local file:// URI now lives in a unique domain. Old behavior can be re-enabled with the new flag --allow-file-access-from-files.

ローカルのファイルは全部バラバラの出身とみなすよ、ということでしょうか。ちなみにこの変更の元になったバグレポートはIssue4197かな？

ともかく、上記の起動引数を追加してやることでGoogle Chromeでも期待する動作になってくれました。

けど、ユーザにこんな面倒なことさせられないよな…

あと、JavaScriptってこういう場合には例外出してくれないんですね。JavaだとSecurityExceptionみたいなのを送出しそうですが。

さきゅばす拡張とcoroidのCentOS対応

バイナリをビルドし直しましたので、CentOS5.3上でもUbuntu上と同じ機能が利用できるようになった…と思います。すみません、”対応”と言いながら実行環境が無いので本当に動作するかは試せていません。

Wikipediaによると、CentOSは”大手レンタルサーバ会社の低価格プランで[中略]採用される事例が多い”、とのことなので対応しておいた方が後々のために良いのかな、と。

ちなみに、こちらにも記載しているのですが、現バージョンのcoroidには認証機能がないので、リモートからアクセスを許可することはセキュリティ上リスクが有ることを認識しておいて下さい。

ダウンロードはそれぞれさきゅばす拡張 Linux版(rev3)、coroid Linux版(rev2)のページから。