--- a/paper/chapter/03-gears.tex	Tue Feb 16 14:23:37 2021 +0900
+++ b/paper/chapter/03-gears.tex	Tue Feb 16 14:33:25 2021 +0900
@@ -388,7 +388,7 @@
 現在のGearsOSでは、 CMakeによるコンパイル時にPerlで記述された\texttt{generate\_stub.pl}と\texttt{generate\_context.pl}の2種類のスクリプトで変換される。
 
 これらのPerlスクリプトはプログラマが自分で動かすことはない。
-Perlスクリプトの実行手順はCMakeLists.txtに記述しており、 makeやninja-buildでのビルド時に呼び出される。(ソースコード \ref{src:cmake1})
+Perlスクリプトの実行手順はCMakeLists.txtに記述しており、 makeやninja-buildでのビルド時に呼び出される(ソースコード \ref{src:cmake1})。
 
 \lstinputlisting[label=src:cmake1, caption=CMakeList.txt内でのPerlの実行部分]{src/cmakefile.1.txt}
 

--- a/paper/chapter/04-interface.tex	Tue Feb 16 14:23:37 2021 +0900
+++ b/paper/chapter/04-interface.tex	Tue Feb 16 14:33:25 2021 +0900
@@ -68,7 +68,7 @@
 
 このSynchronizedQueueはGearsOSではDataGearとして扱われる。
 Interfaceの定義と同等な型定義ファイルが、 実装の型については存在しなかった。
-従来はcontext.hのDataGearの宣言部分に、構造体の形式で表現したものを手で記述していた。(ソースコード\ref{src:singleContext.h})
+従来はソースコード\ref{src:singleContext.h}に示すように、 context.hのDataGearの宣言部分に、構造体の形式で表現したものを手で記述していた。
 \lstinputlisting[label=src:singleContext.h, caption=cotnext.hに直接書かれた型定義]{src/singleContext.h}
 
 CbCファイルからはcontext.hをインクルードすることで問題なく型の使用は可能である。
@@ -171,19 +171,19 @@
 ほとんど返す値はInterfaceの時のものと同様であるが、 Implの場合はisaキーに、実装しているInterfaceの名前が格納される。
 
 この情報はパース対象がInterface、もしくはImplementでなければ返さない。
-パーサーはInterfaceであるかどうかを、構文の正規表現にマッチするかどうかで確認をする。(ソースコード\ref{src:IsInterface})
+ソースコード\ref{src:IsInterface}に示す記述で、 パーサーはInterfaceであるかどうかを、構文の正規表現にマッチするかどうかで確認をする。
 \lstinputlisting[label=src:IsInterface, caption=Interfaceであるかどうかの確認]{src/IsInterface.pm}
 
 \subsection{詳細なパースAPI}
 parse APIはシンプルな結果を返していたが、 Interfaceに定義しているCodeGearの引数など、詳細な情報を取得したいケースがある。
 Gears::Interfaceに、詳細なパース用のAPIである\texttt{detailed\_parse} APIを用意した。
 先ほどのStack Interfaceをパースした結果をソースコード\ref{src:parsedStackDetail}に示す。
-新たな情報としてcodeNameが連想配列の要素に追加されている。(ソースコード2行目)
+新たな情報としてcodeNameが連想配列の要素に追加されている(ソースコード2行目)。
 codeNameはCodeGearの名前がキーになっており、valueとして引数の文字列情報が\texttt{args}に、、 Interfaceの呼び出し時に必要な引数の個数が\texttt{argc}に設定される。
-これらの情報は配列codesからもアクセス可能となっている。(ソースコード48行目)
-Interfaceが持つDataGearの一覧は、配列dataに格納される。(ソースコード62行目)
+これらの情報は配列codesからもアクセス可能となっている(ソースコード48行目)。
+Interfaceが持つDataGearの一覧は、配列dataに格納される(ソースコード62行目)。
 
-OutputDataGearがあるCodeGearの一覧が、 hasOutputArgsに格納される。(ソースコード68行目)
+OutputDataGearがあるCodeGearの一覧が、 hasOutputArgsに格納される(ソースコード68行目)。
 codeNameと同様に、CodeGearの名前がキーとなっている。
 対応する値は、 出力する変数の名前と、その型の組のリストになっている。
 
@@ -211,7 +211,7 @@
 このサブルーチンでは、ヘッダファイルを起動時に全探査し、 すべてパースを行う。
 4行目でGears::UtilのAPI呼び出しをしているが、 このAPIはGearsOSで使うヘッダファイルを、指定されたパスから再帰的に探索するものである。
 
-なお同名のヘッダファイルが見つかった場合は、 変換をしているCbCファイルと同じディレクトリにあるヘッダファイルが優先される。(ソースコード 13行目)
+なお同名のヘッダファイルが見つかった場合は、 変換をしているCbCファイルと同じディレクトリにあるヘッダファイルが優先される(ソースコード 13行目)。
 \lstinputlisting[label=src:createHeaderName2Info, caption=ヘッダファイルの名前とInterfaceのパース結果の対応リストの作製]{src/createHeaderName2Info.pl}
 
 \section{Interface定義ファイル内でのincludeのサポート}
@@ -221,7 +221,7 @@
 この為Interfaceで別のヘッダファイルの型を使いたい場合は、手動でcontext.hに\texttt{\#include}文を書く必要があった。
 
 これらのinclude処理を、Perlトランスパイラ側で自動で行うように実装を行った。
-これに伴い、Interface、Implの定義ファイルで使いたいヘッダファイルをinclude文で指定することが可能となった。(ソースコード\ref{src:SingleLinkedQueueInc})
+これに伴い、Interface、Implの定義ファイルで使いたいヘッダファイルをinclude文で指定することが可能となった(ソースコード\ref{src:SingleLinkedQueueInc})。
 \lstinputlisting[label=src:SingleLinkedQueueInc, caption=Include文を書けるようになったImplementの宣言]{src/MCWorker.h}
 
 \section{Interfaceの実装のCbCファイルへの構文の導入} \label{sec:newInterfaceInCbC}
@@ -274,7 +274,7 @@
 
 generate\_stub.plはソースコードの情報を読み取るフェーズと、変換した情報を書き込むフェーズに別けられる。
 まずは読み取りの際の処理をソースコード\ref{src:replaceCodeGearName1}に示す。
-generate\_stub.plは、CodeGearの宣言時に、自分が今変換しているInterfaceのImplのCbCファイルかどうかをまず確認する。(ソースコード6行目)
+generate\_stub.plは、CodeGearの宣言時に、自分が今変換しているInterfaceのImplのCbCファイルかどうかをまず確認する(ソースコード6行目)。
 ImplのCbCファイルであった場合、変数\texttt{\$implInterfaceInfo}に具体的な値が入っているため、if文に進む。
 if文の中ではInterfaceのパースの結果と、今定義しているCodeGearの名前を比較する。
 ここでInterfaceのAPIであるCodeGearの名前と、今CbCファイルで定義しているCodeGearの名前が等しい場合、後ろに型名をつけたCodeGearの名前に変換し、スクリプト内で変換したことを記憶する。
@@ -442,7 +442,7 @@
 パースした結果の情報に、 各CodeGearの引数情報と引数の数を取得できれば、それらとAPI呼び出し時に与えられている引数を比較すればチェックが可能である。
 現状は引数の数が揃っているかどうかで確認をしている。
 
-Intefaceの引数を確認し、Gearefマクロを生成しているgenerate\_stub.plの箇所に、引数の確認処理を実装した。(ソースコード\ref{src:parsedArgs})
+Intefaceの引数を確認し、Gearefマクロを生成しているgenerate\_stub.plの箇所に、引数の確認処理を実装した(ソースコード\ref{src:parsedArgs})。
 ここでAPI呼び出し時の引数は、\texttt{\$tmpArgs}に代入されている。
 CbCの関数呼び出しの引数はカンマで区切るので、2行目でカンマで文字列を分割し、引数を配列\texttt{@args}に変換している。
 
@@ -491,7 +491,7 @@
 CodeGearをすべて満たしていなかった場合はエラーを出したい。
 
 ソースコード\ref{src:notDefInterfaceAPI}は、Interfaceが要求しているAPIを実装したかを確認する部分である。
-変換しようとしているCbCファイルが何かのInterfaceを実装しようとしている場合、 Interfaecの定義ファイルのパース結果から、満たすべきCodeGearの一覧を取得する。(ソースコード1、2行目)
+変換しようとしているCbCファイルが何かのInterfaceを実装しようとしている場合、 Interfaecの定義ファイルのパース結果から、満たすべきCodeGearの一覧を取得する(ソースコード1、2行目)。
 実装していた場合は6行目でマークをつけ、 マークがなかったCodeGearが検知された時点でエラーを発生させる。(12行目)
 \lstinputlisting[label=src:notDefInterfaceAPI, caption=InterfaceのAPI呼び出し時の引数エラー]{src/NotDefine.pl}
 
@@ -515,7 +515,7 @@
 処理を実行するとInterfaceの値をStubCodeGearで取り出す際に、初期化をしていない値をとってしまい、 セグメンテーション違反が発生する。
 この問題は、Gearefマクロを利用して作製したpar goto用のContextの引数用の保存場所に、それぞれ実装のポインタを書き込むことで解決する。
 
-ソースコード\ref{src:pargotoPhil3}では、par goto作製したContextであるcontext{\textgreater}taskに、 Gearefマクロを用いて引数としてPhilsのインスタンスを代入している。(ソースコード3、 15行目)
-またthinkingの引数はCodeGearが必要であったので、これもnextに設定している。(ソースコード4、 16行目)
+ソースコード\ref{src:pargotoPhil3}では、par goto作製したContextであるcontext{\textgreater}taskに、 Gearefマクロを用いて引数としてPhilsのインスタンスを代入している(ソースコード3、 15行目)。
+またthinkingの引数はCodeGearが必要であったので、これもnextに設定している(ソースコード4、 16行目)。
 この処理は、generate\_stub.plで、 par goto時にInterface呼び出しをしている際のパターンを新たに実装し、Interfaceのパースの結果から得られた引数に書き込む様なルーチンで実現している。
 \lstinputlisting[label=src:pargotoPhil3, caption=改善されたInterface経由でのpar goto]{src/ParGoto3.cbc}

Binary file paper/final.pdf has changed

Binary file paper/master_paper.pdf has changed