本当は怖いHPC

HPC屋の趣味&実益ブログ

GreenScheme(2)

勢いでGreenSchemeと名付けた処理系の制作日記。

本当にただの日記になってしまうけど、ここ数日地味にゴリゴリ書いていた。バイトコードアセンブリ言語レベルでクロージャの作成と起動とかまでできるようになった。構文解析を全く書いていないので、Schemeの面影は全くなく、ここからいきなり突拍子もない言語の処理系になる可能性も!!!(ありません)。


(以下、面倒なのでGreenSchemeによるバイトコードアセンブリ言語のことをgrasmと呼んでいる)

ユニットテストを書きまくる時期

自分でもなかなか驚くのだが、ここまで(だいたいコードサイズは3000行くらい)ユニットテスト無しでコードを書いてきた。というのは、普通のユニットテストフレームワークは使いたくなかったので、自作のテストフレームワークを作る必要性に迫られるまでユニットテストを先延ばしにしてきたのだ。


なぜCppUnitなどの既存のテストフレームワークでは駄目なのかというと、理由は大きく分けて2つあって、

  • C++による処理系の部品のテスト、grasmの処理系としてのユニットテストSchemeの処理系としてのユニットテストなど、いろいろなレイヤーのテストが混在するので、それらを統一的に扱いたい
  • 言語処理系というプログラムの性質上、SEGVするケースが結構多い。grasm層やScheme層については-eオプションでプロセスを起動して期待の出力になることをテストすればよいので問題ないのだが、C++ユニットテストでは問題になる。テストプログラム全体が1つのプログラムとして実行されると、SEGV時に全部巻き込んで死んでしまうので、それ以降のテストが実行されなくなってしまう。これは困る。

という感じ。


現在、Gaucheにテスト実行スクリプトを書いていて、C++のテストコードを解析してテストケースごとにファイルに切り分けてコンパイルして実行する、というスクリプトを実装中。


まともに動作するまでにかかる時間がすごく多いので我慢の連続なのだけれど、いったん動き始めれば使いながらライブラリの実装とかチューニングとかができるので楽しくなるはず。我慢我慢。

コードはそのうち公開します。とりあえず曲がりなりにもSchemeと呼べるものになるまでは手元で育てるつもり。

【広告】