# 個別MTG
## 議事録

## 1/17
### 卒論作成について(by 2/7)
- Abstractの文章について

ソフトウェア開発における自動プログラム修正は開発工数の半分を占める作業といわれているデバッグの工数を削減することが期待されており，研究が盛んにおこなわれている．
自動プログラム修正は，バグを含むプログラムに変更を加えることで用意したテストを通過するプログラムを出力する手法である．
自動プログラム修正の手法として，遺伝的アルゴリズムに基づいて修正を行うものがある．
ここで，自動プログラム修正における遺伝的アルゴリズムは，目的のプログラムが得られるまでプログラム文の挿入，削除，置換及び交叉を行う手法である．
Macawは，遺伝的アルゴリズムを採用したAPRツールのひとつであるkGenProgの進化過程をツリー状に可視化するツールであり，遺伝アルゴリズムにおける膨大な変異プログラムの解析を容易にすることが期待される．しかし，kGenProg及びMacawには個体の生成時間を計測および表示する機能が実装されておらず，解となる経路が最適に生成されているかどうかを確かめることが困難である．
そこで，kGenProg側に各個体を生成する時間を計測する処理を追加し，それをMacawで可視化することで全体の生成時間のうち解となるプログラムの生成経路にかかった時間を特定することにより，改善案を提供することが期待される．

- 参考文献の探し方
- Google Scholarで調べようと思っているが、本当にそれでいいか
- そのとおり、ただしbibTeXを用いる
### 中間発表について
- 1/26(Thu.)
- fenrir上の先輩のスライドを参考に作る(by 1/22(Sun.))
- その際何かコツのようなものはないか
- 進捗報告の一環にしてもよいし、卒論の予行演習的に作成してもよい
- 発表練習は対面orオンライン？ 1/24ごろに行いたい

### 研究そのものについて
- kGPに実装した時間計測機能が本当に正しいかを検証中
- どのように検証すべきなのか？
- sleepを挟む(いったん柗本先生に相談)
- D4jなどで実験すべきか？
- 十数個程度のテストについて実験して、無駄な経路の占める割合などを調査
## 11/28
- 案1(修正)実行時間可視化:kGenProgを実行しているとき、世代間の処理時間が長くなることがある。しかし、その原因がテスト実行に起因するものなのか、それとも変異の生成に起因するものなのかを現状では判断しづらい。また、**生成途中に、そもそもビルドに失敗する粗悪な個体が生成されることがしばしば起こりうる。そこで、実行時間を可視化することで、そのような不要な個体を正常に生成された個体と比べて時間比較をすることで、どのような変更に対して生成時間を費やしているか、またその変更は修正に有効であるかを知ることができ、kGenProgの性能改善に役立つ。**

- 案2(修正)実行結果のツリー比較:kGenProgには、OchiaiやZolterといった行ごとの疑惑値の算出方法や変異・交叉のタイプを変更することができるオプションが用意されている。さらに、実行結果をJSONファイルで出力するオプションも用意されていて、実行結果に関する情報をツリー上に表示するMacawという先行研究がある。しかし、Macawでは一度に単一のテストのみしか可視化できず、異なる条件での比較を単一のページでは行えない。**また、kGenProg側でも、異なるオプション同士の比較を行える機能は存在しない。すなわち、既存のツールにおいては一目で同じソースコードで機能を比較しづらいという問題がある。** そこで、Macawに複数のファイル情報を一度に重ねて表示できる機能を追加し、手法を提案する。このことにより、異なる条件間でのテスト結果の比較を容易に効率的に行えることが期待できる。
- ツリーのDiffを効率的にとる研究は盛んにあるので目的を決定し、そのアルゴリズムを模倣すれば手法として成立する

- 太字が
## 11/24
- テーマ:シナリオの構成
- 案1.実行時間可視化:kGenProgを実行しているとき、世代間の処理時間が長くなることがある。しかし、その原因がテスト実行に起因するものなのか、それとも変異の生成に起因するものなのかを現状では判断しづらい。さらに、kGenProgにおいては、実行環境の性能がそのまま実行可能な変異数に直結する。研究室の環境においても高性能であるとはいえ、~~メモリやプロセッサの性能には限界があり、大規模なプロジェクトのプログラム修正においてはメモリ不足で満足な結果を得られないことがある~~**これは実行時間∝メモリの前提、これを確かめる**。そこで、実行時間を可視化することで、高コストの経路を特定し、性能向上のヒントを与えうる。
- 実行時間を表示することで無駄なミュータントに関する情報を知ることができ、それを削減する

- 案2.実行結果のツリー比較:kGenProgには、OchiaiやZolterといった行ごとの疑惑値(バグの存在のうたがわしさ)の算出方法や変異や交叉のタイプを変更することができるオプションが用意されている。さらに、実行結果をJSONファイルで出力するオプションも用意されていて、実行結果に関する情報をツリー上に表示するMacawという先行研究がある。しかし、Macawでは一度に単一のテストのみしか可視化できず、異なる条件での比較を単一のページでは行えない。そこで、Macawに複数のファイル情報を一度に表示できる機能を追加し、それらの表示をオンオフすることができる手法を提案する。このことにより、異なる条件間でのテスト結果の比較を容易に効率的に行えることが期待できる。
- このシナリオは手法のみ。これに関しては目的「既存のkGenProgやMacawの」
- TODO : 次回個別MTGを11/28(Mon.)17:30～対面で行うので、それまでに
- 案1については肥後先生のアイデアを基に内容を考える
- 案2については目的について明確に述べる
タスクを行う。
- Memo : まずYes/noで答えてから情報を付け加える
## 10/6
- 研究テーマ:APRの可視化を用いた欠陥限局(Ochiaiなど)の評価基準別の比較
- 欠陥限局の評価基準に関する研究はすでにある(Ochiaiが最も優れている)
- 可視化したときに基準別の違いがどう表れるかを
- 1つのソースコードだけでなくいくつかのソースコードを用いてその特徴を調査
- 手段:MacawのようにJavaScriptでの実装を念頭に
- あるいは、GUIアプリとして実装することで新たな研究の材料になる？
- 先生に聞きたいこと:欠陥限局以外のAPRの研究テーマ
- 可視化の研究に役に立ちそうなものがあれば教えてください
- https://sdl.ist.osaka-u.ac.jp/pman/pman3.cgi?DOWNLOAD=459
- https://sdl.ist.osaka-u.ac.jp/pman/pman3.cgi?D=635
- この論文を読んで今後の研究に関しての改善点や弱い点などを古藤先輩に報告する
- 10/9 11:00～

### 7/5
## 6/28~7/5
- 研究テーマ:テストケースと自動プログラム修正の影響の修正プログラム依存性の調査
- 目的:自動プログラム修正において、テストケースがAPRにどのような影響を与えるのか、具体的には修正内容ごとに成功・失敗テストケースの量を変化させて修正が
- 手段:自動テストケース
- 6/28 古藤先輩の前で作成したスライドを発表したところ、
- テストケース１をパッチ生成用のファイル、ケース２を評価用のファイルとする
- オーバーフィット（過学習）に関する論文をGoogle Scholarで調べる
- といったフィードバックを得た。

### 6/28
- 研究テーマ:自動テストケース生成
- 目的:APRにおいて複数のテストケースを用いたときそのすべてについてバグをできる限り取り除くこと
- 手段:テストケースを複数用意し（それぞれをテストケース1,テストケース2,...,テストケースNとする）、まずテストケース1に対してAPRを行う。次に、テストケース2に対してAPRを行った後。もう一度テストケース1を
- 6/28 古藤先輩の前で作成したスライドを発表したところ、
- テストケース１をパッチ生成用のファイル、ケース２を評価用のファイルとする
- オーバーフィット（過学習）に関する論文をGoogle Scholarで調べる
- といったフィードバックを得た。

### 6/14
- 先生と話したいこと
- 希望調査書について
- 6/9提出分は自動プログラム修正の研究について提出、添削してもらった
- もし竹村研などメタバース関連の研究室に移ろうとする場合は調査書をどのように修正すべきか
- 研究テーマについて
- 早い人であれば夏の時点で研究結果を示している場合もあるが今現在の時点で研究に取り掛かっていなくてもまだ問題はない。しかし、研究テーマは大方の人は決定している。

### 6/8
- 次回の個別MTGは6/14(Tue.)ミーティング~~後~~前(13:30)
- かいち先輩に話を聞いてみる
- デコンパイルしたソースコードと元のソースコードの比較
- デコンパイルに特化しているわけではない
- 明日の希望調査票のネタについて、もし厳しければ古藤先輩に延長を打診してみる（テーマによっては先生に拒絶されることも）
- コンパイレーションレスコンパイラについて希望調書を一旦書いてみるのも手段

# Legacy

## 6/14~6/28
- 月末までに研究の
- 目的 現時点で未解決である必要がある(現時点でこの程度まで進んでいることを併せて説明できると良い)
- 手段 (どのようにして未解決の問題を解決すべきか？)
- の２つを他の人が聞いてわかるように説明できるようになる

## 6/8~6/14
- 調査希望書はとりあえずRE(リバースエンジニアリング)を用いた自動プログラム修正について書いた
- 具体的にはバイナリコードをデコンパイルツールを用いてアセンブリ言語に変換した後、それをJavaコードにディスアセンブルしてコードを解析する
- プログラム修正を終えた後修正後のコードを再びバイナリコードに変換する

## 6/3~6/8
- 次回のMTG(6/14 16:00~ごろ)までに自分の研究したいテーマを先生などにわかるように説明できるようになる
- 最悪先生に研究テーマを決めてもらうことも？
- gradleやantといったビルドの自動化でバイトコードが生成されたら嬉しい

## 6/03 15:00
- todo:次回のMTG(6/8 15:10~ごろ)までに自分の研究したいテーマを先生などにわかるように説明できるようになる
- 論文があると良い
- https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%90%E3%83%BC%E3%82%B9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0
- カイチ先輩がバイナリから似たような研究を行っている
- sdllog

### Provable～Networksについて
- https://dl.acm.org/doi/pdf/10.1145/3453483.3454064
- この論文は安全でない挙動が見受けられたときの問題修正について取り組んでいる
- *Provable(立証できる、証明可能な) repair problem*
- ネットワークNに対して、与えられた条件を満足するネットワークN'を構築する
- 点修正(有限入力)、超多面体修正(無限点集合)のアルゴリズムをプレゼン
- Decoupled DNN
- 点修正を線形問題に帰結できる
- https://easychair.org/publications/open/CWhF の実装は指数時間だったもののこの論文ではLP（線形計画法）問題に帰結
- DNNにもバグや誤検知はありうる
- 修正を施そうとするとかえってバグが生じることも
- 手入力で教育させるのは非効率的かつ教育データが手に入らないことも
- 代わりに再急降下法を用いて行う
- ドローダウン(ひとたび教育したデータを忘れる)を防ぐ

### Neural Network以外に興味のある分野
- リバースエンジニアリング（ただ趣味的な意味合いで興味があるだけ、できればこれに関係した研究を行いたい）
- リバースエンジニアリングを防止用の目的のコードと等価な自動コード生成
- printf("Hello, world!");
-
- APR（自動プログラム修正）
- 先輩方の「巨人の肩に乗る」
- 自動コード生成

## 5/24 14:00
- 論文を読むときは、「この論文によって何ができるようになったか」をチェック
- ツール、データが利用可能であるか、もしそうであれば論文の結果を再現できるか
- Provable Repairについては一度それを実践する、もしダメだった時のために別の論文についても調べる
- 論文にartifact availableの表記あり
-
- 3名のスライドはGithubのkusumotolabに置いてある

- バグのリンク↓
https://github.com/kusumotolab/kGenProg-exp

- 次回は6/3 15:00~

## 5/13 16:00

- コードの自動修正・自動生成がやりたい．
- kGenProgを触ってみる． https://github.com/kusumotolab/kGenProg
- 付属のバグ，Defects4Jのバグに対して実行してみる
- 自動生成の一例：https://copilot.github.com/
- ☆藤本，前島，渡辺のスライドをチェック
- ☆ https://program-repair.org/bibliography.html ←興味が持てそうな論文を探す
- 国際会議：ICSE, FSE, ASE，論文誌：TSE, TOSEM, EMSE
- 自動修正自動生成以外でも興味が無いわけではない．Deep Learningも機会があればやってみたい．
- ☆ https://sdl.ist.osaka-u.ac.jp/pman/pman3.cgi?MODE=list;MENU=simple;FROM=year;SEARCH=;LOGIC=and;SORT=y_t_descend;PTYPE=all;LANG=ja

## my note
- ここに気がついたことを書く(1週間程度)

## ざっと目を通してみた論文
- A syntax-guided edit decoder for neural program repair
- デコーダ
- github: https://github.com/95616ARG/PRDNN (公式)、 https://github.com/95616ARG/SyReNN (派生)
- Concolic program repair
- Concrete + Symbolic、具体記号プログラム修正
- Shipwright: A Human-in-the-Loop System for Dockerfile Repair
- Dockerファイルについての修正
- Provable Repair of Deep Neural Networks
- 深層ニューラルネットワークの修正
- 個人的にホットだと思う
- GUIDER: GUI Structure and Vision Co-guided Test Script Repair for Android Apps
- AndroidアプリのGUIによる構造-視覚共通補佐テスト
- アプリ×修正

# 2022/5/23
- コード解析の方法、手段は一つじゃない ある程度の論文に触れてみたが、まだ研究内容を決めるには至っていない