netail.net

_ Big Mac ▲

バージニア工科大の構築したクラスタ．Mac で作ったから Big Mac なのは分かるけど，ニュースでわざわざ「愛称」って付いてるのはやっぱり商標だから？http://biztech.nikkeibp.co.jp/wcs/j/comp/276948

_ Eclipse ▲

Eclipse 2.1 + AspectJ 1.1 環境に移行が終了．1.0.6 の頃から比べるとだいぶ環境が洗練されてきた感がある．

_ 情報処理 ▲

OO2003 のレポートのところに論文賞もらったというので名前が載ってた．

_ [work][Java]Ant with Eclipse ▲

久しぶりに Ant の build.xml を書いてみた．JAR を生成する処理とソースコードおよび周辺ファイルのZIP アーカイブ作成処理だが，それぞれ [Run]-[External Tools] から Ant build を使うと，ボタン一つで両方の処理を実行できてかなりお手軽な感じになってきた．

user.dir が build.xml を配置しているディレクトリになるようで，eclipse.home は Eclipse インストール先を指すようだし，プロジェクト自体のディレクトリを指してくれるものが見つからなくてちょっと微妙な感じ．プロジェクトのトップディレクトリに配置しろということか．

_ [論文]イベントパターンを使ったアスペクト記述 ▲

Robert J. Walker, Kevin Viggers:Implementing Protocols via Declarative Event Patterns.Proceedings of the 12th FSE (FSE2004), pp.159-169,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

FTPプロトコルでのユーザ認証を題材にした論文で，pointcut でイベントを定義する以外に，tracecut というイベント列（pointcut を使って正規表現ぽく指定する）で処理の実行を記述できるようにしたもの．実行が済んだ部分にアクセスする history(tracecut) という述語を使って，過去のイベント情報（システムの状態？）をアスペクトの記述の基準にできる．

状態を保存する部分が自動化されていて便利だ，という主張ぽい．イベントベースのAOP，AspectJ などと比べて表現力，追跡性，拡張性，理解容易性が全部「高い」と言ってるあたりは少し「？」だが，個人的にはけっこうよさげな手法のように見える．うまくベースのイベントと切り分けられるものについては，AspectJ よりもうまくいきそう．

_ [論文]Pointcut のマッチの検査 ▲

Shriram Krishnamurthi, Kathi Fisler, Michael Greenberg:Verifying Aspect Advice Modularity.Proceedings of the 12th FSE (FSE2004), pp.137-146,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

基本的には pointcut をオートマトンと考えて（受理状態になると関連付けられたアドバイスが実行される），メソッド呼び出し列などのプログラムの状態に対してpointcut がいつ受理されるかどうかを判定しつつ，CTL によって記述した性質をテストするらしい．

使い道としては，pointcut の状態を見ることができるので，複数の類似した pointcut の性質の違いを調べたりするのに使えそうな気はするが…．

_ [論文]良い反例の出力 ▲

Sagar Chaki, Alex Groce, Ofer Strichman:Explaining Abstract Counterexamples.Proceedings of the 12th FSE (FSE2004), pp.73-82,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

モデル上でエラーとなるような反例を見つけて，実行が成功するような実行系列の例と「距離」が近いような実行系列の例として出力したいねという話．

一方の実行系列を他方へと変換するような基本操作の数が，実行系列間の距離となる．ここで，実行系列は，状態と，実行する命令の組の系列らしい．

発想はそのうち参考にすることになるかも?

_ [論文]動的解析による不変条件の推定 ▲

Jeff H. Perkins, Michael D. Ernst:Efficient Incremental Algorithms for Dynamic Detection of Likely Invariants.Proceedings of the 12th FSE (FSE2004), pp.23-32,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

実行時の各変数の状態から，不変条件を推定するという話．"Incremental" なのは，最初の実行で成立した条件を仮に全部不変条件だと思っておいて，反例が見つかった時点でそれを捨てていくというもの．

条件がプログラムのどの場所で成立しているかによって，広い範囲で成立する条件とその部分範囲でのみ成立する条件とをツリー階層で管理することで，反例が見つかった瞬間にツリー間で条件式を移動して，「条件が成立している範囲」の情報を調整する形になっている．

この論文の主旨としては Incremental なアルゴリズムに対して適用したいくつかの最適化方針に対してパフォーマンスを測ってみたというところ．

時間の単位が1000〜20000秒となっているので，実用かどうかというとちょっと怪しげな側面もあるが，重要な場所だけ絞って判定するとか工夫すればそれなりの結果は得られるのかな？と思わないこともない．ただ，サンプルが多くないと「そのテストケースでの不変条件」という微妙な出力を得ることになるので，使い道としては微妙か．

_ [Delphi][ツール]ボリューム調整デスクバー ▲

ちょっとほしくなったのでボリューム調整ができるデスクバーなんてものを作ってみた．ボリューム調整には，Vivasoft様のTMixerコンポーネントを使わせていただいている．

_ [OUCC] ボージョレ・ヌーヴォー ▲

今年はシャトー・ド・ブリュイザールのヴィラージュ・ヌーヴォーを飲んでみた．かなり当たりだと思える美味しさだった．ワイン飲むのが久しぶりだったのも効いてるかもしれない．

_ [AspectJ] 1.5M5 リリース ▲

着実に進んでいる様子（最初のスケジュールからは遅れているが）．

Load-Time Weaving の機能強化が進んでいるらしいが，有効な使い方がいまだによく分かってないので，ありがたみが湧かない．

_ [論文] プログラムの条件分岐を無理やり変更してデバッグ ▲

Xiangyu Zhang, Neelam Gupta, Rajiv Gupta: Locating Faults Through Automated Predicate Switching.

ICSE 2006, pp.272-281.

プログラム実行中のある時点でデータに誤りが発生した場合，それはそこまでの実行経路に問題がある．直前ないし近い位置の分岐で別方向に進んでいたらプログラムはうまく動いていたかもしれない．だから，そういう条件分岐（"critical predicate"）がもしあるのなら自動的に見つけよう，という論文です．

critical predicate が見つかれば，入力変数から critical predicate を経由して誤った変数値に到達するまでの経路の chopping を計算することで，バグの位置を普通のスライシングよりも絞れるだろうという見込みがあったりします．

方法自体はわりと単純で，動的解析でどの条件分岐を何回どちらに進んだかを記録しておき，コード書き換え技術を使って「このif文を20回目に通過するときは必ずTRUEだとみなす」というような細工を施してプログラムを再実行するというものです．どの条件分岐を変更するか，という選び方を工夫してます．

実験結果では，それなりに critical predicate を発見できていて（発見できないケースもあり），その結果を使って計算したスライスのサイズも小さくなっている，という評価を行っています．「デバッグの手間」というのは計測しにくいので，普通に計算したスライスのサイズと，critical predicate が分かっている場合のスライスのサイズを比較することで，開発者が調査するであろうコード量を比べています．

この手法は，ひたすらプログラムを再実行するという力技で，面白いやり方だなーと思います．特定の条件分岐を中身を気にせず強制変更するので，無造作にデータ構造を壊したりしないのか，という点は多少気になります．