ちょっとした計算を外部に出したいってことがある。
そのために外部変数を取り入れ可能なインタプリタエンジンがほしい。
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#
- 言語のもっている機能（多機能なので、習熟に時間がかかる）
ロジックの考え方に関しては、プログラムの肝であり、また習熟し尽くすことはできないと思われる。そしてロジックに関しては擬似言語でも学習可能である（限界はあるような気もするけど）。しかしこれが豊かであればあるほど、上質なコードを生成できるので、これを強調したい。もっとも言語によらず、ロジックは存在できるので、一つの言語でこれを試行錯誤することが重要である。それゆえに開発言語がなにであるのかということは、言語特性に習熟しているか、開発の見通しを立てやすいかということぐらいにしか関係しない。。。と思う。まぁ、母国語が日本語なのに英語で作文を書くと大変なのと似ているような似ていないような…
2/23/2009
信頼システム
信頼でなりたつシステムっていっぱいある。というか、保証つきのシステムだってそうだ。
何が言いたいのかというと、妥当性チェックしろってこと。
下位構造を知ることなく使えるシステムは全て信頼の上に成り立っており、その信頼が揺らぐときシステムは既定の動作を行えなくなる。何らかの権利を集約して持っている存在は信頼性なしにはその動作を安定させられない。しかし逆に下位構造がなくなっていても動作した気になることも可能である。「信頼している」が思考停止の魔法の呪文であると同時に「信頼されている」という言葉もまた思考停止の魔法の呪文でしかない。常にこの関係は妥当であるのか、チェックしなくてはならない。
信頼システムは安定した環境では非常に簡便なシステムであることは認める。しかし安定した動作を求めているのに、日常的に動作不安定な状況ではこれほど非合理なシステムはない。ただこれを厳格化すると初動がどうしても遅くなる。不安定な状況でも安定した動作を求めるのか、それとも不安定な環境でもそれなりに妥当であればいいのか。それは機能の安定性に関連してくる。それがトレードオフの対象だろう。
ところで厳格なシステムでは変革への機運が生まれないような気が･･･まぁ、デジタルな世界ではうまいこと変革ができないので、厳格システム一本かなぁー。アナログな世界ではどうかなぁ？
2/21/2009
法意識とネット上での人格形成
法の意識というものは、人間の発達段階で思春期を過ぎたあたりから生まれるものらしい。
インターネット上で中学生ぐらいの質問者が違法なレベルに抵触しているテーマを提出するということはこの観点からすれば、一定の留保を認めることができるかもしれない。しかしこれらをたしなめることなく質問に対して回答してしまうことは問題だと思う。そしてそれをたしなめる自身にも同じことが遵守されなければならないはず。
また日本で法といってもそれは守るべきものではなくて、引っかからないようにするものであるという意識がある。そうでなければ、違法か非違法かどうかを気にするわけがない。見つかる、見つからずに関わらず発生すべきである。しかしこれはあくまでキリスト教的な「ユビキタスな神の視線」ということが前提である。日本は一応これではなく「恥」というものを考え方を使っていた。現在これが十分な機能を果たしているとは思えないが。いまどきは恥をかかされた自分を悔いるのでなく、恥をかかせた相手を名誉毀損や侮辱で訴えるのだろう。結局自らのうちから恥をなくし、神の視線はなく、ただ他者の視線から隠匿されるならばそれでいいのだ。
インターネットという現実世界とは違う振る舞いを求められる世界で現実世界と同じように振舞うなら、ただ他者の視線から隠匿されることを望むものたちは、非常に活動しやすいだろう。発言者の身分は自ら明らかにしない限り隠匿され、ほぼ他者から隠匿されている。ネット上では強制力はなく、ただ一個人として自らの倫理観や道徳観をもって振舞うのでなければ、自らの振る舞いを律するものがない。実際は18歳未満禁止のポルノサイトに青少年がいくらでもアクセスできるし、それを行っている行為者を特定する手段が存在しないことからも、これらの違法行為を抑止するのは本人以外にない。
だからといって、ネット上でもこそこそと違法な話をすればいいというわけではない。そこで発言されたことはネットを介して閲覧できる以上は技術をもった人ならば誰でも到達できることを意味している。これは先ほどの隠匿とは逆の公開である。存在は隠匿されていても、そこで行為することを通じて、次第にネット上に存在が確立されていく。このようなあり方を「新たな誕生」のように捉えることもできるだろう。
結論として言いたいのは、ネット上でも人格が形成されていく可能性があるから、あとから後悔したくないのなら、自らの発言には生活世界であるとき以上の厳密さと責任が必要とされることだ。
まぁ後悔などと無縁であるような人はこの限りでないので、何を説いてもそれは無駄というものだ。これの人格の話もただ便宜上これを採用するだけで、これは真実ではない。ただこういう風に組み合わせて考えることもできるというだけだ。VR内で人格を形成することはたぶん可能だろうけど、それはVRのみではなく生活世界にも当然関係するから、まぁVRでの人格はある意味その人の一面という意味合いが伝わればいいなぁ。
2/19/2009
ガラパゴスで何が悪い？
まぁ、特殊であることの不利な点は環境が変わると全滅する可能性があるということです。 それがリスクであるけれど、逆に強みでしょ。 グローバル化という御旗の元に外へと出て行こうとしているけれど、井の中の蛙だったということですね。 というか、このガラパゴスという表現を使うなら当然進化論を前提にしているわけで、 でもその進化論の現在の研究まで到達していないでただ絶滅の危険だけあおってもしょうがない気が･･･ 遺伝子の変異の仕組みからすると、業界は変革していくだけの広さを認めないと死に絶えるような気がする。 まぁ小手先の変化なんてよくある変異なので、大きく変えないとダメだねー。 ってことでガラパゴスがガラパゴスから変化するにはもっと大きくぶれないといけないですよねーって話。
2/18/2009
2/11/2009
PSxのためのゲーム開発
http://ps2dev.org/psp/Projects
にPSｘでの開発のための道具が公開されていますし、
Tutorialがあります。
でもコンシューマーゲーム機での開発ならXBox360で
XBLA用にXNAで開発するほうがクリーンかも。
ただポータブルゲーム機の開発環境がないので、
開発環境の公開が願われます。
にPSｘでの開発のための道具が公開されていますし、
Tutorialがあります。
でもコンシューマーゲーム機での開発ならXBox360で
XBLA用にXNAで開発するほうがクリーンかも。
ただポータブルゲーム機の開発環境がないので、
開発環境の公開が願われます。
2/07/2009
2/05/2009
データの取り扱い
最近、ＭＶＣの構造でのアプリケーションを構築することを目標に開発している。
ＭＶＣは、Model-View-Controllerの頭文字であり、
Modelは本質的なデータ構造とそれに付随するメソッド
Viewは表層的なデータ構造とそれに付随するメソッド
Controllerは本質的なデータ構造と表層的なデータ構造を接続するメソッド
と解している。
ただこれも便宜的な分割方法に過ぎないので、無理にこれを準拠しようとすると
当然うまくいかないこともあると思う。
Objective-Cというかリンゴの会社はこれを推奨している。
これを意識するようになって、根本的にデータ構造の研究に注意を向けていなかったことがわかった。
以前は、View-Controllerのやり方に引きづられるかたちでその場その場に都合のいいデータ構造を作っていた。
これだとViewが変化したときにデータ構造が大きく変更されたり、そもそも不要になったりするので、改造に不便なこと、この上ない。
最低限必要なデータを決めておくこと(Modelの措定)によって、その後もデータの要素を変更しても、そのデータ構造に対して、必ず代入して値を満たすことを目指していけば、データをうまく扱えるようになる。
と思う。私の知っている範囲だとこの構造が一番うまく組めると思う。
ＭＶＣは、Model-View-Controllerの頭文字であり、
Modelは本質的なデータ構造とそれに付随するメソッド
Viewは表層的なデータ構造とそれに付随するメソッド
Controllerは本質的なデータ構造と表層的なデータ構造を接続するメソッド
と解している。
ただこれも便宜的な分割方法に過ぎないので、無理にこれを準拠しようとすると
当然うまくいかないこともあると思う。
Objective-Cというかリンゴの会社はこれを推奨している。
これを意識するようになって、根本的にデータ構造の研究に注意を向けていなかったことがわかった。
以前は、View-Controllerのやり方に引きづられるかたちでその場その場に都合のいいデータ構造を作っていた。
これだとViewが変化したときにデータ構造が大きく変更されたり、そもそも不要になったりするので、改造に不便なこと、この上ない。
最低限必要なデータを決めておくこと(Modelの措定)によって、その後もデータの要素を変更しても、そのデータ構造に対して、必ず代入して値を満たすことを目指していけば、データをうまく扱えるようになる。
と思う。私の知っている範囲だとこの構造が一番うまく組めると思う。
登録:
投稿 (Atom)