<details>
<summary>進捗報告時の注意</summary>

- 先に結論を書く
- Good or Bad を伝える
- i.e. 実験結果の項目の直下に Good or Bad を書く
- 客観的な言葉を使う
- i.e. ある程度 -> 80%
- 後で見返して，何のことを書いてあるかわかるように書く
- i.e. 論文を読んだ -> "{論文タイトル}"を読んだ
- 事前に話すことを考えてスマートに話せるように準備
- 最低限Wordの校正で怒られないレベルの日本語になるように推敲する
- i.e. 各xxxごと -> 各xxx or xxxごと
- 日本語は厳密に使う
- i.e. 「調べる」と「見つける」は違うので使い分ける
- 全角と半角を混ぜるな．許せん💢💢💢（冗談です）．統一するべき
- i.e. 「（」と「(」
- 何をしたかだけを書くのではなく，何のために行ったのかを書く
- i.e. やったことの後に"目的"や"理由"みたいな項目をつける
- 文だけでは伝わりづらいと思ったら例を載せることを検討する
- 文を推敲するのは前提
- 質問の答えを頭に持ってくる
- i.e. 「〜ですか？」には「はい or いいえ」
</details>

<!--
# 2025//
## ry-inoue
## tk-kawam
## simizu-s
## ta1-kmr
## a-yamank
## m-kunagi
-->
# 2025/2/6
## ry-inoue
- 博士ネタは東京行ってから？→今から始めようかな
## tk-kawam
- 前回の添削のやつは全くできていません。
- 日曜日なら来れる。日曜の午後1時に全部新しいところの修正をして自分なりに完成版だと思えるものを送ってきて、最後の確認程度のつもり。
- それでお願いします。
## simizu-s
- 日曜日の午後1時にいてほしい。
- 発練は全部入っている。完成版ねOK。
- もうちょっとページ数足りてない気がする。
## ta1-kmr
- 16分ぐらいでいいのでは？
- いろんな人から意見をもらえるように。
## a-yamank
-
## m-kunagi
- いいと思います。
- 全部で何章？５～７はまだ、これが書けても30ページいかなさそう。参考文献も含めて30ページを目指してください。
- 11日の朝の手元にあれば添削します。
- それまでに先輩の修正を加えてもらったもの。
- 時間がないからできないけど、評価実験は何をしようとしていた。考えていない。データセットを作りましたといえるけどデータセットに対してはこういう評価をできるといいです見たいな文章を書いてもらえればいいと思います。
- 機能等価なペアが少なくなってしまったというのは、目で見たときにフィルタリングアウトしてしまったっていう意味？
- そもそも相互にテストを行ったペア数が少なくなってしまったことも最終的な結果が少なくなってしまったということ。
- 何を考察するのかよくわかっていない。考察になるかな。もともとのデータセットが良くなかった？もともとのデータセットは機能等価なメソッド向けのものではないから、データセットが悪いのは乱暴な気がする。選び方が間違っていたというのも、Ｃのコードに特徴的なことがあれば記述してもいいのかもしれない。今はあんまり書ける事ないのではないかと思う。

# 2025/1/30
## ry-inoue
- いつ返っててくるの？
- 見た方がいいところはどこ？TOSEMからの変更点ある？
- 本提出の１週間前に投げる→OK
## tk-kawam
- 死んでるか？
## simizu-s
- 原稿の修正がんばって
## ta1-kmr
- 原稿はあふれそうだからって書くのやめるのはなしで、あふれた状態で見せてください。
- その後削るのが肥後グループ流儀である。
## a-yamank
- 表書かんでもよろし、
- 論文を見ればうまくいったパターンがわかるのでは？
- なんでRepairAgentにしたの、先生が言ったから。
- べつにRepairAgentが動かすのはゴールではないので、とにかく早く出るのはあるってこと？
## m-kunagi
- 実験は全部終わった。
- 評価実験（作成したデータセットを用いて評価をするやつ）Pythonは動作が遅い言語だからそれをやった。CはPythonのトンデモ倍早いから。
- LLMの学習にするというのはいいけど時間が足りひんかな。
- SQLのデータを作るように、めっちゃ簡単ならSQLite。ちゃんとやるならPosgresql？とかかな。ちょっと敷居が高いと思う。
- 現時点で何ページ？ 15ページ、卒論は大体30ページを目指してほしい。

# 2025/1/23
## ry-inoue
- 博士後期の口頭試問で，もう1個テーマを話せる？博士後期を進めるためのロードマップのようなものを出せるといい．
## tk-kawam
- 発練の日程は個別で決めさせて。
- 書くのに集中したほうがいい。
- 修論ゼロ～。うん頑張ってください。
## simizu-s
- Weaklyはいいと思う。StrongType-3がType-4になったものも被験者実験の対象にした方がいいんじゃない？
- 100個集めるなら50個50個じゃない？
- まにあうんかな。火曜日には間に合わせるんじゃない？被験者には声かけたほうがいいんじゃない？
- 分身できないから、どっちか朝の十時までとかできる？tk-kawamと相談
- つーるって 完全にできた？できたと思う。OK。
## ta1-kmr
- 次版はいつ？5が〆切だよね。6の朝だよね？火曜の午前10時ということで、間に合わなそうならできているところまででいいので。
## a-yamank
- RepairAgentの環境建築は修論テーマとは別？→直接は関係しないだろう．ワークスペースで作業している．
- 動くようになったら呼んでください．一緒に見よう．
- 1つのグループ？別のグループによる研究？(一つの研究グループがずっと取り組んでいるのか，別々のグループが取り組んでいるのかに興味があった．)
## m-kunagi
- 内部の処理が違う。参照渡しだと出力が同じでも内部処理が違う場合がある。
- ポインタで与えられている場合はてすとのところに 日本語で記述するのがいいと思う
- 結果はどういうふうに保存している？SQL使ったことある。Execlでやってる。これを他の人に使うようにした方がいいのでSQLの方がいい。
- ちなみに判断に困るケースはどれくらいあった？5個ぐらい、あ、まあそれならいいか。
- 卒論はM1のひとに見てもらうようになっている。日程を決めるように、焦らないので、
- 170個で9時間半、何個のクローンペアに対してどれくらいの時間がかかったか記述したほうがいいのでそうするように。

# 2025/1/16
## ry-inoue
- 井上先生に見てもらったら？
- 2/5口頭諮問の発表練習，本番の数日前で
## tk-kawam
- 389件の内345件の話は他の人のデータセット。他の人が作ったデータセットが間違っていたっていうこと？他の人の研究で使用していた荒いデータ。
- パラメータの一致度で場合分けで分けたのは何で、完全一致したもので追跡した。
- 何と何のパラメータが完全一致、リファクタリング当時のパラメータと現在？聞き取れんかった
- 追跡成功したもの280件で二つ分けた、追跡できたっていうのは長いもので11年追跡したっていうのはもっと短いものもあった？プロジェクトは複なので様々、
- リファクタリングされた位置はものによって違う。最新版まで追跡できたってこと？
- 追跡成功っていうのは最新までたどれたってこと？ちがう。。。
- リファクタリング後に一年でも追跡できたら追跡成功、途中まで成功した。

- 多分ね、リファクタリングの追跡ツールがナニヲしていてい何がしたいかの目的が見えないからよくわからなくなっている。by inoue
## simizu-s
- junitを入れてテストケースを入れてこういうコードを入れたらType2を返すべきだみたいなのをやってほしい。使う人が確認できるような。
- トークンがX＋ｙがあるとするとa+bならＴｙｐｅ２になるこれがx+1ならＴｙｐｅ３になる。これはType2になるべきでは？
- 変数はリテラルでもいい場合もある。少し細かい部分の調整が必要ある。テストケースを作ってもらってそれをもとに自分も考えてみる。Ｂｙ肥後先生
## ta1-kmr
- 独自要素の追加削減と機能の追加削減、独自要素も機能じゃん、独自要素はＬｏｇの出力を独自にしたいとか、まあ、機能といえば機能？がっちゃんこしてもいい気がする。
- 片方がforwardのものは取り除いている？はい、ならＯＫ
- 分類の仕方が主観が入っている。他の人が同じ結果になりそう？ちゃんとしたところに投げる時にvalityがないとダメかな。
- 開発者にどんな提言ができる。機能の追加削減がいい例かな。多すぎたら削っている？かいはつしゃにそれをお勧めする。それはBadPracticeにならないかな、しない方がいいよねと言えるのか。こうしたほうがいいよね。こうしない方がいいよね。というのはどっちでもいいけど根拠がないと査読者が困惑する。根拠が大事。
- 原稿の手法の部分は書いといたほうがいいよね。
- 6ページしか書けないからPythonとかはいらないかもね。
## a-yamank
- 休み
## m-kunagi
- 同一の構造を除く手順を飛ばしていた。Nicadを使ってフィルタリング。
- Nicadを動かすときのパラメータはどう設定した？Type3のクローンも検出しちゃう。多少の際を含んでいても見つけてします。対応の取れない行が含まれているものは削除しない方がいいと思う。そういう設定になっているようにしてほしい。フィルタリングしすぎているのではないかなと思う。そんなに実行時間は長くないと思うので、コマンドラインの引数で、どれくらいの類似度で判断するかを設定で気うはずだからそれを設定してもらって、
- もう少しフィルタリングされるものは減るんじゃないかな？
- Nicadの出力ファイルに%がかかれてなかったっけ？その％で取り除くとかでもいいけど、
- 論文で書くときに怪しくなっていなｋれ場良いのでそこをしっかり。
# 2025/1/9
## ry-inoue
## tk-kawam
- 389件のクローンはどうやって見つけたの？→コミットメッセージにdeplicatedが含まれる．クローンではなく，extraメソッド
- CodeMapperがうまく動かないのはなぜ？→CodeMapper自体が良くない．過去から未来のマッピング
- リファクタリングの分類は手作業で確認したの？→CloneTrackerの出力によるのもの
- Aに分類されていたら絶対に重複が関係する．Bに分類されたら重複が関係ないと言い切れるのか？→未確認
- 322個全てにやったら，いい結果が出そうなのが現状
## simizu-s
- Tree sitterを使う部分は完成したということか→完成した．
- 実行結果のグラフはリラベルと類似度の関係
- 前見せてくれた気がしたけど、別の方法でリラベルしたもので今の結果のリラベルした結果は見せていない。
- Githubをまた連絡してください。
- Finetuningはどんなタスクにする。
- FEMPDatasetでクローンの分類をやってみる。
## ta1-kmr
- NILによる検出が再実装の検出のために十分なのかが興味．これはわかるようになるのか？→大変．
- 0から実装していることが理由，というのは推測？事実？→推測．
- 再実装をした人は，ライブラリにその機能があることを知っているんだろうか？→知りながら自前で作っている気がする．
- この推測のもっともらしさを主張できる根拠が欲しい．類似度の低さを見るのがいいかもしれない．
- コピペされていないことが言えればいいなら，どの関数とも類似度が低いと言えれば十分かもしれない．
- 100個のクローンペアはどうやって持ってきたんだっけ？→関数の長い方から100ペア．
- forwardじゃないもの，を条件に加えたらどうか．→やってみる．
## a-yamank
- 前から同じこと言って無かった？できそうなのかできなさそうなのか。どうしたらいい僕はBy肥後先生いいい
- 他の延久のことを知らないんだよねそれを調べたらというアドバイス。調べてね。
- どうやって調べるのPrograming Repairから調べる？それは違うんじゃない？高田君が紹介している論文を引用している論文を見るべきじゃない？
- 手元で動かしてみて損はないので。やってみてもらて

## m-kunagi
- テストの生成が済んでいる段階で，テストの実行に80時間かかったってこと？→そう．研究室のコンピュータ．
- 重複したメソッドを含むペアならば，最も相互実行したテストの数が多いものを選ぶといいかも．数が多ければもっともらしそう．→もうやってます．→いいと思います．
- 機能等価でないのなら，どちらかのメソッドでしか通らないテストケースを作ってもらえるといい．
- 15時間の見積もりはどうやって計算を？→肥後先生の論文にある数字から計算した．
- 目視確認が終わったらその段階で見せて．

# 2025/12/26
## ry-inoue
- 後ほどミーティング
## tk-kawam
- method単位でも追跡が出来る？追跡しているときに変更されていても追跡が出来る？リファクタリングされて集約されたものがどれだけ変更されたか、何回変更されたかは取ってこれる？取ってこれない。
- 変更されてしまった場合、リファクタリングされたコードをマッピングできない。対応関係が取れたものを対象にしていいのか。
- 大きな変更がない場合のみが実験対象になるのではないか？変更が大きくされたものについてもTrackingできるならいいと思うけど。
- この部分で査読者がRejectすると思う。
## simizu-s
- fileのIOが問題なので、これを辞めてDBから直接取りましょう。９割ぐらいそれがOverheadになっていると思う。
- 少し結果の話し合いについて、実験結果が思ったものにならない可能性がある。なりそうな結果としてはType-3のほとんどがType-4になっていそう。
- それをLLMに読み込ませていい結果が出るかどうか怪しい。
- ほとんどがType-３がＷｅｅｋ、これがＴｙｐｅ４になっている。だからBCDのほとんどがtype-4になりそう。懸念は？
- 懸念は、分類を行うときに。。。わからん。後で相談しましょう
## ta1-kmr
- ２１０個のペアは見てはない。プロジェクトないのはない？
- ｃｌｏｎｅの検出の仕方がよくわからない。ライブラリとクライアントのそれぞれについてProjectを選んで実行
- ライブラリとクライアント間で10行以上が10ペア、ほとんどフォワード関数、コピペぽいかといわれると怪しいので、モデルの定義をするところ、これが似ることは自然なの？自然だと思う。
- フォワード以外の残りの4件は？コピペっぽいのはあった？あった。こぴぺっぽい理由を決めたほうがいい。
- どうしようかな？、コピペっぽいかが先に調べること。上位100件でもいいけどそのうち何件がコピペっぽかったか？
## a-yamank
- 休み
## m-kunagi
- テストの対象ファイルってなに？
- 実行するときに作成するファイル。GoogleTESTが作成するもの。？？？UTBotを実行する時ではなくテストを実行すると生成される。テストを実行するたびにたくさん出てくる。
- おけそれならいいかな。
- 相互実行をする対象ペアの数はいくつ？ペアの数を知りたいです。そのうちの何％ぐらいが出来ていたかわかる？
- 3％ぐらい。だけど１００個以上のペアがあったってこと。3%ぐらいで、そんなに実行かかっていない。
- timeっていうコマンドの後ろに普段のコマンドを付けると実行時間が出るよ。
- どのくらい時間がかかったかは記録しておくこと。
- 関数Aと関数B、Cがペアになっている。このペアがすべて実行されると、A-B A－CとかAばかりが出てしまうとデータセットとして微妙だと思う。一つの関数が目視対象として何回も出てこないように優先付けをした方がいいと思う。
- JavaのFEMPDatasetで実行したので、確認してもらえると優先付けの話が載っているはず。

# 2025/12/19
## ry-inoue
- TOSEMの方を修論にすればいいと思うけど，どう？→そうします...．
- 来週の肥後先生は22と23か23と24？二日連続して潰れてる．26が一番空いてる．
## tk-kawam
- データセットの構築？既存の研究のデータ。
- 手元で既存研究のデータベースを再現する必要がある。
- データベースが配布されていない。手元で作ったデータベースがちゃんとできたか確認できていない。
- WSSEは？書いて？
- じゅりされたらアーカイブ。
- Extractリファクタリングされたもの。何件のデータ？わからない？論文の中では何件なの？
- データセットを使うことは否定しないけど、リファクタリングのデータ数が十分か考えないとダメじゃない？現状、13件のリファクタリング、、、多くねその数字、調べてください。下調べ
- 苦労してデータセットを構築しても無駄になるのではない？そこを調べよう。
- 何件あればいいの？10件だったら足りないよね？何件？800件ほどあればいい？自分で目で見ていく？クローンのExtractyメソッドのインスタンスが見つかったら、それが実際に修正されているかめでみる？コードトラッカーを確認する。
## simizu-s
- 公式とサードぱーていの違いって？公式の方が環境構築がめんどくさい。Tree-sitterとJavaのパーサーのライブラリをインストールしなきゃいけない？
- パーサを用意しなくても、サードパーティはいける。
- 動かすまでの違い？動作は一緒、ならOK。
- 分類とTreeの類似度の数値が幅がありますよって言っているだけ、古いラベリングを使ったときと新ラベルとのひかくで、新ラベルが有効であると言いたいr。古いラベリングを使ったものと比較して新しいファインチューニングの方がいいと思うということ？タスクはぱっと思いつかないけど何かしらのタスクを思いつかないといけない。
## m-kunagi
- 一つのシグネチャーにつき？？？？？？
- 知りたいのは何個の関数に対してテスト生成が出来た？7300個。この関数たちには最低でも1個のテストが生成されている。
- utbotを使ってテストと生成をした時って、対象テストのカバレッジは何パーセントが出る？一つ生成されているというのはテストの質として低すぎる。ちゃんとテストされていないように感じる。
- 十分じゃないものをテストに使っても有効ではないのでは。その担保が欲しい。生成されたテストケースが対象の関数の何％実行されているのかの数値が欲しい。
- 7300個のテストを生成できた関数は、何個のペアに対して実行しないといけない。組み合わせは？一つのシグネチャに対して100～200ぐらい？？一つのシグネチャ内で何個の関数にテストを生成できたかによって相互実行しなければいけないかがわからない。
- 時間がかかるかもしれないけど相互テストを実行できそうと思ってる？はいＯＫ．
- 優先度をつけると目で確認するときの優先度をつけられる。

# 2025/12/15
## ry-inoue
- 明日の個別はラウラ先生と？→そう．
- 結構いい割合だと思う．全部見た時に言えることはあると思うが，目視確認で何を確認するのか予め決めておくといいと思う．何を見るか決めたら見る価値はある．
- 数を落として別のプロジェクトを見た方がいい
- 500件を何かしらのソーティングを行なって上位10件を見る
## tk-kawam
## simizu-s
- arXivはできた？→できたっぽい．
- ニュース記事はまだ？→まだ．
- ツリーシッターは難しい？難しいなら諦めてもいいと思うんだけど．
- 清水さんの環境で動いても，他の人がこのツールを使えなかったらよくないと思う．肥後先生が自分で試したことのあるツールではない．引き際の判断も自分でしてみてほしい．
- ツリーシッターが動いたら何するの？→Type-3の3つの分類について，ASTによる分類がどうなるかみてみようと思っている．
- JDTでなら葉の除去はできている．
- ツリーシッターは多言語対応．多言語対応が強み．
## ta1-kmr
- どのバージョンに依存してるのかとか書いてあるんじゃないか？最新を持ってこればいいだけだろうから簡単じゃないかな．
- サクッとやろう．
## a-yamank
## m-kunagi
- コンパイルが通って，テストに通ったのが8万いくつってこと？→そう．
- グループ数は？1400グループくらい(１個しか含まないものもある)．

# 2025/12/8
## ry-inoue
## tk-kawam
- CRDが提案されたクローンはメソッド単位ではなくコード片単位のもの、これを対象に作成された。今は関数単位である。だから相性がよくない。
- NiCadは関数単位ではない？ブロック単位にしている？ほとんどがブロックたいんじゃないかな～。
## simizu-s
## ta1-kmr
- 1か2の再実装の観点からの操作はおかしい？
- まだふわっとしているもう少し詰めて具体的にどうするのか決めてくれないと判断しかねる。
- 再実装が調査されていないのが新規性？そう。たくさんありそうな予感がしている？ありそう。言語によるかもだけどjsはどうか怪しい。
- たくさん見つかりそうな言語を対象にしてくれればいい。
- Mtは？ラウラ先生も交えてしたい。スケジュールを調整したい。
## a-yamank
- OK～！
## m-kunagi
- UTbotはうまく動いた。テストが生成できない関数はある。今は何個試した？4個。これは動いた。OK。4つのプログラムからテストケースは何個出ていたか。これは大事な指標になるので保存すること。
- ビルドが失敗したかどうかはmakeの返り値でわかる。成功した時だけつぎのステップに進むようにしていこう。ビルドが失敗してもいいけど弾くようにしてしまえばいいかな？
- 何割抽出できそう。4割。はじかなくってすべての関数を実行すると遅い？遅いか。プロセスの起動時間が遅いから、マルチスレッドでやって。
- あまり根詰めないように。

# 2025/11/27
## ry-inoue
- 新規実装時に共通化している場合は，すでにあるコードが変更されているはず．新しく追加された部分と既存コードの削除された部分を比較したらわかる？
- 修論は困らないのでそれでいいです．もうちょっとトライしてみて
## tk-kawam
- 何を自動にするの？→コードクローンが発生した理由を知る方法
- 何をするかは書いてあるが，目的がわからない
- 解析をすることは手段じゃないの？起源を知ると何が嬉しいの？→どういうタイミングでリファクタリングすればいいかがわかる→現状ではタイミングがわかっていないの？
- やろうとすることは書くんだけど，なぜやろうとするかを書くべき．もっとわかりやすく書くべき．もっと背景を書くべき．
- リファクタリングをいつすればいいかがわかることはどんな嬉しさに繋がるの？わからないことが問題になるの？
- コードクローンがいつ発生したかわかれば，適切なリファクタリングのタイミングがわかるのは本当か？Anti〜はできるかどうかを述べているだけで，適切なタイミングかどうかの議論はないのでは？
- 過去のクローンについてはいつリファクタリングをすべきだったかはわかるが，未来についてはわからないのでは？
- 適切なリファクタリングのタイミングを明らかにするのがやりたいの？コードクローンの起源を調べるのがやりたいの？

## simizu-s
## ta1-kmr
- ライブラリとクライアント間のクローンを調べる研究はやめるの？→調べたらすでに既存研究がある．→論文を読んで結論は知っていた方がいい
- 興味のある方向で進んでもらっていい．
- JavaでやられていたならPythonなどの他の言語に応用できる可能性もあるのでは？
- Pythonはいつダウンロードされたかの情報は取れるの？どのバージョンがいつダウンロードされたか
- 論文読み終わったら何する？→論文で解明されていないところの調査
- CSセミナーは前の内容を話すプラスアルファで今の内容も
## a-yamank
- 使っていいんじゃないの？使う可能性があるなら言ってくださいって言えばいいんじゃないの？
- 今からやろうとする研究は高田さんの輪講2本目の論文との差分があるの？手法としてやろうとしている研究と，論文の手法と違うの？
- 既存研究は状態遷移を利用していないの？次のミーティングまでに読んで理解してください
## m-kunagi

# 2025/11/20
## ry-inoue
- いいのが見つからなかった時の案を考えておいたほうがいい
- 調査の結果として報告するのも一つの手
- 微調整，解析はどれくらいかかる？→実行に時間かかる．１週間で終わるかは怪しい
- TOSEMのやつを修論にするのも手です
- 追い詰められてるわけじゃないので，まだ大丈夫ね？
- 来週のミーティングで結果が出せるといいよね
## tk-kawam
- 調査対象を広げると別の方法の調査を心みたいは別のことを言っている？
- 研究のテーマを変えるのはいい．それなら調査対象を広げるのはやらなくていいんじゃないの？
- Helperメソッドの対象は拡張するけどしないんだよね。おけ。
- リファクタリングマイナーはクローンに特化していない。そのリファクタリングに対してそれがクローンによるかどうかを判定するということ。コミット前後のクローンの有無で？
- リファクタリングのパターンごとに各条件を実装する必要があるのではあるのでは？実装のコストが高いのでは？
- 手動を自動にするところだけではなく、他に改善点があるのではないの？自動化するという安直に飛びつくのは良くないと思うよ。
## simizu-s
- くたびれ
## ta1-kmr
- コーディングスタイルって具体的に何を指してる？インデントの数とか中カッコとかが想起される．ブロックのネスト構造ってことだよね？
- 書き方の再利用って何？
- ライブラリの機能が欲しいのではないの？→機能の等価を見つけるのが難しそう．目視を避けたかった．
- ピンとこない、何が嬉しいのか。
- どういうときに構造を真似ているか、でその目的って何？ライブラリの機能を真似たいってこと？他の状況がある？ ⇒ 目的をちゃんと、変更するのはいいけど目的をちゃんと示せて何を見つけたいのか例を示せるように。
## a-yamank
- 安価なのよりはそのほかのコストの方が大事そう（AutoCodeRoverの論文の話）
- コンテキストって何？
- LLMのブラックボックス解明は無理じゃない？一人でやるには無理では？大きすぎる．中の話ではないのか，Agentの話か．それは高田君の論文に帰着するのでは？→被りそう
- 研究としては成り立つと思うよ．できるかどうかはおいといて．何かしらの貢献があれば．
- 高田君にもう一度確認をとったら？多分被らないと思うよ．Agentでいいんじゃ？
## m-kunagi
- 対象のプロジェクトの数，行数は？→6000プロジェクト
- 変数と返り値のペア→シグネチャの数，ペアの種類の数
- 5050は何を表す？→シグネチャの数
-

# 2025/11/10
## ry-inoue
- Profesの原稿はいつ上がってくるの？→今日できれば今日．修論の方がやばそうだから，今日終わらなかったら改めて．
## tk-kawam
- 経過時間で様子を見る。単位でみる。
- それってさ、経過年数と共に見落としが増えるかどうか見たい。何で5年ごとにしたの。短い単位だとディスク容量が足らない。買ってください。
## simizu-s
## ta1-kmr
-
## a-yamank
- トップカンファレンスから持ってきた方が良い．確認しておこう．
## m-kunagi
- 関数の抽出ができて，戻り値と引数の方でグルーピングしたんだね．グループの数はいくつか？→１つしか含まれないグループを含めて300ある．２つ以上含まれるものも半分はありそう．
- グループの数が少ないと辛いし，１つしか含まれていないとどうにもならないから，グループ数は注視しておいて．
- ビルドは研究室のワークステーションだよね．それで再ビルドに2時間?ビルドの失敗を繰り返しているということ？これ何度もトライしているんだよね．
- utbotがC++非対応．C++のためにKLEEを直接動かそうとしている．
- データセットはCだけか！じゃあCだけ先やろう．KLEEはちょっと置いておこう．
- 次の1週間はutbotを使ってテスト生成，クロス実行をやりましょう．
- クロスで実行して，成功した数がいくつかもわかると良い．

# 2025/10/30
## ry-inoue
- 頑張って
## tk-kawam
- 写真とかはlab-adminがやります
- なぜヘッドが対象なの？現在の先頭なので，実験結果は日付も必要だよね？バージョンなどの区切りがいいところを使うんじゃないの？何月何日時点のヘッドは使わないほうがいいんじゃないの？
- ヘッドでも問題ないの？→過去のどこかの段階で再利用を逃しているから．最新のリリースでとったほうがいい？（ry-inoue）自分は最新のリリースの方がいいと思うけど、修正が確定した部分で区切る方がいいのでは
## simizu-s
- tree-sitter?って知っている？Githubで使えるParserを使った方が良いのでは。
- Javaじゃなくてもどの言語の木を作るというのを最初に指定すればいいっていう。軽量なので変数名のバインディングはできないけどそれの方が拡張性があるのでは？
## ta1-kmr
- どっちかからどっちかに派生したってわかってる？わからないけど実装時期からわかるかなと思う。どっちもある。GitBlameを使用すれば、どっちのコードが先に出現したかわかる。実際にコードがパクられた、派生したことが分かればいい。
- コメントの中にそういうものもあった。それいいやん。それを探すベースでもいける。クローンだけじゃなくてコメントで調べて再利用しているかを目視確認、関連研究がないかを調査したほうがいい。
- 全部やってみたらいい，まずは予約語から

## a-yamank
- 込み入った調査というのは，何をしたい？→まだ決めきれていない．
- 調査したいことがわからないのに環境を整えているの？
- TBarで対象にできるバグとkGenProgで対象にできるバグが違う
- 同一のバグを複数のツールで修正しようとしているのはなぜ？できる，できないを比較するため？
- APRのツールを一回試しに使ってみたら，ということを言った．
- TBarとkGenProgってどちらも古いツール．これらを(今更)比較したところでどうなるんだ？という話がある．
- 昨日高田くんが紹介した論文，あれ面白いと思うよ．どんな状態遷移を辿ったかを調べるってのはやってなかったみたいだけど，興味ある話だよね．嫌じゃなければ，これもどうか？高田くんに譲る気があるのか聞いてみたら．
## m-kunagi
- c++は入れたほうがいいと思う
- KLEEがうまく動かないんだよね，KLEEのバイナリがダウンロードできてすぐ動く，という話ではないんだよね．→KLEEがインストールされているDockerイメージがある．これを使った．
- aptを使うと，必要な依存関係を自動で導入してくれると思う．
- 通るのもあって，落ちるのもあった？(ちゃんと動いてそうか確認できてる？)→両方あった．

# 2025/10/23
## ry-inoue
- 原稿は投稿する予定のものが飛んでくると思っていい？→一旦英語化したものを見せる予定．どこに出すかは決めていない
- 何ページ？→二段組で8か10
## tk-kawam
- この後，発表練習
## simizu-s
- 80Gに収まる，ほんまかなぁ．
- 分類するプログラムは最終版ができていると思っていいの？どうやって確かめるの？→最終版．
- 他の人が簡単に使えるようにして欲しい．gradleのコマンドを打てばjarファイルがパッとできるようになっているか？
- 誰でも簡単に使えますよって修論の時に言えるといいね。
- そろそろProfesの発練いつするか？遅くとも2週間前には発練をした方がいい。プログラムがでて発表時間がわかったらスライド作ろうね。
## ta1-kmr
- Guoさんの修論に型推論のツールを書いてある筈、それを使えば型ヒントが出てくるからカテゴライズできるかなと思う。
- Javaの方優先でいいと思う。
## a-yamank
- なんのツールの環境構築？→ティーバー(つづりわからん)
- いろんな種類があって，その種類ごとに課題は違うんじゃないの？だから，動かせそうなものをとってこればいいんじゃない．
- 先週の輪講ってAPRじゃなかったよね，なんでAPRを選ばなかったの？他のものに興味があるならそれをテーマに選択すれば良かったんじゃないの．
- KGenProjが一番簡単だと思う(楠本研)．サクッと動かせるものを探せばいいと思う．
## m-kunagi
- どういう基準でプログラムを取ってきた？Githubからとってきた手で集めてきた。
- 最終的にデータセットを作る場合にはProjectの取ってきて関数を自動抽出している部分はある？Royが作ってくれている。あるからOK。
- Cの５つは難しめ？失敗したC＋＋と同じくらいの難易度のものである。処理は閉じているけどC＋＋は失敗した。KLEEはC＋＋だけ？Cでもできるなら、C++もCもKLEEでやれば？KLEEの方がテスト生成の能力が高ければKLEEだけでいいよね。楽じゃん。
- utbotとKLEEがテストをどう作成しているかは卒論で答えられないとまずい、ので調べたほうがいい。
- 自分で見比べてutbotとKLEEのどちらがいいか考えればいい。

# 2025/10/16
## ry-inoue

## tk-kawam
- 顕著だとその単体がこける頻度が多いと捉えられれう修正
- Type-1、でビルドが失敗する？
- コードクローンの種別は何でやっているの？データベースはどのような構成になっているか？考察が出来ていないんではないか？ー考察が全件出来ていない？これから調べる。これを全部見るの？見切れない？どうやって考察するの？いくつか取り出す？それで考察できるの？努力でカバーしようとしているのでは？それでいけるの？97件はミルの、比較はできないのではないの？Type-1だけで考察できるの？他のものも見る必要がある？エラーメッセージだけ取ってくることはできる？それを分類するとか？なるべく目視確認は避ける、楽にいこう。
- 国際会議の発練は？Olivier先生の方にはお願いしています。日程調整は後で、
## simizu-s
- すでにやったYEAH！
## ta1-kmr
- NoteBookLMの方がいい。
- デフォルトの値にしている。そこで数が違うのかなと思ったけど、デフォルトなら問題ないかな。Pythonのデフォルトの10行未満か5行未満かどれくらいが対象外になっているかは確認したほうがいい。python短いの多そうやん。
- 実例が欲しいかな。再実装された何をする関数だったのか知りたい。
- Javaは数が多いので考え物。ある一つの関数が複数のあぷりけーしょんと重複しているのでは？何重にもクローンになっているものは考えるといいのでは？
## a-yamank
- 読んだだけなのはちょっと、動かしてみよう。
- 論文の弱点や改善点を探していく方が良さそう
## m-kunagi
- 取ってきたプログラムはどのくらいの大きさ、まだ見てないか、いったん今は規模が大きくないもの。UtbotはC++も対応している？してるけどうまく動かない。すべてでできていない？抽出した一つの関数でダメ、原因はCでもあるのか？C++だけなのか？原因が言語依存ではなく根本にあるのではと主思うので確認して下さい。
- なるべく実験対象を多くなくていいので早く全部の工程が終わるように

# 2025/10/9
## ry-inoue
- OKです．
- SANERは出さないんだよね．
- 修論のこと，何も書いてないよね...．アハ．
- SIGSSのを修論にするのはあるけど，逃げの手やな．

## tk-kawam
-
## simizu-s
- ブロックの識別はできるの？できる．
- 単文の識別ができなくて困ってるということだよね．単文ならSingleStatementみたいなタグ(?)がついているんじゃないのか？
## m-kunagi
- 来週クロス実行できているといいな。
- utbotは最近更新がないからこういう状態？→そういうこと．
-

# 2025/9/26
## ry-inoue
- 変数名は精度に影響を与えてると思う
- いつぐらい？→結果は来週，論文は16の１週間前
- タイトルとアブストだけ先に見せて，９？
## tk-kawam
- 目で見た実験結果は良かった？→悪かった，1件しかないのはよくない
- ここでいうコードの再利用は何？→抽出されたメソッドが後で呼び出しされていれば
- メソッドの抽出はしたけど，再び出てこない，使用した形跡がない
- 全メソッド数→クローンセットの数
- クローンセットの要素数最大で→６〜１０
- 人間が新しく追加したコードが再利用できることをわかっていない．1件しかないのは見落としている？→見落としか，わざと見逃したのかを自動に判定できない．
- 調べる方法は思いつく？→新しく追加したコード片が既存のコードとクローンになるかを調べる．
- 何個存在するかのデータは得られる．調査の価値はある
- 先にTODOに書いてあることをやってもいい．任せる
- この間の論文誌はもう１ヶ月くらいで返ってくる．それまでに進めておいた方が良い
- WSSEのRegistrationをしておいた方が良い．お金足りなければ立てかる
## simizu-s
- この研究はツールを作る研究ではないよね．
- decrd?Baxter?川本君が知ってる。
- クローンのタイプ出してなかったかも
- どうやっているかを知らベる法はある。
- BigCloneBenchではどのようにラベル付けされていたの？
- 機能的に等価だろうメソッドをとってきたとは言っている．が，機能的に等価だろう，という部分に懸念点があるという話だね．BigCloneBenchの精度がどうあれ，再評価したらどうなったかを調べるのは良いと思う．んでもって別のデータセットを使うのも良いと思う．
## ta1-kmr
## a-yamank
- 頑張ってという感じ．
- 時間ができたらその時に研究すればいいと思う．
- 研究テーマがないということ？ないのなら，B4向けのテーマから誰も選んでいないテーマを選べばいいんじゃないかな．輪講で紹介された論文から面白そうなものを選んでテーマを考えてもいいと思う．
## m-kunagi
- 実行可能かってどういう意味？実現不可能なことをしているかもしれないと言われたの？そのコメントはどんな意図があったんだろう？実装できるかどうかを聞かれたわけだ．
- ロイはどうやって実装していたの？→ASTを使っていた．
- システムコールを使った関数を取り除くのはなぜ？OSが用意している関数のことを言ってるよね，OS依存だから良くないという話になったんかな．→テストに通らないと思った．
- 依存が全くないピュアな関数って一体どれほどあるんだろう？と思う．システムコールは依存関係の解決がいらないから，取り除く必要を感じない．
- システムコールにせよ，voidポインタにせよ，取り除くならばその理由が必要だと思う．実際にやってみたら理由は出てくると思う．まずはやってみよう．
- 実行可能かどうかの確認，1週間でできるといいね．
# 2025/9/19
## ry-inoue
## tk-kawamt
- カメラレディは添削しなくていいよ
- 何でこれをしてるんだっけ？
- リファクタリングケースが奪われる？
- 21件で1週間、それで一件。プロジェクトの数21件で1個のリファクタリングが見つかった。なぜ100件しないといけないの？21件が少ない？
プロジェクトはどのくらいの大きさ？21件は大小はばらばら？プロジェクトの規模を気にせず上から調べた。21件のうち ExtractMethodは何件？何割なのかわからんのかなあ？EtractMethodでクローンをとりのぞくリファクタリングは1件。リファクタリングマイナはExtractメソッドを検出。二つのExtractメソッドが検出されているならNicadを使用する理由はないのでは？リファクタリングのコードが一致していたらいいのでは？
NILが検出できなかったクローンはクローンとして扱っていないからよくないのでは？見逃しがあるのでは？RefactoringMinerだけでよくない？自動化できるよね？それで500プロジェクト流したら終わりでは？ソースコードのダウンロードに時間がかかっている？手元にリポジトリクローンしてないの？
NILを使わない行けない理由はない？ない。それで全自動でできる？それでも、それをすると一つのコミットで二つのソースコードが両方集約されていないといけない。
RefactoringMinerを使えないのであれば、代替案。進速度が遅く精度が悪いのでそれで使用できるかなと思った。がもういいのでは？RefactoringMinerを使う形でいいのでは？
関数オブジェクトを引数で受け取る関数を探すとRefactoringは見つかるの？関数オブジェクトとしてExtractしているものしか検出できないのでは？
代替案だと関数オブジェクトの形でリファクタリングしている場合に限れば、行ける？？？RefactoringMinerと関数オブジェクトはやっていることが違うのでは？とりあえずしないんだね？はい。
RefactoringMinerで検出して数十個ぐらい見つかるんじゃない？かな？
## simizu-s
- トークン分割の分類をしてもいい分類にならない？そもそもラベルの付け方がよく似という話ではない？
- トークン単位でのSimiralityの計算もよくないというわけではない？
- 行単位でやるとうまくいかない？
- トークン単位と行単位で計算するとよくないよね？
- ASTを用いて分類を行いたい？
- 表の説明は中間報告
## m-kunagi
- 個別で
# 2025/8/1
## ry-inoue
- 研究内容について個別でよければ
- 来週はいないのでお盆休みの後に個別ミーティング
## tk-kawamt
- ポスターって原稿いる？アブストです。
- 申し込むなら早めにホテル取っといた方がいいよ。
## simizu-s
- ASTでやろうとすると大変かも。
- スモールスタートで
- 9月の前半でMT？
## ta1-kmr
- 車輪の際発明になっているならプロジェクト独自の型を持つ可能性があるのか。ある。
- でも、線引きしないと。どこまでを見つける対象にするのかをちゃんとしないと、そしてその線引きがだとであると言えないと、それをちゃんと決めないといけないんじゃなかな？

# 2025/7/25
## ry-inoue
- OK

## tk-kawamt
- OK

## simizu-s
- 今日でもいい？4時か4時半ぐらいからMTで

## ta1-kmr
- 休み（別府いいなあ）

# 2025/7/18
## ry-inoue
## tk-kawamt
- 論文誌のチェックリストで確認してから送ってください．
## simizu-s
-
- 予期される結果と手元での結果は一致する？一部のデータだけでいいけど論文通りの挙動をしているか？バージョン違いとかで結果が変わっていると元も子もないから，確認しておくと良いと思う．
- 夏休みに入るまでに今後の方針をもうちょっと決めた方が良いと思う．
- 空白行で分割したデータセットをみて考えようかな、悪くなることってあるのかな？変わらないことはありそうだけど
## ta1-kmr
- プログラム依存グラフの本貸します
# 2025/7/11
## ry-inoue
- この後発表練習
- 論文誌早くていつ原稿できそう？→早ければ18，どんなに遅くても22の朝まで
## tk-kawamt
- CSセミナー気になる質問あった？
- 参照渡しに関するところ
- 現状はクローンペアだけ？→そう．
- 論文誌の原稿はいつ頃見せられそう？→再来週の週明け，22の朝？締め切り28だから結構ギリギリ，遅くても22日に
## simizu-s
- 多分すんなりは動かないかなあ（感想）
## ta1-kmr
- Python以外で車輪の再発明はなかった？→論文はc言語を対象にしている．他の言語でもある→他の言語は？というツッコミに対応できるように
- 呼び出されているところをnumpyに置き換えるだけではなく，動くかまで確かめた方がいい
- 来週の金曜日に発表練習
# 2025/7/7
## ry-inoue
## tk-kawamt
- OKです 問題ない
- WSSEの発表の資料を作ったらRaula先生かOliver先生にスライドの表現を確認したほうがいい。肥後先生を通さず，勝手にやってよろしい．
## simizu-s
- 興味を持ってやれそう？→やれそう．
- それでやれそうならそれでいいよ，夏休みまでに研究の大まかな方針を立てておこう．
- 具体的なやり方は見えているのか？→やり方は検討できているが，いい結果が出るかどうかはわからない．
- この後個別で．
## ta1-kmr
- ライブラリのコードとアプリケーションのコードの間でクローンを見る．ライブラリにあったら，アプリの方を置き換えられる．
- 関数全体を置き換えるものを対象にしてもいい
- 来週のどこかで個別

# 2025/06/27
## ry-inoue
## tk-kawamt
- 後、1カ月ぐらいで余裕でしょう
- 特に、言うことはないいいですねえ
- 書き換え失敗した奴については何で、どういう風な考慮を行えば成功するかは論文で必要。

## simizu-s
- 微調整、謎の空白
- 暴力反対

## ta1-kmr
- ぱっとSQLが出てこなかったのは実装の限界、二重のSQL文に対して探索的にできなかった？いやそれは大丈夫で論文の中にも明示的にネストされているクエリはあるので。
- とんでもない間違いでループが終わらない？後で確認。
- ネットからとってきたもののまんまは良くない。数字変えてみるなり必要。
- 見立ての方で、LLMに勝てなさそうな見立て。
- SQLとかラムダ式とか小さいのではなくてJavaのメソッドそのものを対象にしてもいいかも。開発者が書いたメソッドから入出力のペアをLLMに入れて、開発者が書いたメソッドと比較してリファクタリングするべき箇所を見つけてみましょう。
- メソッドを使用するならFEMPDatasetがいいかあ。

# 2025/6/20
## ry-inoue
- 最後の1週間(?)頑張ってね．
## tk-kawamt
- ソースコード解析のやつ？intが来たらとか？SQLとかのなにか？自動生成されたコードの場合ない？ソースファイルの先頭のところにGenerate by ～～とかない？
- 人がこのコード書く？キチ外じゃない
- こういう場合にはうまくいかないと、考察に書けばいいからあまり心配していない。
## simizu-s
- P値の計算が間違っていた。
- 命令分岐の方では一番端っこのところがEvosuiteの方がいいか検定してるんですけど、命令分岐だと言えない、分岐網羅率だと言える。SBFLスコアは手動テストの方がいいという結果
- めっちゃおもしろいやん。
- ネストが深くなるほど自動テストが良くないとは言いづらい。
- 結果はすごくいいのでは？人間が書いたテストはBranchCovは人間が書いたテストはEvosuiteに負ける。けどSBFLだと人間の方がいい。昨日の見込みではネストが深いほうが値が高いことを想定していた。
- ネストが1,2,3,4...7のものはそれぞれ何個づつあった？効果量の算出方法に要素の数が関係しているのではないか？要素が多いほうが効果量が大きくなっているのではない？箱ひげ図と矛盾するので、どこか間違っているのでは？
## a-yamank
## ta1-kmr
- いいやん
- 個人開発のSQLは一番長そう、実際のコードは一行。地獄。
- どっちにJoinさせるか、はどっちの方がいい？ClassにJoinした方が意味はあっている？
- Start End Day と順にチェックしているけどどれがいいんだろ。iとかcとかの情報は欠落してしまう。ほぼ同じ、
- テーブルのデータには工夫が必要.SQLを生成させるために必要な例をすべて出しておかないといけない．
## g-kimura
## g-kunagi
- ｃ言語とかで構造体だと出ないかも、
- 簡単なやつで出なかった。もうちょっと調べなあかんね。

# 2025/06/13
## ry-inoue
-　休み
## tk-kawamt
- 問題なさそうで良い．頑張って
## simizu-s
- クラスパスの問題を解消したらどのくらいケースが増えるの？→10〜20件ほどだと思われる．→有意差の有無にも変化が出そう？だよね．
## a-yamank
- 休み
## ta1-kmr
- 改行は自分で
- 定数になっても意味は変わってない？→変わっていない．SQL実行中に変数の値が変わることはないので一緒
- この結果はあまり良くないと思ってる？→そう
- 違うところをみると，例えばアスタリスクとか，見やすくなっているという利点がある
- 分かりやすいのはどっちかと言われると生成した方じゃない？，ASCを明示的に書いている方が親切．悪くない結果だと思う
- リファクタリングは双方向．必ずしも全員が元の方を好むとは限らない
- みんなが使っているリポジトリに含まれるしょうもないSQLの方が嬉しさはある．やってみたらいいよ
## g-kimura
- LLMの方が賢かったんだ．がは．
- プログラムの構造を変えないリクエストが通らないことがあるなら，LLMにも弱みはあるんじゃないのか？
- LLMは課金してる？→個人のもの．企業向けのものを使ったら変わるのかはわからない．
- 井上くんも交えて話した方がいいと思います．Slackでコンタクトを取って，来週早め(月火くらい)に話しましょう．ここで結論は出せない．
## g-kunagi
- 今はリモートデスクトップは繋がるの？→まだできていない．今日中にこの問題を解消した方がいい．Must
- 他のエラーは解消できそう？→川本さんに手伝ってもらう．今日中にエラーを解消できるといいけど．．．無理そうなら来週でもいい
- リモートでヘルプはどうしたらいいのか？→Slackのハドルで画面共有
- 研究希望調書はどうなっている？誰に添削してもらう？決まってる？→院試解答チャンネルに投げてもらう
- 院試優先で！
- 6月中までミーティングに来て

# 2025/06/06
## ry-inoue

- 2014年に似た考察をした気がする．あとで渡します．
- Gemini，金渡したくせにAPIあんま叩けないの，もっと渡せば叩けるようになるの？→そうではないみたい．
- Gemini，今回の実験はいくらかかったの？(興味)→1万も届かない．
## tk-kawamt
- 6月までに実験を終了させる
- それ以降は原稿に集中する

## simizu-s
- EvosuiteのFBSLスコアが高いのに網羅率が低いのは矛盾している気がするが，
- またあとで

## i-kondou
- groupE?に移動
- 頑張ってください．オリヴィエと仲良くやってください．
## a-yamank
- 欠席
## ta1-kmr
- 実験対象を増やそうしている感じがする。
- 定数結合や文字列結合がないものを見つけてくるのは難しい？
- 研究会までに対象を増やすのはやめたほうがいいと思う。
- 実行できるSelect分は何個ぐらい？
- 手動で見つけている、プロジェクトで回したらSelectを見つけてくることはできると思う。
- 文字列として取ってこれると思うからSelectとGroup byとかで検索して持ってこれるのでは？
- || は文字列結合、これを含んでないものを条件にして、なるべく目で調べる量を減らして、Pad何とかを改変せずにいい感じのSelect文を実行できる。
## g-kimura
- 元々，既存の手法で型がうまく復元できない場合でも型を復元できるようにするのが目標じゃなかったか？
- 型情報がおかしくなっているのはどれなんだ？→それぞれの分類について良し，悪しとはっきり言えない？？

-

## g-kunagi
- エラーの種類がたくさん、
- tk-kawamに頼りましょう

# 2025/05/30
## ry-inoue

## tk-kawamt
- 今日だけがんばれ、終わったら休憩で

## simizu-s
- 休み

## i-kondou
- 結局LLMに依存した結果になっちゃって，萎えちゃわないかなって心配がある．
- SZZで精度の高低に言語間の差はあるのか？→それが主題の研究は見てない．
- ある変更があったときに，二重に変更があったら誤って検出されるみたいな話があったよね．変更を複数のコミットに分解するような研究はあるかな．タングルドコミットをどうにかする方法．コミットを分解するような方法はある．
- あとはSSZから離れてフレッシュに新しいものをやるのもいいと思うよ．気持ちも新たになると思います．→Gitを使ったリポジトリマイニングには興味がある．→研究のネタは色々にあります．探してみてね．
## a-yamank
- 休み

## ta1-kmr
- JSQLParserは実行可能かを調べるの？正しい構文かどうか調べるの？→構文のチェック．
- そのプロジェクト内を探せばCREATE TABLE文もあるかもしれないよね．この辺をまとめてLLMにでも聞きながらやれば実際にテーブルを作れるよね．サンプルのテーブルを作って，SQLを簡素にするツールを使って簡素にする前後のSQL文を使ってうまく動いているか試してみてはどうか．
- PatSQLはSELECT文にしか対応していない．何かSELECT文を見つけて，1つでいいんでやってみましょう．
## g-kimura
- 表から読み取れる大事な事項は文章で書きましょう．
- 元からany型なのはそもそも対象外でいいんじゃないか？
- 1週間かけてやるのは長すぎるように思うので，このあと相談しましょう．
## g-kunagi
- UTBotのダウンロードは終わったんだよね．元々これは単体で動かすツールだと思うけど，動かした？→動かしていない．→まずはgen_test.shを使わずに単体で動かしてみて，UTBotがインストールできていることを確認しましょう．
- 願書！やりましょう．

# 2025/5/23
## ry-inoue
- 休み
## tk-kawamt
- 原稿は一度grammarlyに通したものをください
- grammarlyよりはchatGPTの方がいいかも
- どっちも通してみよう
## simizu-s
- 個別はグループミーティング終わりくらいで
- フォーマットを早めに変換しておいた方が良い
## i-kondou
- 5月中には投げられるか？
- 来週出してください
## a-yamank
- しばらく休み
## ta1-kmr
- 逆に言うと425行目はこのまま？→そう
- Javaの中で文字列結合が起こっているととってこれない→難しい，静的解析でとってこれない．なしでいい，これだけで一つの研究になりそう
- SQL文が正しいかを自動的に判定できるか？実行できるかの判定を自動でできれば，できるもののみをとってこれる
- 実行はできるが，書き方がいけてない奴を見つけられる
- どれくらいの割合が文法的に正しいかを数字で示せるように
- スモールスタートで，少しの数でいいので
## g-kimura
- コンパイラが動作するとどうなる？→変数の一覧と型が表示される．変換前後の変数と型の比較を行うことで，型情報が失われたかを調べることができる
- 文法があるから愚直に比較できない．
- 構文が変わることがあっても，変数の名前や数が変わらないからタイプチェッカーを使えると言ってる？JSとTSの間には型の違い以外にも文法の違いもあるんだよね，変換しても変数の名前や数は変わらないということか？これを説明してくれないと伝わらないです．
- そもそもそんなことをせずとも元のTypeScriptとTS->JS->TSの変換結果はダメなのか？だめなんだよね．
- TSとJSを比較するのか？TSとTSを比較するのか？→TSとTSの比較．
- この調査にはあまり時間をかけて欲しくはない．今は忙しいのか？→インターン等で忙しい．
- TypeScriptのコンパイラオプションの選択の仕方も色々あるのでオプションの選択に時間がかかり，困っている．
- 型情報の調査結果は，来週中には出そうか？→わからない．
- 今，とりあえず予備的な調査として数字が欲しい．正確さではなく，早く数字が欲しい．適当なパラメータでいいから，どのくらい型情報が落ちているか出して欲しいということです．
## g-kunagi
- ノートパソコンでやるんじゃなくて，サーバを使おう．ノーパソ壊れちゃうよ．今日，管理者権限もらおう．計算機の人，よろしく．
# 2025/5/16
## ry-inoue
- 休み
## tk-kawamt
- 締切は？5/30
- 過去の論文を見るとACMのフォーマットで５〜７pの論文が多い
- ガンバって
## simizu-s
- カバレッジを測定するためにビルドする必要があるってことだよね，Ant使うのは簡単なはず．ant buildって打つだけでできると思う．
- 心配なのはantのバージョン．今メンテされてるかな，どのバージョンを使うかが大事．
- 現時点で対象(プロジェクト)はいくつ？→全部実行できたら64+106
- 64+106の中にantのも含まれる？→antを含めないと約半分．含めれば全て対象にできる可能性．
- 来週までに実験が終われるといいね．
## i-kondou
- 僕(肥後先生)がやるのって細かい表現の修正とかだよね．今更構成のことを何か言っても何だよ，だよね．→一章が長いのが気になってる．→後で相談しよう．
- 早く終わりたいね．
## a-yamank
- 休み
## ta1-kmr
- 元の研究ネタのゴールって何だっけ→与えられたSQLが複雑か判定する．
- ソースコード中に記述されているSQL文を簡単にする話だっけか．
- ソースコード中のSQL文はどうやって見つけるの？→サンプルを見つけるところは手でやるつもりだが，自動化のアイデアはない．→Javaを対象にするならソースコード中のstringを抽出して，grepをかけるとかするといいと思う．正確に抽出するんじゃなくて，候補を集めてこればあとは目で見ればいいんじゃないか？(ソースコード全部から探すよりはまし)
- ソースコード中のリテラルだけ持ってくるといいと思う．後で話そう．
## g-kimura
- ts-migrateは時間がかかる？→調べるのに時間がかかってる．
- 型情報をチェックするアイディアは今あるか？→ない．→目で確認はできないと思う．
- 型情報が落ちるほか，違う型になってしまうこともあるだろう．
- 型情報が落ちるだけなら1行1トークンにしてdiffをかければ分かる．構文が変わるならそうはいかないだろうね．構文が変わるかは保証されるんだろうか？
- TS,JS間の書き換えのルールを調べるといいと思う．
- 憶測の部分を潰していきましょう．困ったことがあればミーティングまで待たずに僕でも井上くんでも聞いてね．
## g-kunagi
- 渡した論文には既存のデータセットの一覧が載ってたよね．CやC#は少なかったはず．それは越えないといけないってことだね．
- Royのは大体理解できた？Royのを使い回した方が早そう？→使いまわせそう．→いいね．
- メインは院試終わってからだから，無理せず，輪講と院試優先でいいからね．

# 2025/5/9
## ry-inoue
- 実験結果がこうなった理由は言える？
- 想像の域を出ていない，考察には弱い．難しいよね
- こういう結果になったから，この結果がこう利用できますよと言えるといい
- 今日中に申し込みとアブストを，タイトルは要相談

## tk-kawamt
- デスクトップに乗ってるのはSSDではなく，HDDでは？そのせいで実行が遅い
- テストに時間がかかる→ファイルの読み出しに時間がかかっているのか？
- 容量少ないならSSD買ったら？今日この後すぐ注文しよう，軽部さんへ
- 文章書く締め切りは守るべき，自分で言った締め切りは守ること

## simizu-s
- Defect4jがJava11でコンパイルできるけどEvosuite未対応、
- Defect４jのJava11とJava8ではないが違うの？Java11ではコンパイルできるけどJava8ではコンパイルできないとかありそうだけど
- なんでJava8にしたのか示せればいいんじゃない？
- それプラスで実験する必要ある？2倍になったけど？ いいんじゃない？LangとMathは外部パッケージに依存していないから。
- 次はどうする？PORFESに出そうとしてる。12月か

## i-kondou
- 来週の月火木は使い物にならないので、水曜日までに頑張ります。
- 早く出したいです。
## a-yamank
- それができたらどんな嬉しさ(直接的に何に役立つか)があるかを言えたらいいんじゃないか．
- 抽象的な嬉しさでなく、具体的に
- また、個別は連絡
## ta1-kmr
- 論文の実装は手元で動かせた？→まだ動かせていない．
- 動かせるんなら再度実装しなくていいと思うけれど→Pythonで動かしたいから→それならそうか．でもPythonってすごく遅くないか？即座にSQLが欲しいから速度を考慮するならPythonはどうなのか．(まぁでも任せるわ)
- とりあえずSQLiteの方が簡単だと思います．
## g-kimura
- ts→jsの変換はすんなりいくと思っていたが違うのか？→リポジトリのファイルが不完全である可能性がある．
- 最新のコミットをとってくるのは良くない，最新のリリースをとってきた方がいい
- 一つのTypescriptのファイルは必ず一つのJavascriptファイルに変換されるのか？そもそも調べておく必要がある．ファイル数が一致しなければならないのか？
- jsからtsへの変換は先行研究があるのか？既存のツールは動かせるのか？→まだ動かせていない．
- まず1つだけやろう．一番上のリポジトリでまず調べよう．
- 基本的に１対１対応になるはず．できないのはファイルが壊れているか，型情報が落ちて変わってしまった
- 例を見ると型情報が落ちてるだけのようには見えない．厳密には型情報を落とすだけと言えない？落とす時に何が起こるのかを明確にする必要がある
## g-kunagi
- 機能等価メソッドデータセットの論文の後半はあまり読まなくてもいいと思う．どうやって作るかさえわかれば十分．
- Royのコードは完成していないの？→Todoで残っていたものがあった．
- あなたの得意な言語はある？得意なものがあればそれでやればいいと思う．使い回しを否定するわけではない．得意なものでやれたらそれがいい．
- 目視確認の前にするテスト生成を工夫する等の方法を模索したいということだね．
- UTBotを動かすのはRoyも苦労していたと思う．困ったら連絡してください，
- 願書の研究希望調書を書く必要がある．それが書けるくらいには研究が進んでいると良い．