ちょっとした計算を外部に出したいってことがある。
そのために外部変数を取り入れ可能なインタプリタエンジンがほしい。
IronPythonもあるけど、あれは便利だけど、でかすぎる。
もっと機能限定された簡単なものでいいのだ。
ということで、
『ゲームプログラミングエンジン』赤坂玲音著、Softbank Publishing
『プログラミング作法』Brain W.Kernighan,Rob Pike著、福崎 俊博訳、ASCII出版
に出てくるインタプリタの項目を参考にして作成中。
とりあえず考え方は分かるのだけど、いかにして言語化するのかについて思案中。
基本的な算術式を実行できるようにするだけでなかなか大変だなぁ。
でも一度作れば、自分の資産になるので、勉強中。
現在、まさにこの勉強にぴったりな内容の本が出版されているので、
興味のある方はそちらを探してみるのもいいでしょう。
別の話
RIDEBACKがアニメ化されているけど、おもしろい。
10巻で最終巻らしいが、さっさと戦争状態に入ってしまったので、かなしい。もっとレースの話をしてくれても楽しかったかも。
2/28/2009
2/27/2009
IronPythonへの移植
Pythonコードへの外部化に成功した。
今回ネックになったのは、DLLのImport
そもそも名前空間だけ異なる同じプロジェクト内に存在するファイルのクラスをどのようにして認識させるのか分からなかったので、そもそもそれはDLL化した。
まぁそこまでやると普通のDLLの登録と変わらない。
AssemblyNameはｄｌｌのプロパティからデータを取って、妥当性チェックをすることができる。名前空間のImport自体はオブジェクトブラウザにDLLを食べさせることができれば問題なくできる。
ただPythonのコード自体の妥当性チェックに有効な方法があまりないのが現状で、このコンパイルエラーをより厳密に特定できるようになれば、生産性は格段にあがると思う。
あとは、ImportのSyntaxSugerがもっとほしいとは思う。
とりあえず前のエントリの情報に従っていけば、IronPython1.1は十分エンジンとして組み込み可能なことが分かった。ただやはりハードコーディングのほうが実行速度は速い。事前コンパイルのエンジンを駆動させることができればより早くなる可能性はある。要検討だと思う。
2/26/2009
IronPython
IronPythonはC#で実装されているPython。仲間にはCPythonやJyphonがある。しかしIronPythonの特異な点は、それが.NET Frameworkとの橋渡しがされていることだ。DLRというカテゴリーらしい。
ちなみにIronPythonのサイトは、
であり、ここには全てがある。
MicrosoftのPublic Licenseに登録されているので、ソースコードも公開されています。これをみれば、インタプリタの勉強にもなるかもね。
ちなみにIronPythonについてなら、
入門編なら
IronPythonとC#の連携についてなら
大前提としてこれ以外にも
Pythonについて勉強しなければならないのはご愛嬌ｗ
スクリプト言語が組み込み可能になることによって、
ソースの細かな調整部分が外部に取り出されることになるので、
とっても便利だね！
最近CodeZineの無料の会員に登録したのだが、
まじCodeZineのソースは便利。
2/25/2009
自転車の取扱説明書
よく考えると不思議なのだけど、
自転車の取扱説明書を僕は読んだことがない。いや、そもそも今乗っているものも「自転車」とは言いがたいのかもしれないが、説明書が付属していなかったなぁ、と思った。自分の足の拡張である自転車のメンテナンスをしようとふと思ったときに、どうすればいいのか分からない。機能として「自転車」の要求を満たしているものが、本当に自転車足りえているのかを調べるすべを私は知らないのだ。もっというと、この「自転車」が妥当なものか分からないのだ。今にして思うと、私はメンテナンスというものを行った覚えがない、さまざまなものに対して。これで機械や論理的なものが好きだというのはお笑い種かもしれない。またなにかを大切にしていると発言することすらおこがましいのかもしれない。
なぜこんな話をしているのかを少し言おう。最近、自転車をこよなく愛する人のブログを読むたびにすこしづつ、信頼という思考停止状態に疑問を感じるようになってきた。まぁ、その人の文言はキツイのだが。その人が主張することの１つである、「自転車が楽しいこと」に関しては、異論はない。これほど単純で明白で便利なものはないのだ。そういう意味で言うとどのようなものも道具としてあるには意義があるんだ。でもその道具はその意義と「生命」を持っていると思う。それゆえその道具を活かしきれる環境が整わないとそれはそれで道具に悪い気がする。
じゃあ翻って、PCについてはどうだ？こいつのメンテも難しいなぁ。オーバーフォールするには経年している歴史が再構築に難ありで、困る。･･･ところでPCの固有なものってなんだ？
自転車の取扱説明書を僕は読んだことがない。いや、そもそも今乗っているものも「自転車」とは言いがたいのかもしれないが、説明書が付属していなかったなぁ、と思った。自分の足の拡張である自転車のメンテナンスをしようとふと思ったときに、どうすればいいのか分からない。機能として「自転車」の要求を満たしているものが、本当に自転車足りえているのかを調べるすべを私は知らないのだ。もっというと、この「自転車」が妥当なものか分からないのだ。今にして思うと、私はメンテナンスというものを行った覚えがない、さまざまなものに対して。これで機械や論理的なものが好きだというのはお笑い種かもしれない。またなにかを大切にしていると発言することすらおこがましいのかもしれない。
なぜこんな話をしているのかを少し言おう。最近、自転車をこよなく愛する人のブログを読むたびにすこしづつ、信頼という思考停止状態に疑問を感じるようになってきた。まぁ、その人の文言はキツイのだが。その人が主張することの１つである、「自転車が楽しいこと」に関しては、異論はない。これほど単純で明白で便利なものはないのだ。そういう意味で言うとどのようなものも道具としてあるには意義があるんだ。でもその道具はその意義と「生命」を持っていると思う。それゆえその道具を活かしきれる環境が整わないとそれはそれで道具に悪い気がする。
じゃあ翻って、PCについてはどうだ？こいつのメンテも難しいなぁ。オーバーフォールするには経年している歴史が再構築に難ありで、困る。･･･ところでPCの固有なものってなんだ？
2/24/2009
基礎研究
自分で考える基礎
共通
共通
- 開発環境の状態
- 開発言語の文法
- ロジックの考え方（テンプレート的なもの、デザインパターンなど）
- ポインタ制御
- 標準の関数群の内容
- ファイルの分割方法
WinAPI
- イベント駆動型の意義
C#
- 言語のもっている機能（多機能なので、習熟に時間がかかる）
ロジックの考え方に関しては、プログラムの肝であり、また習熟し尽くすことはできないと思われる。そしてロジックに関しては擬似言語でも学習可能である（限界はあるような気もするけど）。しかしこれが豊かであればあるほど、上質なコードを生成できるので、これを強調したい。もっとも言語によらず、ロジックは存在できるので、一つの言語でこれを試行錯誤することが重要である。それゆえに開発言語がなにであるのかということは、言語特性に習熟しているか、開発の見通しを立てやすいかということぐらいにしか関係しない。。。と思う。まぁ、母国語が日本語なのに英語で作文を書くと大変なのと似ているような似ていないような…
登録:
投稿 (Atom)