netail.net

_ [論文] デバッグ用のスクリプト ▲

Guillaume Marceau, Gregory H. Cooper, Shriram Krishnamurthi, Steven P. Reiss:A Dataflow Language for Scriptable Debugging. Proceedings of ASE 2004, pp.218-227.

なんでデータフロー言語という名前が付いてるのだろう，というのがふと気になって前に読んだのをもう一度読み直した．

FrTimeという scheme 系の言語でプログラムの状態を監視し，制約検査を行うのだが，FrTime は，プログラム内部の状態変数に対して， その値を常に反映するような変数を定義することができるらしい（AspectJのargsやthisなどはその時点での値にアクセスできるだけなので，だいぶ意味合いが違う）．で，この変数を使うと，プログラムの状態を常に反映した条件式が書けるので，プログラムが何らかの制約違反を起こした場合に即座に検知することができる．

"dataflow language" というのは，プログラム中のデータが，検査式に直接接続されているという意味合いで，他の言語などで，情報集めのための文をあちこちに埋め込む必要がなくて嬉しい，とかいう話らしい．

_ [論文]プログラム中の実行パスの表現 ▲

B. Bruegge and P. Hibbard. Generalized path expressions: A high level debugging mechanism.

In Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on High-level Debugging, pages 34-44, 1983.

プログラムのパスを正規表現に近い形で記述し，そのとおりにプログラムが動いているかどうかをテストする． 呼び出されうるメソッドの列なんかを正規表現とかオートマトンとかで書くこと自体は（今となっては）そんなに珍しくないのだが，これはwhile文とかまで記述対象にできるところが面白い．

CHECKPATH Loop {WhlleLoop[ACT(Whileloop) < 6] | PlaceLines}

という記述を行うと，PlaceLinesメソッドが呼ばれるまでは while 文のループが６回以上起きてはいけない，とかいった条件になる．検出する条件自体はブレークポイントのループカウント＋条件付ブレークポイントで普通に実現可能な機能かもしれないが，記法は何かに使えるかも？

_ スタイルシートをちょっとだけ変更 ▲

zaurus搭載のNetFrontからだとページが崩れていたので，修正．サイドバーがポジショニングのabsoluteで右側に固定されていたのを，floating を使って本文を左側に，サイドバーを右側に移動するようにした．

_ [hyCalendar] スタートアップ時の起動エラーへの対処 ▲

hyCalendar は WndProc 内で Screen.ActiveWindow にアクセスしているが，Windows XP での起動直後は Screen.ActiveWindow = nil になることがあって，それで起動時にエラーが起きていた様子．

とりあえず修正版を公開．他に追加する機能がまだあるので 1.3.1 リリースまでまだ少し時間がかかりそう．

_ [Delphi] pas2dox ▲

Delphiでドキュメント生成系のツールがないのかと思ってたら，実はpas2dox という Delphi から Doxygen 用入力を生成するためのツールがあるらしい．そのうち試してみることにする．

_ [Delphi] pas2dox 試してみた ▲

出力結果はあまり使えそうとは思えなかった．pas2dox 自体は *.pas に対応した C++ コードらしきものを生成するのだけど，文法的には当然厳密な C++ コードなわけがなく，doxygen 側が，ただの関数呼び出しを関数宣言と誤解したりして，怪しい生成結果となってしまう．

_ 研究室の来客 ▲

Bashar Nuseibeh, Jeff Kramer, Anthony Finksletein という３人が来訪．Requirement と Architecture の間の関連性とか，XMLの中のデータ一貫性制約を記述するxlinkitとか，たぶんどこかで聞いたことがある（図に見覚えのある）話を聞いた．

コードクローンの検出に使うCCFinderの "識別子をシンボル化した" トークン列が，コード自体ではないので公開しても差し支えなく，しかもライセンス上同一であっては困るコードと比較できる signature として使えるだろう，という指摘があった．トークン列の使い道としては面白いところかもしれない．

_ [論文] 副作用のないメソッドの自動検出 ▲

Alexandru Salcianu and Martin Rinard: Purity and Side Effect Analysis for Java Programs.

Proceedings of the 6th International Conference on Verification, Model Checking and Abstract Interpretation. Paris, France January 2005.

外部に副作用を残さないメソッドを JML などでは pure メソッドと呼んで，アサーションの定義に使えるようにしているが，@pure の指定は手作業になる．それを自動的に検出する方法を提案している．既存の研究と異なる点は，メソッド内で新しいオブジェクトを確保したとき（一時使用のイテレータなど），そのオブジェクトに対するデータの書き込みは許容するところ．

各メソッドごとにどの変数がどのオブジェクトを指すかを示す Points-To グラフを構築しておき，メソッド呼び出し関係をたどるときに呼び出し側の Points-To グラフのノードと，呼び出し先のグラフとで，対応する引数やthis参照を接続することで，呼び出し先まで含んだ解析グラフにしていくらしい．末端にnativeメソッドが入ってしまうと解析できないので，いくつかには手であらかじめ定義したグラフを与えている．

_ 皮膚科 ▲

背中にあった1cmくらいのほくろから出血があったので，蛍池駅前の奥野皮膚科まで出かけてきた．てきぱきと診察されて，液体窒素らしきものでほくろの部分を焼かれる．けっこう痛い．

_ [work]コールグラフのサイズ ▲

開発用の小道具として使えるかな？と思って，クラスを指定したら，そのクラスから参照しているクラスも全部見つけてきてコールグラフを作ってくれるようなプログラムを作ってみた．

Main クラスを指定してみると，47クラスのプログラムに対して，約25000頂点のコールグラフが生成されてしまった．java. とか javax. とかがやたら多く，全部除去しても500頂点くらいで，Graphviz レイアウトでは既に人間が取り扱えないサイズ．Eclipse の呼び出し階層ビュー（素直なツリー形式）がいかに無難かよく分かる．呼び出し元へたどっていくか，呼び出す先へたどっていくか，同時にはどちらかしか使えないが……．

_ [Java][ツール] プリミティブ型を格納するコレクションライブラリ ▲

各種調べてみたので少し整理．Javaでは，autoboxing はパフォーマンス上のオーバーヘッドが大きいので，たくさん要素を処理する場合はこれらのコレクションが有効（なはず）．

• GNU Trove for Java: http://trove4j.sourceforge.net/

int や boolean など，各プリミティブに対する List, Set, Map, Iterator を提供するパッケージ．

コレクションの各要素に対して手続きを呼び出す foreach が利用可能．また，任意の型から int への Map については，int→int変換をかけて別の Map に変換する transformValues というメソッドもある．

Java Collections API との互換性を保つための Decorator も提供（ただし効率は悪い）．ライセンスはLGPL．

• Primitive Collections for Java: http://pcj.sourceforge.net/

Troveと同様，各プリミティブに対するList，Set，Map，Iteratorを提供するが，それに加えてSortedSet，範囲型(Range)なども提供．

ハッシュの実装を Chained (ハッシュ結果が Linked Listになっているもの)と Open (ハッシュ結果のエントリが埋まっていたら他にさらに移動するもの)から選択する必要があり，選べて嬉しいともいえるし，いちいち選択するのは面倒ともいえる．

Java Collections API との互換性を保つための Adapter も提供．ライセンスはLGPL．

Trove4Jと比べた場合，こちらだけが提供するSortedSetなどを使いたいか，それとも Trove4J だけが持つ foreach などが使いたいか，によってどちらを選ぶかが決まりそう．

• The Colt Distribution: Open Source Libraries for High Performance Scientific and Technical Computing in Java: http://hoschek.home.cern.ch/hoschek/colt/index.htm

主に int と double に関する配列・行列処理用クラス群．事前条件をチェックしない setQuick などの高速処理用メソッドを持つ．

その他，複素数，行列演算，様々な分布の乱数生成などのパッケージもくっついている．

ライセンスはパッケージごとに異なっており，ほとんどは非商用なら利用可能．一部 Mutex などを提供するパッケージのみ GPL になっている様子．

• Type-Specific Collections Library: http://www.sosnoski.com/opensrc/tclib/

array, queue, stack, set, map をサポート．array は，主に配列との相互変換を重視している．

short や long などはサポートしていないコレクションもあり，また全体的にメソッド数も少ない（add と get での利用が基本のよう）．

機能が少ないぶんシンプル（目的のものを探すのが容易）なパッケージだと思われる．ライセンスは独自で，基本的には自由にしてくれというもの．

_ [ゲーム] ドラクエ３のクリア画像置き場 ▲

Ｄ論作成モードに入る前に，ドラクエ３情報を整理．

_ [hyCalendar] 1.3.1 リリース ▲

バイナリを作った後，ファイルのアップロードを忘れていた(!)ので，リリース．

_ [work] LaTeX の \input ▲

英語でＤ論を書くべく英語原稿を整理していて，各セクションごとにサブディレクトリを作って \input を使ってファイルを読み込むようにしてみた．

このとき，読み込まれる側のファイル中での相対パスは，読み込む側のファイルのディレクトリを基点に計算されるようで，図のepsを固めたfigディレクトリの参照部分を全部書き換える必要があった．

図を格納したディレクトリを一箇所にまとめるという手でもいいのかもしれないが，どっちがいいのかは微妙なところ．

_ [hyCalendar] 1.3.2 リリース． ▲

バグが１件，1.3.1 で見つかったので修正してリリース．

単に Copy(string, index, length) の呼び出しで Copy(string, index+1, length) になってただけなので，修正自体は一瞬だった．DUnitとかちゃんと使っていれば事前に防げたバグなだけに，少し悲しい．

次の機能拡張を入れる前に，一度DUnitのテストを追加してコード整理しないとなー，と思う．iCalendarオブジェクトをhyCalendar上にマップする方法についての調査もそろそろ始めておきたいところ．

_ [OUCC][ゲーム]ドラゴンクエスト３（ファミコン版）勇者１人でのバラモス退治 ▲

ドラクエ３の勇者１人旅でのバラモスの倒し方が Nelcy＠OUCC らによって確認された．

レベルが60超えてもHPが足りないので（409で成長が止まった），サマンオサでクマとサルを相手に修行することがポイント．グリズリーがちからのたね，コングがいのちのきのみを１時間〜２時間に１個くらいは落とすので，それを集めて，HPが459，ちからが206となった時点で初めて倒せた．

このときレベルは74，MPは256．すばやさはほしふるうでわつきで255．レベルアップごとに，MPが3〜4伸びるまではリセット．ちからのたねは3，いのちのきのみは5が出るまで同様にねばる．

マホトーンで呪文を封じ，くさなぎの剣で守備を 0 まで下げてから，本格的に戦闘開始．攻撃３回→ベホマの繰り返しでダメージを累積させられるかどうかが勝利できるかどうかに直接影響する．攻撃３回で，420〜480程度のダメージを与えられれば，自動回復４ターン分の400を差し引いても，20〜80程度累積させることができる．で，蓄積した値の記録を取りながら戦い，蓄積ダメージが0に戻るようなら一度仕切りなおし．会心の一撃が出て，ダメージがある程度乗ってきたら，あとはギガデインの連打で決着をはかる．

バラモスはHP900，自動回復が100．バラモスからの攻撃は，マホトーンを使って魔法を封じると，攻撃２回→炎＋攻撃→攻撃＋炎の繰り返しになり，ドラゴンメイルを着ると１ターンに100〜130程度の範囲で分布する．HPが480程度あれば，３回攻撃→回復のリズムをほぼ確実に保てるので，確実に勝利できると思われる．

ちなみに，勝利時のダメージ数値列は以下の通り．

136, 122, 163, ベホマ, 172, 131, 163, ベホマ, 
251(会心), 282(会心), 127, ベホマ, 
199(ギガデイン), 219(ギガデイン), 186(ギガデイン), ベホマ,
181(ギガデイン), 208(ギガデイン), 214(ギガデイン) →勝利

詳細の写真（ステータスやら退治した瞬間など）いくつかはこちら．

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

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

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

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

_ [AspectJ] 1.5M5 リリース ▲

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

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

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

ボリューム調整デスクバーを更新した．変化は最低サイズの設定が可能になったことと，右クリックで設定ダイアログの呼び出しと，ミュートの指定ができるようになったこと．ボリュームコントロールをいちいちクリックせずにすぐにボリュームを調整したい人向け．

iniファイルの位置は，ちゃんと DLL ファイルと同じ位置に出力するようにしている．いちおう COM コンポーネントなので，ComServer.ServerFileName を使って取得している．

_ [Delphi]黄色がデフォルトの透過色？ ▲

Delphi 7 で TForm の TransparentColor プロパティを True にすると，TransparentColorValue プロパティが clBtnFace なのに，黄色(clYellow)で透過が発生する．基準がよく分からない．とりあえず，TransparentColor を False にしておく．

_ [ツール] ActiveX DLL/EXE のインストール補助ツール ▲

Volume Deskbarを公開したものの，ActiveX を regsvr32 で登録する手続きは敷居が高いという指摘を受けて，OCX Setup というツールを再配布させていただくことにした．

Vector の「インストーラ」カテゴリにいくつか似たようなツールはあったのだが，ランタイムライブラリが不要であること，インタフェースが比較的単純（登録するファイルを選んでOKを押すだけ）であることから選択した．

_ [OUCC][ゲーム]ゾーマ１人撃破の巻 ▲

ドラクエ３ バラモスと踊るにゾーマ退治時の画像を追加．

戦法はバラモスのときよりも単純で，ひかりのたま使用後，ベホマで攻撃・回復をひたすら繰り返し．いのりのゆびわでMPを全快してから戦闘開始で，あとは運（相手が威力の低い吹雪やいてつく波動を何回使ってくれるか）がかなり影響する．物理攻撃が一番ダメージが大きいので，はんにゃのめんを装備すると圧倒的に楽になることは確認されたが，以下のデータでは使用していない．

HPが足りなかったのでやっぱりサマンオサでサルを相手に修行し，レベルも上げてMPを上げておく必要はあった．

いちおうダメージ値の列のメモをもらったので以下に掲載．ゾーマのHPは1000，自動回復100．はんにゃのめんを装備すると，回復のサイクルがだいぶ長くなり，戦闘時間を大きく短縮できる．

152, 152, 161,   0, 168, 148, 179,   0, 166, 170, 145, 171,   0,
151, 172, 154, 149,   0, 167, 169, 159,   0, 145, 145, 158, 177,
  0, 160, 162, 170, 176, 164 (撃破)

_ [論文] プログラム変換を使ったスライシング ▲

M. P. Ward, H. Zedan, and T. Hardcastle:

Conditioned Semantic Slicing via Abstraction and Refinement in FermaT.

Proceedings of 9th European Conference on Software Maintenance and Reengineering (CSMR 2005), pp.178-187, March 2005.

スライス基点として選択された変数集合に影響を与える文以外を削除する．if-(cond)-then-else を ((cond and then) or (not cond and else)) に置き換えるとか，入力時に，いくつかの変数の値域を指定することでその値を簡約化するといった変換操作をして出力を決定している様子．

_ [論文] クラスのフィーチャ固有／インフラ担当の分類 ▲

Orla Greevy and Stephane Ducasse: Characterizing the Functional Roles of Classes and Methods by Analyzing Feature Traces.

Proceedings of 6th Workshop on Object-Oriented Reengineering 2005.

ユーザが起動できる操作（主に，GUIから実行する各メニューの操作など）ひとつひとつを feature と呼び，それぞれについて実行履歴を取った結果を feature traces と呼ぶ．

feature traces に登場するクラス群を分析したとき，１つのfeatureにしか登場しないものを single feature，複数に登場するものを group feature，半分以上のfeatureに登場するものを infrastructural と分類することで，クラス群を分類して理解しようとしている．

feature の集合が，プログラムの全機能を完全にカバーしなくても，feature location 的な使い方には十分だろう，と書いている．また，手法自体は単純なので，スケーラビリティは高そう．

fan-in analysis で呼び出し元が多いものをアスペクトにしよう，という発想の研究に似ている気がする．

また，著者の人のページにあるほかの文献の abstract とかを見てたら，Latent Semantic Indexing (LSI) を適用したとか，他にも色々分析して論文を書いてる様子．

_ [読書][AspectJ] アスペクト指向入門 ▲

千葉先生の本が出ていたと聞いて買ってみた．ちょうどアスペクト指向の授業を終えたところなので，タイミング的には少し遅かったけれど．「アスペクト指向は呼ぶ側のモジュールを再利用するための技術」という説明のしかたをしている部分は，そういう言い方もあるのね，とちょっと感心した．

アスペクト（アドバイス）間の干渉の問題についても少し触れられていたけれど，この問題は，実用性に影響を与えているというよりも，開発者にとっての「書いたプログラムがどういう順序で動くか良く分からないのは気持ち悪い」という心理的影響が大きい気がするこの頃．

アスペクトの Obliviousness によってクラス側にアスペクトのコードがまったく入らない気持ち悪さも，これに似ているかもしれない．アスペクトに書かれた処理を呼び出すためだけの不自然な文を入れるとかいった愉快なプログラマがいなければ，調査用のツールさえ一緒に使えれば大丈夫な気はする．オブジェクト指向でも，Delphi の一部のコンポーネントとか，Active := true; という代入文で，実はActive というのは手続きが関連付けられたプロパティなので処理が実行されるとかいうことがあるし．そういう言語仕様が元々ない Java の世界だから気にかかる度合いが強いのかもしれない．

_ [論文]コードクローン技術を使ったアスペクトマイニングの実験 ▲

Magiel Bruntink, Arie van Deursen, Remco van Engelen, and Tom Tourwe: On the Use of Clone Detection for Identifying Crosscutting Concern Code.

IEEE Transactions on Software Engineering, Vol.31, No.10, pp.804-818, October 2005.

横断的関心事の中には，モジュール化機構が存在しないから仕方なくあちこちに同じ実装をばらまいてしまっているものがあるはずだ，という仮定に基づいて，コードクローン検出ツール３つを使って，本当に見つけられるかどうかを実験している．

各関心事をあらかじめコード中に見つけておいて，クローン検出で出てきたものとつき合わせる．関心事もクローンも，プログラム行の集合ととらえて，手でマークをつけた行のうちどれだけがクローンに入っていたかで再現率・正確性を評価している．ただし，いくつのクローンを調べるかで，クローンとして検出されたクラス群のうち，正確性の向上に一番貢献するものから優先的に（greedy に）k個選び出している．

この選択のやり方でアスペクトを探した場合，手でマークをつけた情報に依存して正確性が決まっているので，マークがないコードに対するアスペクトマイニングでは，この性能を超えることはないだろう，と言及されている．マークつきでもログ記録は60％程度，エラー処理は40％程度しか見つけられない，という情報が，自動的なアスペクトマイニングの性能がどのくらい良いのか悪いのかを考える指標にはなりそう（ログ記録とエラー処理のどちらが相手かで，30％のコードを発見した，の意味合いがかなり変わる）．

_ [論文] feature trace をリビジョンごとに作る ▲

Orla Greevy, Stephane Ducasse and Tudor Girba: Analyzing Feature Traces to Incorporate the Semantics of Change in Software Evolution Analysis.

Proceedings of ICSM 2005, pp.347-356.

どのクラスがいくつのフィーチャーに参加しているかを not covered/single/group/infrastructural に分類するが，バージョン間での変化量を使って，機能の追加とか削除を識別しようという試み．

単純には，直前の変更で参加するフィーチャー数が増えてカテゴリが変わったならactivity をプラスに，減ってカテゴリを移動したならマイナスに，not covered に移動したら 0 にする．で，プラスなら新機能の追加か再利用が発生しており，マイナスなら機能が削られている可能性が高く，0なら obsolete になっている，といった判断をする．

実行してトレースをとって，特定のフィーチャー集合についての分析なので，クラスのカテゴリが変わるというのは非機能的要求の追加・削除が影響しているだろうと考えている様子．もちろん，実行で一度も触れられなかったクラス群に対しては何の評価も下すことはない．

カテゴリにランク値を与えて（not covered を0として始めて，infraが3）平均値とか今までの変化量の総和とかも計算しているのだが，変化量が 0 より大とか，今のところ，単純なフィルタとしての使い方しかしていない様子．

_ [OUCC][ゲーム]部室のスマブラDX ▲

対戦回数１万回を突破，「猛烈にやりこんでいます」のお知らせが出現した．2001年11月21日開始なので，購入から４年と３日間かかったことになる．

_ 再び皮膚科へ ▲

背中のほくろ（前回焼いて回復した痕，前より少し小さくなった）をもう一回液体窒素らしきもので焼かれる．これでまたしばらく仰向けで眠れないが，切除するとかいった方法よりは，入浴その他に支障がないという点で良い方法らしい．

_ [論文] 状態に基づくJoin Point Model ▲

Noorazean Mohd Ali, Awais Rashid: A State-based Join Point Model for AOP.

Proceedings of Workshop on Views, Aspects and Roles (VAR) (held with ECOOP 2005).

オブジェクトの状態変数に基づいて状態機械をモデル化し，状態遷移に対してアスペクトを定義しよう，という提案．オブジェクトの具体的な変数値と状態機械を対応付けるモデリングのためのアスペクトと，その状態遷移に対してアドバイスを関連付けるアスペクトを組み合わせて使う．アドバイスとしては，特定の状態遷移や，状態遷移の列（transition flow）への対応が可能としている．

event-based でのメソッド呼び出し列を状態遷移としたオートマトンを構築する試みとの違いとしては，複数のメソッド呼び出しによるデータ操作などイベント列では定義しにくい状態遷移をうまく表現できる可能性がある．

メソッド呼び出し列による状態遷移の定義で作った状態遷移モデル＋JML などを使った事前条件や事後条件としての変数値の状態の指定と，このデータによって定義された状態遷移モデルとを付き合わせると，ちょっとした比較ができるような気がする（できてどうなるかは不明だけど）．

_ [論文] アスペクトの単体テスト ▲

Cristina Videira Lopes and Trung Chi Ngo: Unit-Testing Aspectual Behavior.

ISSRE 2005 Workshop on Testing Aspect-Oriented Programs.

アドバイスのテストについての Position Paper．題材には Jaml という，アドバイスの中身をクラスとして書いて，結合には XML を使うという言語を使っている．

テスト方法としては，MockJoinPoint という Join Point の中身を作成し，それをアドバイスに渡して実行するだけ．利点は，JUnit に親しい開発者なら簡単に導入できることと，おおげさな仕組みが必要ないこと．

これに対する問題点は，与える MockJoinPoint が本当にそのアドバイスを実行するのに適切でないといけないこと，コンテキストとして適切なオブジェクト（this や target）を設定すること．どういう join point をテストケースとして用意すると嬉しいかは実験が必要だろうし，依存関係解析などでコンテキストをある程度自動的に作るとかいった方法があるだろう，と述べている．

また，AspectJ では，アスペクトの振る舞いを独立した実行コードとして実現できない（あちこちに weave されるという形でしかコードが現れない）のでアスペクトの振る舞いをテストしにくい，ということも指摘している．