netail.net

_ 新PC移行がほぼ完了 ▲

わりとつつがなく進行して一安心してます．ぼちぼち，ASE出張関連のことを書いていきます．

新PCでは，外付けUSBハードディスクが電力不足のせいか，接続してもカチカチと変な音を立てるだけで認識されない……．ディスク駆動用の外付け電源は持ってこなかったので，今後半年間，バックアップデバイスはSDカードとネットワーク上のどこぞのサーバとなりそうです．

_ [hyCalendar] hyCalendar 1.4.1 となる予定のバイナリ ▲

1.4.1バイナリのみを公開してみました．いちおうテストはしてるつもりですが，導入前のバックアップは必ず取ることをお勧めします．

変更点は次の５点です．

• 設定ダイアログの「状態の保存」欄に，起動時に開くタブの枚数を設定できるようになりました．最大で１年先まで自動で開けます．タブの枚数を増やすと，その分起動時は少し重くなるかもしれません．
• 日付メモに「追加貼り付け」機能が増えました．CTRL+SHIFT+Vで，日付メモの末尾にテキストを追加することができます．
• 起動時のプロセスの高速化を試みました．設定ダイアログなどのウィンドウを使う瞬間までロードしないようにしたので，今までより起動が少し速くなり，各ダイアログの初回の表示がその分遅くなっているかと思います．筆者の環境では，フルにロードすると16MB程度メモリを消費してますが，起動後，特にほかにダイアログを使わなかった場合，メモリ消費量は10MB程度にとどまります．高速化が体感できるかどうかは，環境に依存するかと思いますが．
• フリーメモの中のURLは自動でURLツールバーに項目として追加していたんですが，これをオプション設定（設定ダイアログの「ツールバー」タブ）にしました．さすがに機能ごと削ると誰かが困るかもしれないので，しばらくは残しておきます．
• 日付メモの最初の１行が空行であったとき，その空行がファイルを読み込んだときに消えてしまう問題を修正しました．

正式なリリースの日は，ドキュメント整備に時間をどれだけ割けるかに依存して決まります．例によって，すごく時間がかかるかもしれません．

_ bddbddbのドキュメント修正 ▲

bddbddbの使い方について，最新のソースはCVSじゃなくてSubversionで管理されている，と東大の青谷さんからご指摘いただいたのを反映しました．といって，単に注意書き足しただけなんですが．

bddbddb自体はタプルの集合（リレーション）をBDD形式で保存して，Datalog言語を使って操作するためのツールなので，Javaバイトコードから情報を取り出してbddbddbに変換するjoeqというツールの部分を作り変える（あるいは自作する）と，色々プログラム解析に使えると思います．

この手のlogic programmingの処理系を使ってデータ解析部分を手早く実装するというのがツール作る人たちの最近の流行な気がするので，１つくらいは使い方を知っておくと今後役立ちそうだという印象があります．

_ tex2textを更新 ▲

tex2text.rb スクリプトを，自分の博士論文の原稿が通る程度には直してみました．

多段階の \input{filename} を通るようになったり，エスケープされた "$" をちゃんと識別するようになったり，"section*" のような番号なしのセクションを処理するようになったりしています．

"-s" オプションが有効なときは「行末がピリオドで終わってたら改行する，そうでないなら空白１個で文をつなげる」というように改行を調整するようにしたので，Microsoft Word のスペルチェッカを少しは適用しやすくなったんではないかなーと思います．

_ [ツール] XTMemo のバグレポートを書いてみた ▲

ここ半年くらい愛用しているXTMemoのバグレポートをごそごそ書いて送ってみました．これで報告は２度目だったりします．

Changelogというただのテキストファイルを３ペインの軽快なGUIで見せる，というのが良いところだと思います．このソフトをインストールしてない別PCでもテキストエディタさえあれば普通に中身を読めるし，不足してる機能があっても他のテキスト操作ツール（grep，sed，ほか）が適用できるという安心感もかなり大きいような気がします．

未来のスケジュールはカレンダーで，詳しい内容はテーマ別に区切ったchangelogに記録していくというのが，今のところお気に入りのデータ管理です．

これからも開発がんばってほしいなあ（大変だろうけど……），と思うツールの１つです．

_ [論文] ASE 2006 の情報少しだけまとめ ▲

NIIでやってたASE2006は，参加者221人(うち本会議参加者は182人)，日本人が当然ながら最多で129人，USAから33人，ドイツから13人，フランスから12人．論文投稿数は121，うち22本がフルペーパー，17本がショートペーパー採録でした．フルペーパー採択率は18％．

個人的な印象としては，formal methods を使えるツールにしていこう，と努力してる人が目立った気がします．

便利そうなツールとしては，基調講演で紹介されていた仕様記述＆検証環境のCafeObj，Java などオブジェクトの要素をちゃんと扱ってコードのモデルチェックをしようというBogorあたりでしょうか．後者のほうは某先生が「授業で使おうかな」とか仰ってたくらいに良いもののようです（さすがにこの種のツールの良さはまだ自分では判断できないので伝聞形です）．

そのほかにも，ツールの使い勝手という側面では，コンパイラに組み込んだらどう？と Volanschi, N.: "A Portable Compiler-Integrated Approach to Permanent Checking" が提案していたり，ツール自体のカスタマイズを容易にするためにZ言語でコード量を小さく抑えてみた，と Ledru, Y. et al.: "Tobias-Z: An executable formal specification of a test generator" が言っていたりしました（Tobias 自体はテストケース生成ツールです）．

_ [論文] ASE 2006 でのアスペクト関連な話 ▲

ASE の formal methods 系に少し関連しそうな AOP 関連の発表としては，では，Falcarin, P. et al.: "Automated Reasoning on Aspects Interactions", Stoerzer, M. et al.: "Detecting Precedence-Related Advice Interference" の２本のショートペーパーがありました（他にはアスペクトマイニングの発表なんかもありました）．

前者はアドバイスが書くデータを読むアドバイスやメソッドが他にいるかどうかを調べて警告を出す，後者はアスペクトの動作順によって文間の依存関係が変わってしまうような場合に警告を出す，というツールの提案です．

どちらの手法も，「あるとちょっと嬉しい」というのは分かっても，本当にどのくらい役立つ事例があるのかはよく分かりません．現時点では世の中にあまり AspectJ プログラムが転がってるわけではないので（Stoerzer は実例は１個だけ知っていると言ってました），その辺は仕方ないかなと思います．

AOASIA の話は独立して長くなりそうなんでまた後日にします．

_ [お知らせ][hyCalendar] hyCalendar 1.4.1 リリース ▲

リリースしました．変更内容は先週書いたとおりです．

ヘルプのほうは大きなHTMLを多数に分割するなどして，色々直してみましたが，まだ厳しいかもしれません．

_ [論文] AOASIA2006関連その１：Obliviousness ▲

ぼちぼちAOASIA関連の話題を整理してます．この記事自体は，正確にはAOASIA前日の別ワークショップで話された内容です．とりあえず研究関連ってことで論文カテゴリに入れておきます．

Obliviousness というのは，「アスペクトを結合するコード（クラスなど）はアスペクトの存在を知らない」といった意味なのですが，これが「クラスのコードは，アスペクトのコードへの参照を含んではいけない」という構文レベルでの話なのか，「アスペクトがなくても動くようなコードを書く」「クラスの開発者はアスペクトの存在を知らなく良い？」とかいう意味的な話なのか，というところが実は曖昧でした．

結局，使ってる人によって意味合いが違っていたようで（おかげでだいぶ議論が混乱していましたが），ベースコード中ではアスペクトの要素を参照しないという構文的な意味が AOP においては必須の性質であろう，意味的な Obliviousness の達成は望ましいが必須ではない，という形で整理されました．

意味的な Obliviousness としては，たとえば性能計測のような完全に後付けのアスペクトは，Obliviousness を達成する必要がありそうです．また，クラスから見た場合，別アプリケーションで再利用したいクラス群というのはアスペクトがあってもなくても動く必要があるでしょうし，アプリケーション固有のクラスは，そのアプリケーション内にいるアスペクトのことを多少意識したコードになっていても問題ない気がします．今のところ，構文的な参照関係以上の明確な指針はありません．

_ [論文] AOASIA2006関連その２：Fluid AOP ▲

Gregor Kiczales のビデオ接続な Keynote Talk と Terry Hon の発表で，Fluid AOP について説明がありました（Hon, T. et al.: Fluid AOP Join Point Models）．

Gregor としては，アスペクトがやっていいことをコード上に明示してアスペクトの能力を制限するのは嬉しくないと思っていたりするようです．どうせほとんどの人は統合開発環境を使うんだから，賢い開発環境のサポート下でプログラムを書く，というのを目指しているようです．

Fluid AOP は，けっこう前にも別のところで論文出てた気がするんですが，プログラミング言語自体は普通のJavaなどを使用し，開発環境が必要に応じて（開発者が「ロギングのコードをいじりたい」というような作業ごとのポイントカットを定義して）該当するコードを発見し，それらのコード片を一括して修正するというアプローチです．

発想としては，「開発者ごとに取り扱うコードのかたまりは違うんだから，開発者が作業ごとに動的にモジュールを構成すればいいよね」といった感じです．過去にあった「ファイル単位にとらわれないソースコードビューを作りましょう」という研究に近いと思います．

今のところ，この手法は，特別なソースコードエディタとして実装されています．クエリに対してコード片集合を抜き出してきて，個々のコード片ごとに違う部分は obj.update***(x, ***) のように塗りつぶしてマージし，見かけ上単一のコード片として提示します．そして，そのコード片を開発者が書き換えると，実際にはポイントカットに該当しているすべてのコードがまとめて編集されます．

このアプローチは，保存結果はただのJavaファイルですし，コンパイラその他の道具も特に変わりません．言語を導入するよりも開発プロセスへの導入の敷居が低く，この環境で書いたコードの実行自体は既存のプラットフォーム上でできるという利点があります．個人的には好みだったりします．

安心して使うには，ちゃんと正しいポイントカットを書いて全部のコードを漏れなく変更しているのかどうかとか，何か他のサポートが必要になってきそうな気はします．しかし，現状，普通のエディタで検索＋全置換とかで多数のコード片を編集することを考えると（私が知らないだけかもしれませんが），実用上はそんなに困らないのかもしれません．

_ [論文] AOASIA2006関連その３：アスペクトの影響の解析 ▲

アスペクトを持ってきたらその影響がすぐ調べられる，というような開発支援環境ができたらうれしいなぁ，というようなことを Guenter Kniesel は言っていました．

アスペクトの影響を調べるというのでは，ワークショップのほうでは，アスペクトのウィービング後に成り立っているべき振る舞いを検証する COW （Shinotsuka, S. et al.: An Extensible Contract Verifier for AspectJ）が該当しているかと思います．私はなぜか weaver の実装が正しいことを検証するためのツールだと勘違いしていたのですが……．

うまく発展させれば，「ポイントカットが変なところにもマッチしている」とか，「アスペクト貼り付ける先のメソッドが，元々思っていたような振る舞いをしてなかった」というようなエラーを回避できるんではないかと思います．あんまりちゃんと論文読んでないんで嘘書いてるかもしれませんが．

アスペクトのウィービング前後で特定の性質が保存されていることを検証できるかどうか，というあたりの問題は，ウィービングもプログラム改変操作の一種だと考えれば，たとえばリファクタリング作業の結果プログラムを壊してないか調べるとかいった方面への適用（「動いてるコードは怖くて触れない」問題の軽減とか）もできそうで，実は大事なところなのかもしれない，と思います．道は遠そうなんですけど，まあ，何か思いつくようなら次回の AOSD あたりで誰かを捕まえます :)

_ [論文] AOASIA2006関連その４(最後)：余談 ▲

誰かの指摘やら何やら，適当にメモしたものの独立した文章にまとめるほどでもなかったので，とりあえずリストアップだけしときます．

• AOP のモジュール性などの特性についての議論を Awais Rashid が UML 2006 に投稿しているらしい．
• アスペクトって何？という高レベルのコンセプトが結局何なのか，まだ説明するのは難しそう．キラーアプリケーションはやっぱりロギング？
• アスペクトを導入したことで，設計段階で「意図」を表現しやすくなった．
• アスペクト指向は eXtreme Programming なんかに似ていて，手早く設計を表現するのに向いてる気がする．XPの結果分かったことは，設計をしなくて良いのではなく，設計を柔軟に変更できるようにするのが良いということで，設計は必要だった．
• 議論のやり方について，Guenter からもらったアドバイス: 「突っ込みどころを見つけたら，すぐに口を挟むんだ」(意訳)

お食事会のときはだいぶ人数減ってたものの，座ってたテーブルは賑やかでした．メニューにはアルファベット表記はまったくなかったんですが，同席してた東工大の柳澤さんが頑張ってくれたので助かりました :)

知らない言語に対するパターンマッチ能力の発揮というのはどこの人でも変わらないようで，「ここはビールの欄」と説明しただけで，「ビール／黒ビール／ハーフ＆ハーフ」の意味を類推したりしてたのはちょっと面白かったです．

_ visa RC1 を試してみた ▲

hyCalendarとVolumeDeskbarをテスト動作させてみるために，VMware PlayerにWindows Vista β2 をインストールするまとめのとおりにVMを作ってインストールしてみた．

オーディオデバイスは上記サイトの設定には書いてないので，以下のように追加してみた（VMWare Workstation で作った別VMの記述からコピーしてきた）．

sound.present = "TRUE"
sound.fileName = "-1"
sound.virtualDev = "es1371"
sound.autodetect = "TRUE"

シャットダウン時にブルースクリーンになったりする怪しさはあるものの，何とか動いた．

hyCalendarのほうは，全部をテストしたわけではないものの，いちおうある程度動作しているみたい．拡張子の関連付けだけ，「管理者として実行」しないと失敗した（Volume DeskbarのDLL登録は普通にできた）．

Windows Vista では，ボリュームコントロール自体が，このスクリーンショット(png)のように，アプリごとの音量を一緒に表示されように変わっていたりする．VolumeDeskbar で音量をいじっても，「アプリケーションごとの音量設定」だけが変化して，Windowsの持つスピーカーの音量を調整できなかった．こちらは使っているコンポーネント依存なので，今のところどうしようもない．

_ [ツール][Java] soot の points-to set 解析設定 ▲

jEdit のようなGUI・スレッドをがりがり使ってるアプリケーションを解析するときは，-p cg verbose:true,jdkver:4,safe-forname:true,safe-newinstance:trueあたりのオプションを付け加えてやらないと，うまくコールグラフができず，GUI関連のコードに対してまったく points-to set が生成されない，ということになってしまうようです．

points-to set 解析には，Paddle よりも高速かつクラッシュしない Spark のほうが，現時点では良いようです（-p cg.spark verbose:true,enabled:true）．また-p cg.spark propagator:iterオプションを追加すると，標準設定（propagator:worklist）と結果が変わります．worklist では一部 points-to set が計算できない場所があるようです．iter による反復処理の結果が，worklistの結果と包含関係にあるかどうかは分かりません．

_ [VolumeDeskbar][お知らせ] VolumeDeskbar 1.0.12 リリース ▲

リリースといっても，前バージョンからの変更は「枠を表示しない」オプションを追加しただけです．

標準では白い枠が消せます．そのぶん，音量バーが若干太く表示されます．

_ [論文] イベントを記録／再生してデバッグ ▲

Alessandro Orso, Shrinivas Joshi, Martin Burger, Andreas Zeller: Isolating Relevant Component Interactions with JINSI.

Proceedings of WODA 2006, pp.3-9.

プログラムの動作が失敗する場合に，コンポーネントレベルでのイベントを記録しておいて後から再生することで，デバッグを行う環境を作ろうと提案している．

注目する特定のコンポーネントに対して「境界」を越えるコンストラクタ呼び出し，メソッド呼び出しと戻り，フィールド操作を記録する．このときに，引数や外部メソッドからの戻り値などのプリミティブは全部値まで覚えておく，また，境界を越えない内部呼び出しなんかは無視するみたい．

で，その対象コンポーネントの周辺をすべてモックに差し替え，記録した外部とのやりとりを再生すれば，そのコンポーネントだけを独立してテストできる．この「再生」処理は完全に自動化できるので，delta-debuggingを適用し，問題が発生するような短いメソッド呼び出し列を探索する．

観測するのはあくまで境界を出入りする呼び出しなどだけなので，観測対象はコンポーネント単独でなく，特定のサブシステムなどの単位でも利用できる，とも述べている．一方で，外部からのメソッド呼び出し回数などは減らせるが，そのコンポーネント内部の処理量は減らせない（処理が多いコンポーネントのデバッグはこれでも大変かもしれない），リアルタイム系の処理は再現できない，といった弱点はあるし，コンポーネントの観測境界をどう適切に設置するかというのも難しいかもしれない．

個人的にはかなり良い印象のアプローチで，「プログラムの実行履歴データを全部保存するぞ」というomniscent debuggingよりはだいぶ現実的だという印象がある．それに，彼らが過去に提案している delta-debugging の制約（入力がプログラムから制御可能で，結果の成功失敗が判定可能とか）をうまく満たせるような状況に持ち込んでるのは，やり方としてうまいと思う．

気になる弱点(?)は，特定のコンポーネントを怪しいとにらんで動作記録をとったときに，「なぜその入力が来たのか」を調べようとすると，境界を再設定してデータ取り直しという，大変な作業が待っていそう，というあたり．

今後どうなるかはけっこう楽しみ．

_ 最近のお知らせを上に出すようにしてみました ▲

フリーソフト系なリンクでたどってくる人が多いと思うので，リリース関連情報を探しやすいようにと作ってみました．

tdiary のプラグインである category.rb をいじって，特定カテゴリの最新記事のリストを作っています．カテゴリ名をクリックすると表示される記事一覧の最新３つだけを出力しています．

実装は category_list_sections をかなり単純化したものです．コードはこちら（改造したところだけ抜粋しています）．やっつけ仕事なのでコードは適当です．カテゴリごとの記事一覧のときだけ使われる categorize 処理を毎回呼び出すようになってるので，効率は少し悪いかもしれません．

_ [論文] プログラム実行履歴からオブジェクトのステート図を抽出する ▲

Valentin Dallmeier, Christian Lindig, Andrzej Wasylkowski, Andreas Zeller: Mining Object Behavior with ADABU.

Proceedings of WODA 2006, pp.17-23.

状態遷移はメソッド呼び出しによって引き起こされるのだから，メソッド呼び出しによってラベル付けされる状態遷移図を実行履歴から抽出してしまおう，という論文．

状態遷移のラベルは状態変更を起こすメソッド群（mutator）とする一方で，状態のほうは状態監視用のメソッド群（inspector）の戻り値によって定義している．inspector メソッドの条件は，引数なし，戻り値が void で，副作用を持たないこと．

プログラムの監視方式はかなり単純．mutetaor メソッドの中身をすべてtry-finallyでくくって，finallyの中でinspectorをすべて呼び出し状態を記録している．

inspector によって int 型などを返されると状態数が大変なことになるので，整数値の範囲などを抽出して（dynamic invariant detection などの手法），abstract state として状態数を減らして，それらを mutator メソッドで接続することでモデルを作成する．

動的抽出なので，モデル上に，何回その遷移が起きたかを表示することで，一般的なパスとそうでないパスを明示したりできる．

関連研究としてはインタフェース抽出，dynamic invariant detection 他．けっこう挙げられているので，文献読みの基点としてもよさそう．

監視用のメソッドがある程度用意されていないと動かないかなとも思ったけれど，AspectJのインタータイプ宣言とかを使って監視用インタフェースを勝手に追加して，データ記録もアスペクトとして実装すれば，けっこう簡単に既存システムに組み込んで使えそう．状態の抽象化部分を何とか実装できればという条件付きだけど．

_ [お知らせ][hyCalendar] hyCalendar 1.5 β版テスト中 ▲

1.5.0のβ版バイナリを作ってみました．今回，新機能として「〜まであと何日」という日数のカウントダウン機能を追加していますので，それについてちょっとご意見をいただけると嬉しいなと思っています．

例によってファイル形式が拡張されているので，試される場合は，必ずデータファイルのバックアップは取っておいてください．

メニューの[カレンダー]-[日付カウントダウンの設定]から，特定の日あるいは周期予定を選んで「追加」ボタンを押すことでカウントダウン項目を作成できます．カウンタの値は，ステータスバー（ウィンドウの一番下）に表示されます．

今のところ，設定としては，その日が近づくまでは（デフォルトで100日）カウンタを表示しないという項目ぐらいしかありません．他に設定可能な項目がほしい方はこの記事に「ツッコミを入れる」なり掲示板なりメールなりでご意見をいただけると幸いです．

それから，このβ版には，掲示板でご指摘いただいた「この日を周期予定から除く」機能に関する問題の修正と，期間予定の左右端の矢印をなしにできるという機能も入ってます（期間予定ダイアログに，左右端の形状を指定する項目が増えてます）．

ちゃんとドキュメントまで整備したリリースは，作業時間をどれだけ取れるかに依存しますが，11月後半〜12月前半になるかと思います．

_ [お知らせ][hyCalendar] hyCalendar 1.4.2 リリース ▲

タスクバーに格納された状態のままウィンドウを閉じたとき（右クリックから「閉じる」を選ぶか，タスクマネージャから「タスクの終了」を指定されたとき）に，ファイルの保存確認あるいは自動保存が実行されない問題を修正しました．また，「この日を周期予定に追加する」メニューの使用後に表示が更新されない問題を修正しました．ダウンロードはこちらから．

1.5 β版のバイナリも，上記の修正を加えたものに置換してあります．

(10月31日追記) タスクバーに格納されてない状態でタスクバーの項目を右クリックして閉じるとやっぱりファイル保存ができない，との指摘を受け，1.4.2a としてアーカイブファイルを差し替えてました．

_ [近況] サマータイムが終わりました ▲

１時間時計が巻き戻ったので，日本との時差は１７時間になりました．