netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2005-09-02 [長年日記] ▲
_ [work]ポルトガル語・英語の辞書 ▲
FSE開催地の大学のWebページがポルトガル語しかないようなので,Ultralingua というオンライン辞書を見つけてきた.発音の情報もほしいなーと調べてたらポルトガル語であいさつという静岡県のページを発見.これで少しは地名が読める,かも?
2005-09-11 [長年日記] ▲
_ 帰ってきました ▲
選挙の投票やら部屋の掃除やらpukiwiki.orgドメイン失効に伴うpukiwiki.sourceforge.jpへのリンク張り替えやら,やることはけっこう色々.
IWPSE/FSEの発表では,面白い発表もけっこうあったので,後日,まとめることにする.写真の整理もあるし.
2005-09-13 [長年日記] ▲
_ Program Evolution ▲
IWPSEで,ERCIM Working Group on Software Evolutionの人たちが,M.M. Lehman, L.A. Belady: Program Evolution という20年くらい前の本をコミュニティに提供しまっせ,と言っていた.
[Publications]の欄にPDFが置かれているのだけど,555ページ(!)あるので,読むのはけっこう大変そう.
_ IWPSE Keynote Talk メモ ▲
Keynote は "Does Software Evolve ?" というタイトルで,Mehdi Jazayeri という人がしゃべっていた.
コードはソフトウェアのモデルの一部にすぎず,ユーザの要求との対応などの情報も含んでいないと完全とはならない,と言っていたのが印象的.最後あたりのスライドに"Software is more than source code; models and meta-models are important to software evolution. Individual software products age; our understanding of them evolves." とかスライドに書いてあったような気がする(適当にメモを取っただけなので違っているかも).
研究の方向性その1としては,ソフトウェア進化を起こす要因について: (1)それらはproduct-/domain-/architecture-specificなのかどうか (2)それをどう識別(identify)するか (3)それらをどう記録(record)するか (4)それらがどうモデルやコードと関係するか,の調査.
例としては,open-source vs closed source (Godfrey; Walt Scacchi) や systems vs subsystems (Gall et al.) といった比較の研究が挙げられていた.それによって得られるであろう成果としては,どこが stable でどこが changing な場所か分かるようになる(その結果,ソフトウェアのモジュール構成などにも影響するかもしれない)といったことが考えられる.
研究の方向性その2としては,コンポーネントの役割(role)について: (1)コンポーネントが単独で更新されるのか,複数のコンポーネントが一緒に変化していくのか(たとえばRepository Miningによる調査) (2)何かコンポーネントモデルがその変化を支援できるのか(Component model portability とか).現在行われている研究で関連するものとしては, Retrospective analysis (validating the architect's claims),empirical validation of theories,model evolution,mining repositories (with surprising implications) などが挙げられていた.
_ [論文]IWPSE セッションメモ1 ▲
興味の引いた論文だけいくつかピックアップ.基本的にプレゼン聞いたことベースで書いてるので,論文の内容はあとでチェックしてみないといけない.
- Tom Mens: Challenges in Software Evolution.
過去の研究18本を,時間・目的・利害関係者といった軸で分類して整理したサーベイ系の論文.
- Giuliano Antoniol, Vincenzo Fabio Rollo, Gabriele Venturi: Detecting groups of co-changing files in CVS repositories.
「ほぼ同時に変更される」ソフトウェア部品の集合を取り出したい,という研究.このタイプの研究,最近よく聞くような気がする.変更回数を曲線として取り出したとき,2つの曲線の近さをwarp differenceという基準で評価している.
- Lerina Aversano, Marcello Bruno, Massimiliano Di Penta, Amedeo Falanga, Rita Scognamiglio: Visualizing the evolution of Web Services using Formal Concept Analysis.
Webサービスを利用しようとするとき,zipcode→zipcode2 といったようにサービスが変更されたとき,そのサービスの内容がどう変化したかを Concept Lattice を使って評価しましょう,という論文.
インタフェースのドキュメントなどから Concept Lattice を作っておいて,それがサービス追加の前後でどう構造が変わったか(新サービスが古いサービスをカバーしていると,新サービスに対応するノードが古いサービスのノードよりもLatticeの上側に位置するとか)で評価できそうだと主張している.
あまりサービスの数が増えると管理不能になりそう,と指摘はされていたが,Concept Analysis をこういう用途に使ってみようというアイディアは面白い.
_ [論文]IWPSEセッションメモ2 ▲
- Jameleddine Hassine, Juergen Rilling, Jacqueline Hewitt, Rachida Dssouli: Change Impact Analysis for Requirement Evolution using Use Case Maps.
Use Case Mapという,システム内のどのコンポーネントが順番に動作するかを表現できる図を描いておいて,その図上で,あるコンポーネントを変更したとしたら,他のどのコンポーネントへ影響が波及するかを調べましょう,というもの.Use Case Map については初めて聞いたのだけれど,クイックリファレンスの図などを見ると,シーケンス図などよりも条件分岐など描けて,抽象度の高いレベルの表記には便利そうな印象.
- Jacek Ratzinger, Michael Fischer, Harald Gall: EvoLens: Lens-View Visualizations of Evolution Data.
コンポーネント間の結合を無向グラフとして閲覧するツールを作りました,という話.結合度を閾値でフィルタして,ある期間でたくさん変更される場所(で,かつ結合度が高いもの)を探せるようにした,という.メトリクスとしては事前計算可能なものだけを選んで,表示自体は高速に行えるようになっている.
- Serge Demeyer: The LAN-simulation: A Research and Teaching Example for Refactoring.
違う Reengineering Tool を色々使って,授業の一環としてリファクタリングと回帰テストの指導をしたという報告.教材だとケーススタディとしては小さくなってしまうものの,ツールの違いなどを学ぶには役立つ様子.スライドなどの教材はObject-Oriented Reengineering Patterns という書籍のページで公開されている.
_ [論文]IWPSEセッションメモ3 ▲
- Steven Reiss: Evolving Evolution.
普通,システムの変更(たとえば,OSをいつアップグレードするかとか)は管理可能だったのだが,Web サービスを使うと,サービス提供者側の都合などで突然仕様が変更されたりする可能性があって,変更の管理が困難となる.
それに対して,Outerface という Interface + Functional Sematnics + Non-Functional Requirements (Security, ...) といったリッチなインタフェースを用意しようと言っている."Functional Semantics" として,その実装(サービス)が満たさないといけない単体テスト(と Contract)を用意して,サービス仕様が変わったことを検知しようというのがちょっと強引な気もするけど,ないよりはずっと良いかもしれない.
- Giuseppe Antonio Di Lucca, Massimiliano Di Penta, Anna Rita Fasolino, Porfirio Tramontana: Supporting Web Application Evolution by Dynamic Analysis.
Web アプリケーションの実行を,Web サーバ側で実行時情報を集めて 分析しよう,という研究.
ユーザ・セッションをページ間の Transition graph として表現して,入力が1より多いJoin,出力が1より多いFork,入出力ともに1ずつのGroupableというノードに分類し,グラフのノードをクラスタ化する.
で,各クラスタはユースケースの候補であろうと考えて名前を開発者に割り当ててもらうと,それらのユースケース候補間のextends関係やinclude関係を取り出して開発者に提示するというものらしい.
一度名前を割り当てると,次の解析のときにはその名前を再利用するようなことを言っていたので,一種のトレーサビリティ確保のようでもあり,なかなか面白い研究という気がする.
2005-09-14 [長年日記] ▲
_ ESEC/FSE 2005 サマリ ▲
参加者 251人(うち学生111人,28カ国).Conference本体だけの人は147人(学生47人).
Proceedings は全部で350kg超.Organizing に働いた人は65人以上.
採録論文数は,201本中の32本.
ツールデモは,21本中の8本.
Doctoral Symposium が12本中6本.
ワークショップが17個中6個.
チュートリアルが25個中8個(ただし,そのうち開催されたのは2個).
ACM SIGSOFT Ditinguished Paper Awards は以下の3本.
- Martin P. Robillard: Automatic Generation of Suggestions for Program Investigation.
- Yichen Xie, Alex Aiken: Context- and Path-sensitive Memory Leak Detection.
- Koushik Sen, Darko Marinov, Gul Agha: CUTE: A Concolic Unit Testing Engine for C.
個人的には,最初の Keynote Talk とか,Software Evolution Analysis のセッションとか明示的に Evolution と言っている人たち以外でも,リポジトリから過去の変更の様子を調べてバグ発見に役立てようとか,Evolution 系でよく聞くようなお話が増えてきている気がした.
_ ESEC/FSE Keynote メモ ▲
- Keynote その1. Oscar Nierstrasz: The Story of Moose: A Language Independent Reengineering Environment.
前半は Reengineering の特徴の話.
ソフトウェアの保守作業と呼んでいるものは,60%くらいが機能の追加,25%くらいがバグフィクスで,"continuous evolution" だというのが正しい.変更しなければ,そのソフトウェアが徐々に役立たずになっていくだけ.
legacy system は,価値があるものの,知識が失われており,アーキテクチャや設計が変化したりしていて,変更が困難である.extract design, identify components といった研究は,これに対処するためのものだと言える.
で,reengineering では,コード→設計→要求→変更された要求→変更された設計→変更されたコードというように,コードから始まってコードに帰っていく特徴を持つ.
スタート地点として,まずはソフトウェア内のエンティティ群から,メトリクスなどをもとに特別な(exceptional)エンティティを発見しておき,そこから詳細なモデルの獲得,コードクローンの検出,責任の再配分(redestribute responsibilities),コード変換と進む.
後半は,Reengineering を支援するために作った MOOSE という環境の話.Java や C++ といった言語から中立なモデルを作ってツールの integration を可能にすること,entity のグループも entity とすることで階層的なエンティティの取り扱いを可能としていることなどが特徴.また,smalltalk のような動的言語を使って,entity に直接様々な働きかけをできるような環境も有用である,と言っていた.
- Keynote その2.António Câmara: Innovations in Pervasive Computing.
日本でいうところのユビキタス環境に近いお話.
主役は携帯電話とか無線タグ(RFID)で,色々なサービスが作れる.たとえばタグの物理的な位置の識別を使ったサービスであれば,タグを持っている人の位置情報と,どの場所に人がいるかの他のセンサーからの情報との一貫性をチェックすることで侵入者を検知したり,行きたい場所へのナビゲーション情報を提示したり,何らかの資産が無許可で移動させられようとしているのを検知したり,といったものが考えられる.
その他,消防士であれば通信デバイスや位置・周辺環境・体調に関するセンサを付けて消防車や病院などと情報を交換するとか,運動選手ならやはり体調や外気温などのセンシングをしたりとかいった intelligent garment のような応用があるといったように,今後数年でこのような応用がある,という紹介系な話だった.
- Keynote その3.Jeff Kramer and Jeff Magee: Engineering Distributed Software: A Structural Discipline.
こちらは分散アプリケーションと,アーキテクチャ記述言語の関わりについてのお話.モデリングによって実際のアプリケーションの複雑さを抑えて解析を容易なものとし,プロセス代数として構造(structure)や振る舞いを合成する combinator を用意してデッドロックや一貫性のない状態への到達を検出する.
オブジェクトの管理の例として,オブジェクトの active/passive 管理を挙げており,active (処理を実行中)のオブジェクトはたとえ破棄される命令が来ても,処理が終わって passive に戻るまでは途中で消滅したりできないようにすることで,データの一貫性が保持される様子を紹介していた.
_ [論文]ESEC/FSE セッションメモ1: Change Impact Analysis ▲
プレゼンで聞いた話ベースなので,詳細は論文自体を読む必要あり.
- Martin P. Robillard: Automatic Generation of Suggestions for Program Investigation.
プログラム要素間の接続グラフに対して,ユーザが調べたい要素名をいくつか与えると,それに関連した注目すべき要素だけを取り出すというシステムの構築.たとえば allocated フィールド,allocateFiles,getAllocated,setAllocated メソッドを入力として指定すると,それらを使っているようなメソッドが候補として紹介されることになる.
推薦の基準は,Specificity と Reinforcement.Specificityとは,入力で与えられた要素集合だけに関連しているものは,他の要素にも関連を持っているものよりは優先度が高くなるということ.また,Reinforcementとは,入力で与えられた要素集合のに対して多くの関連を保持しているものを,関連が少ないものよりも優先するということ.
関連としては,calls, called by, accesses, accessed by を使って,それぞれについて個別に推薦を出すらしい.同じ要素に,複数の関連から推薦が来た場合は,範囲の値なので f(x, y) = x + y - xy で merge する.
ケーススタディでは,推薦されたアイテムをチェックして,上位に関連したものが固まりやすい傾向があることを確認している.
- Bill McCloskey, Eric Brewer: ASTEC: A New Approach to Refactoring C.
C言語のマクロには文法がなく,扱いにくいが,実際に使われているほとんど(著者らによれば99%)のマクロは構文的に完全な文や式が来ることが前提になっているので,そういう制約を付けたC言語用のプリプロセッサを作ってみた,という話.マクロの引数の型として,文や式が選択できるようになっている.また,言語を定義すると同時に,従来のマクロを新しい言語上に自動変換するツールを作っている.基本的には,どこを展開したか記憶しながらマクロを展開→構文木を構築→展開後の構文木からその展開されたマクロの型情報を取得→展開していた部分を徐々にマクロに変換していく,という形式.
- Thomas Henzinger, Ranjit Jhala, Rupak Majumdar: Permissive Interfaces.
ライブラリに対して,どんなメソッド呼び出し列が許されるのかを自動分析しましょう,という話.
ライブラリの中にある状態変数を選択すると,関数呼出しごとにそれらの値の範囲がどのように変わるかをチェックして,型付きの有限状態オートマトンを構成する.状態変数の指定を間違えていた場合,正常状態とエラー状態とが同じ条件を保持してしまうので判別可能だったりするらしい.引数のことは考慮してないようだが.
_ [論文]ESEC/FSE セッションメモ2: Patterns and Aspects ▲
- Murali Haran, Alan Karr, Alessandro Orso, Adam Porter, Ashish Sanil: Applying Classification Techniques to Remotely-Collected Program Execution Data.
プログラムの実行履歴ごとに実行の成功・失敗をラベル付けしておき,モデル学習を行っておくことで,新しい実行履歴に対してそれが成功だったか失敗だったかを自動分類する.
モデル学習には,tree-based classifier(分類木?)を作成.複数の木を作ってから多数決を取る "forest" を構成することで,tree の不安定性は克服できるらしい.で,この分類の実現にはどんなデータが必要かを調査している.
データとしては,プログラム中の各ブロックあるいはメソッドが何回ずつ実行されたか,あるいは例外が何度投げられたかの記録を使っているのだが,実際に集めてみたら,あまり性能に変化は出ず,集めるのが簡単なメソッドの実行回数ベースで良いようだ,ということになったらしい.また,計測するメソッドの数を何%か減らしても,性能が急激に劣化したりはしないようで,メソッド呼び出し回数を,ランダム選定した10%くらいのメソッドだけに対して集めただけでも pass/fail の2値分類はできるようだ,と述べている.
- Hamid Abdul Basit, Stan Jarzabek: Detecting Higher-level Similarity Patterns in Programs.
Structural Clone を見つけよう,という論文.Structural Clone は,相互にクローンであるようなコード片の集合(Clone Class)ごとに割り当てられた ID の列.「クローン A のコード片が1個とクローン B のコード片が2個同時に登場することが多い」といったパターン.例としては,Java Buffer Library を挙げていた(似たような構造を持ったクラスが多いため).
質疑応答では,クローン検出しなくても名前などだけからでも似ていると分かるものもあるのでは?というのに対して,ファイル名などが似ているから中身がコピーとは限らない場合がある,といった答えをしていた.また,「コードクローンなら同時に直さないといけないというのであれば,同時に変更されているかどうかの情報を集めたほうが早くないか」とも聞かれていた.クローン検出は別にそれだけのために使われるわけではないと思うけど.
- Kevin Sullivan, William Griswold, Yuanyuan Song, Yuanfang Cai, Macneil Shonle, Nishit Tewari, Hridesh Rajan: Information Hiding Interfaces for Aspect-Oriented Design.
アスペクト指向プログラミングでは,横断的関心事を修正するときはアスペクトだけ直せばよいが,アスペクトが貼りつく対象となるクラス群のどれかが変更されても,アスペクトの修正を検討しないといけなくなる.これでは困るので,クラスよりも先にまず抽象的な "Pointcut interface" を用意しておいて,それをクラスが実装して,またアスペクト側はそのポイントカットを利用するという形にできないか,と提案している.
_ [論文]ESEC/FSE セッションメモ3: Software Evolution Analysis と Tools から一部 ▲
- Miryung Kim, Vibha Sazawal, David Notkin, Gail Murphy: An Empirical Study of Code Clone Genealogies.
ソフトウェアのバージョン間のクローンの変化を調べてみました,という論文.ローカルな修正が困難なクローンがたいてい long-lived クローンとして長く生存し,修正しやすいものは volatile (たいてい5バージョン程度で消滅)であった,という調査結果.
long-lived で,開発者が放っている間に複雑化してしまうことはないのか,と質問をしてみたら,そんなことはないようだ,とあっさり答えが帰ってきた.実は全部手で調べている?
生存期間のバージョン数の数え方が,total lines of code clones が変化したかどうかで決定されているので,少し怪しい印象は受けた.また,volatile なものは,共通化して消してもまたすぐに分岐させないといけない場合があるから放っておいてよい,といった発言をしていた点も,少し気になるところではあった.開発者が努力したから消えたのでは?という気もするが,volatile クローンについては,発生してもすぐにコードとして分岐する例を見たからそう言っているようにも聞こえた.
- Reid Holmes, R.J.Walker, Gail Murphy: Strathcona Example Recommendation Tool.
ツールデモのみ.目的のインタフェースやメソッド名のコード片から,それに似ているコード(実際に使っているコード)の推薦を行う.やはり,弱点は把握しているようで,悪い例を推薦してしまう可能性,それとコピーペーストを促進してしまう可能性がある,と言っていた.とはいえ,面白い試みではある.
- N. Tillmann and W. Schulte: Parameterized Unit Tests with Unit Meister.
普通の Unit Test では,条件分岐などをカバーするようにうまく入力変数を色々作っていかないといけないが,このツールは,パラメータとして変数宣言だけを用意しておくと,条件分岐を一通りカバーするように変数値を準備するテストケースを作ってくれるらしい.やっていることは単なるテスト生成ツールなのだが,その自動設定されるパラメータ変数を使って好き勝手にテスト用コードが書けるので使いやすそうな印象は受けた.
- Robert Chatley and T. Timbul: KenyaEclipse: Learning to Program in Eclipse.
Kenya というのが,Java のクラスなどを省いた手続き風教育用言語らしい.クラス宣言などを取り払ったぶん,簡単に言語が学べるようにしようという試み.実行時にはJava にコード変換される.個人的には Pascal の置き換えなのかも,と思った.
このツール自体は,Eclipse 用の Kenya 開発環境で,スタイルチェッカなどを充実させている.色々な開発ツールを使いながらプログラムを書くことを学べるようにしたい様子.IDEを使うとコマンドラインの使い方が分からないとか,「スタイルチェッカが直してくれるから」とそれに依存したコードを書いてしまわないか,といった懸念はある,としていた.
_ [論文]ESEC/FSE セッションメモ4: Bug Localization ▲
- Chao Liu, Xifeng Yan, Long Fei, Jiawei Han, Samuel Midkiff: SOBER: Statistical Model-based Bug Localization.
if 文での predicate を,true/false の2値をとるランダム変数と考えて,テストケースに対して true になる確率を計算し,成功テストケースと失敗テストケースで大きくその値が変わるものを疑わしい条件だとする手法.
どのくらい値が変わったかを評価する関数を決めて predicate をランキングすると,大半のバグについてはコードの10〜20%を調べると発見でき,Andreas Zeller らの Cause Transition などと比べても若干良い値が出ていた.ただし,Cause Transition では,成功テストケースと失敗テストケースを1つずつ用意するだけでよいので,1個しか失敗テストケースがない場合は Cause Transition を使い,複数テストケースが集まってきたらこちらの手法に切り替えるのが良い,といった形になっている.
- Benjamin Livshits, Thomas Zimmermann: DynaMine: Finding Common Error Patterns by Mining Software Revision Histories.
ソフトウェアリポジトリから,メソッドの使い方のパターンを探そう,という試み.同時に追加されるメソッドの集合というのはいくつか決まっているので,追加しているメソッドが足りない場合,あるいは呼び出し順序が間違っている場合はルール違反ではないか,と推論する.
情報収集は,リポジトリからリビジョン単位のコード片を取り出してきて,1つのオブジェクトに対するメソッド呼び出しがどれだけ追加されたかを調べておく.で,frequent item set だけを取り出す.{acquire, release} といった集合が取り出されたとき,{acquire}だけを追加したリビジョンと,その前後に{release}だけを追加したリビジョンがあれば,{acquire, release} にしようとした変更だと判断するようなことを言っていた.
見つけられてきたメソッド群に対して,プログラムを実行し,どのような順序でメソッドが実行されるかを調べる.メソッド呼び出し順序については,現在はまだ自動化できておらず,人間が与えないといけない様子.また,実行は単体テストとか,特に限定していないようだが,ちゃんと選ぶ必要があると思われる.
この方法は,「moveを呼んだ後にupdateを呼ぶ」といったパターンが発見できれば,アスペクトマイニングにも使えるかもしれない.- Zhenmin Li, Yuanyuan Zhou: PR-Miner: Automatically Extracting Implicit Programming Rules and Detecting Violations in Large Software Code.
lock-unlock, SearchSysCache-ReleaseSysCache のようにペアで使うメソッド呼び出し,var.command = foo; var.driver = bar; のような構造体へ設定する値には,ある程度パターン(しばしばundocumented)が存在する.そのような implicit rule を見つけようという研究.
今までには,事前にルールを定義しておいて後でそれをチェックするというのはあったが,自動で探索するものはなかったらしい.
基本は関数単位で,呼び出している関数名,構造体名,フィールド名の集合で関数を抽象化する(ローカル変数は除外).
IDを数値で表現したら,たとえば {5, 12, 19, 26} といった集合が関数ごとに割り当てられることになる.で,{5, 12, 19, 26} が19回登場して {5, 12, 19} が20回登場しているなら,if {5, 12, 19} then {26} が confidence 19/20 = 95% として得られる.
また,一連のメソッド呼び出しなどが複数のメソッドに分割されている可能性もあるので,その関数を呼び出している関数へと遡ってから子供の関数の呼び出し列を調べるという作業も行っているらしい(ただ,call path を調べる都合上 dynamic binding なんかには弱そう…).
ケーススタディでは Linux や PostgreSQL などを対象に適用実験を行っていて,関数群よりもむしろ関数と変数あるいは変数同士といった組のほうが多く見つかったらしい.Linuxでは合計約3万種類ほど.要素数的には,9割方が10個以下に収まっている.ただ,出てきたルールに違反しているであろうと判定された上位60例を取り出してきたとき,Linuxでは16個がバグ,20個が正しい使い方,24個はfalse positive.PostgreSQL では45個がfalse positiveとなっていて,現段階では,false positive 率がけっこう高いのが少し気になるところ.
2005-09-15 [長年日記] ▲
_ [work] ESS2005 ▲
山下記念研究賞の表彰が ESS のプログラムにあるらしいと聞いて,出張日程などちょっと相談.研究会からは今のところ何も連絡ないんですけど….
連絡がないといえば,APSEC2005のNotificationも昨日の予定のはずなのに来てない.
_ [論文] クラス間の関連のインスタンスを扱える言語の提案 ▲
Gavin Bierman, Alisdair Wren: First-class Relationships in an Object-Oriented Language.
Proceedings of the 12th International Workshop on Foundations of Object-Oriented Languages (FOOL 2005).
偶然発見するまで知らなかったけど,POPL併設のワークショップらしい.
ERモデルのように,オブジェクト間の関連にもちゃんとクラスを定義してインスタンスとして操作できるような言語を定義してみましたという論文.
relationship は,クラス宣言とほぼ同様に宣言するものの,先頭に relationship R from A to B
というように名前 R 以外に対象クラスを指定する.そうすると,クラス A の任意のインスタンスに対して,a.R += new B();
のように関連を追加できる.
面白いなーと思ったのは,関連の継承.relationship R2 extends R
と宣言したら,a.R2 += b;
とすると,a.R でも a.R2 でもインスタンス b にアクセスできるが,他の関連 a.R3 などからは見えない.
また,関連に参加できるインスタンス数をfrom one Foo to many Bar
のようにして設定できるようにしている(数値も使用可能).ただし,このような関連についての制約は,どの時点から守られるのか(インスタンス生成から,いつまでに関連を設定しないといけないか)が微妙な気はするが.
AOPのインタータイプ宣言で参照を持たせる場合と,コードは似ている気がする.個人的には,関連自体が双方向になったり,関連そのものにもメソッドなどを持たせたりできれば,何か色々面白い使い方ができそうな気がした(双方向の関連だと参照管理のオーバーヘッド大きそうだけど).
2005-09-17 [長年日記] ▲
_ [work] APSEC 2005 Author Kit ▲
Notification of Acceptance 来ないなーと放っておいたら accepted papers 用の author kit だけが到着.あれ?と思ったので E-mail Chair に notification 来てないよーと連絡.
(追記)Accepted の通知が届いた.well-structured with good readability とほめられたものの,何か特に意見がもらえたわけではなし.みんな査読で忙しかったからコメントが簡潔になっている?
_ [hyCalendar] 1.3.0 リリース ▲
ようやくドキュメント書き直す時間が取れたので,ちゃちゃっと書いてリリース.早いもので,前バージョンの1.2.1からは約2ヶ月ぶりの更新になる.
他の予定からN日前・後の指定ができるようになって,実は初めて「月末からN日前」というタイプの予定が書けるようになった.発生しうる予定の集合を,これでだいぶカバーした,かな?
2005-09-18 [長年日記] ▲
_ [Delphi]ActiveX のタイプライブラリ ▲
新しく手に入れた ActiveX コントロールを使おうとしたら,メニューの[コンポーネント]-[ActiveXコントロールの取り込み]からはなぜか取り込めなくて,[プロジェクト]-[タイプライブラリの取り込み]でタイプライブラリのユニットを作成したらうまくいった.
[ActiveXコントロールの取り込み]は別の目的のためのメニュー?そっくりなダイアログで,何が違うのか不明.
_ [論文] メソッドの reentrant 時などの不変条件の考慮 ▲
だいぶ前に読んでから放置してたことに気づいたのでいちおう簡単にメモだけ.
Anindya Banerjee, David A. Naumann: State based ownership, reentrance, and encapsulation.
Proceedings of ECOOP 2005.
インスタンスの不変条件が,あるメソッドを実行している最中(不変条件が一部崩れているとき)にコールバック呼び出しなどが起きた場合はどうなっているべきか,ということについて議論した論文.
アイディアとしては,インスタンスが packed/unpacked 状態を持っていて,メソッドの中で不変条件を崩すときは unpack し,終了前に pack するらしい.
2005-09-22 [長年日記] ▲
_ [work]論文submitに向けてごそごそ ▲
来週は本格的に移動作業になってしまうので,ぱぱっとCopyright FormとReprints Order Formを送付.
IEEE PDF eXpressを使って,欧文基本フォントも含めて全部埋め込み済みなPDFを作成してみた..tex や .dvi,.eps を一式 zip とかで固めて送ると,メールで PDF が返ってくるというシステムらしい.原因がいまいちよく分かってないが,図の貼り込みにepsfileを使うと画像が表示されず,includegraphicだと通る.
返ってきたPDFはなぜかA4サイズ.letterpaper 指定とかが必要?Acrobat 付属の PDF プリンタドライバで letter サイズに(「自動中央配置」オプションを解除して)フォント埋め込みで印刷してみたら,いちおう目的のものは得られたけど…….
研究室環境だと dvipdfmx -p letter paper.tex
として dvi から直接 pdf 生成するのが一番早い気がする(参考にしたもの: はぢめてのdvipdfmx).
_ ysakata [こんにちは. 向こうでお会いしたものです. 偶然ググッて見つけてしまいました. リスボンは料理がおいしく良い街ですね..]
_ いしお (てぃる) [どうも,こんにちは.ポルトガル料理は「日本人の味覚にあう」と何かに書いてあったのですが,本当に良い場所でしたね.]