[DLR] VM魂でお見せしたDLR電卓について

前回、VM魂にパネラーと参加させていただいたことを記載しました。その時にお見せしたDLR電卓がアットマーク・アイティさんで記事になっています。本音を言うと、DLRに感動してもらってホッとしています。記事では、コードが読みにくいのですが、実際にお見せしたのは以下のようなコードです。py> import calc as x # Pythonでモジュールの読み込み js> c = new x.Calc(canvas) //JScriptでインスタンスの作成 js> x.enliven(c) //イベントハンドラ登録 これでPythonで書かれたモジュール(calc.py)を読み込んで、定義されているCalcクラスのインスタンスをJScriptで作成して、イベントハンドラの登録も行いました。後は、普通の電卓ですから、電卓として使うことができます。 記事には「でも、オブジェクトのマッピングは自明じゃないから、そうそううまく何でも共有できると思えませんね」という説明があるのですが、それはその通りだと私も思います。色々な言語は、その使われ方を想定したチューニングを施しています。このチューニングは、専門化されればされるほど効果を発揮します。でも異なる使い方をすると、思いのほか効果が見えないからです。色々な言語が世の中に存在することを思い出してください。何故、色々な言語があるのでしょうか?やはり用途に合わないからだと私は思います。自分が達成したいことに適した言語を使えるのに越したことはありません。でも…全てのケースでうまくいくのでしょうか?中々うまくいかないジレンマに陥ることは、ないのでしょうか。そう言った場合に、別の言語にするとうまく行くケースもあります。別の言語を使うことを許して貰えないので、ライブラリを自作したという話もあります。こうした場合に、既に存在するライブラリなどの資産を共有化できそうなDLRという技術に私は、魅力を感じます。つまりトレードオフの関係があって、自分の問題解決の手段を選択するときに何を優先するのかということです。このような事を書いている私でさえ、ケースに拠ればコンパイラ言語でカリカリにチューニングしたりもします。目的としていることを達成するためです。 もっとも可能な限り楽をしたいという考えを私は持っていますから、DLRで目的を達成できるのなら迷わずDLRの上で動く既存のライブラリを使うでしょう。目的に合わないケースは、あっさりと使わないという選択もしますけど… 目標は目的を達成することなので、手段を問わないのが私の考えです。無節操すぎるでしょうか? PS.実はこのDLR電卓は、TechEd Yokohama向けに作成したものです。なのでTechEdに参加される方がLL魂にいらっしゃったとしたら、少し早めに見たと思ってくださいませ。

1

[DLR]IronPython 2.0A3の調べごと

前回のエントリーでIronPython 2.0A3がリリースされたことをお知らせしました。リリースノートによると、IronRuby1.0プレアルファに含まれるDLRと同期したバージョンだと記載がされています。このA3を使って作成済みの資料に影響があるかどうかを調べています。結果としてはASTレベルでは、特に影響は見られませんでした。ほっと一息をついたのですが、色々と調べていくと生成されるILレベルでは、変化が見られました。このことは、DLRの中に関する変更が行われたということを意味しています。どういう変更かは、生成されるILをA2と較べてみていただければ理解できるかと思います。 せっかくなのでIronRubyと同居できるかを試してみました。自分でビルドしたipy.exeとIronPython.dll、IronPython.Modules.dllをIronRubyをビルドしたフォルダにコピーして、ipy.exeを動かしてみました。結果は問題なく動作しました。動作するということは、IronPythonからRubyのスクリプトを使ってみようと実験してみました。試したコードは、以下のようなものです。import clr r = clr.Use(“test.rb”, “rb”) # 実行した結果が表示されます。Rubyのスクリプトを実行することはできました。が、clr.Useの戻り値を格納した変数rをdir関数で確認すると「#rfc」というメンバーが表示されます。何だろうと思って調べると「RuntimeFlowControl」オブジェクトでIronRubyのRuntimeが提供するオブジェクトだとわかりました。実行したスクリプトは、以下のようなものです。def test(a) return a + ” ,Hello” end puts test “IronRuby”このスクリプトで定義した関数(メソッド)であるtestがIronPythonから見えてないんですね。ふーむと考えながらスクリプトに「x= “IronRuby”」を追加して試してみると「r.x」で変数xに対してはアクセスすることができます。でも「#rfc」も表示されています。これを調べるためにrbx.exeのオプションである「-X:ShowASTs」か「-X:DumpASTs」を使用してIronRubyのASTを確認してみました。すると、「Variable」ノードに「#rfc」が定義されているのがわかりました。IronRubyのVariableノードをIronPythonはdir関数で参照していたのです。リテラルを定義した変数は参照できますが、オブジェクトや関数は現在のASTでは参照できないようです。PS.John LamのBlogにIronRuby1.0プレアルファリリース後のフィードバックのまとめのようなエントリが掲載されています。いきなり現在の実装のバグを直したりと色々な反応が見られます。後、Windows.Formsを利用するのに「require ‘System.Windows.Forms’」と記述できると書きましたが、内部でアセンブリ識別子に置き換えていました。ですから、現在のプレアルファでは、アセンブリ識別子を記述するのが正しい方法のようです。


[DLR]IronPython 2.0アルファ3リリース

出ました。リリースノートを読むと、IronRuby プレアルファと同期したDLRのバージョンの模様です。試すのが、今から楽しみです。というか、作った資料が使えるかどうか検討しないといけません。http://www.codeplex.com/IronPython 追記:IronRubyとの同期は、DLRが同じバージョンだという意味です。ひろえむさん、フィードバックを有難うございます。

1

[DLR]IronRubyのMonoでの動作

早くもMonoで動作させるためのパッチを作成した人が居るようです。http://sparcs.kaist.ac.kr/~tinuviel/download/IronRuby/ 色々と試していると、それなりに動きますねぇ。まだ、難点もありますが。そこはプレアルファですから。Windows Formsを使うだけなら、require ‘System.Windows.Forms’で大丈夫なのですが、WPFを使おうとするとアセンブリの識別子を書かないといけないようです(書かれていたんですけど)。早速なのでASTを調べていました。IronPythonと違って、ASTのデータの構造が少し異なっています。基本はastという変数に格納しているのですが、その中身の持ち方が異なるという意味です。言語が異なるので、当たり前なのかもしれませんが…8月からRubyforgeをプロジェクトのホームページにするようです。IronRubyプレアルファに含まれているDLRですが、IronPython 2.0A2よりも開発が進んでいる模様です。このため単純にIronRubyのDLRを使って、IronPython 2.0A2を動作させることができません。


[DLR]ASTネタというか独自の言語実装を考える方に

DLRにおける抽象構文木(AST)の解析についてというエントリに対して、興味深いトラックバックをNyaRuRuさんからいただきました。NyaRuRuさんのエントリでは、独自の言語プロバイダを実装してDLRのASTを調べるというものです。 DLRを利用した言語の実装を行うには、IronPython2.0A2が参考になります。でも、大き過ぎるので把握が大変という天の声も聞こえてきます。そういう私のような者のためにJohn LamがToyScriptというサンプルを公開してくれています(情報としてはちょっと古いかも。私は、早くから知っていたんですけど)。ToyScriptは、JohnがIronPythonからインスパイアされて簡単なASTを確認するために作成したようです。この使い方は簡単で、IronPython 2.0A1とToyScriptを用意して、ビルドして実行します。コンソールに対して、四則演算などを入力します。そうすると入力された四則演算がDLRで実行されているのを確認することができます。後は、ソースコードを丁寧に調べていけばDLR上で独自の言語を実装するためのヒントが見つかるという感じのものです。 それからDLRネタというか、IronPythonネタというか、Monoにおける状況ですが、Moonlightの話とDLRの話があります。この状況を調べていくには、monoプロジェクトはもちろんですが、FePyプロジェクトも調べていくと状況が良く理解できます。ちなみにDLRは、5月の頭の時点でMonoに移植する方法が見つかっています。私は、FePyプロジェクトの情報からこのことを知りました(感謝、Sanghyeonさん)。


[DLR] DLR における抽象構文木の解析について

現在、IronPython 2.0アルファ2を使って抽象構文木(AST)がどのように作成されるかを調べています。具体的には、以下のようなサンプルコードを使って、VSを使ってデータを収集しています。def yo(yourname): text = “Hello, ” return text + yourname print yo(“TechEd Yokohama”) このスクリプトを名前を付けて保存して、IronPythonConsoleプロジェクトのコマンドライン引数に指定して、ASTのデータを集めているのが以下の図です。 このastという変数にIronPythonの抽象構文木のデータが格納されています。これを更に調べていくとDLRの抽象構文木へマップしている状態も調べることができます。DLRのASTのデータを調べているのが以下の図です。  CodeBlockというデータ型に抽象構文木のデータが格納されています。こうして調べたASTを図にする作業を行っています。このASTの詳細説明は、TechEd Yokohamaの終了後にでも解説したいと考えています。現時点では、ソースコードを使うことで上記のようにASTを調べる方法もあるということをお知らせしておきます。 PS:DLRをC#などから利用する方法も調べています。その過程で見つけたのは、IronPython 2.0A2で提供される実行モジュールは、キーペアによる署名を持っていたことです。なので、ソースコードからビルドしたモジュールを使って色々と調べています。

2

TechEd2007で「動的言語」の説明を行います

TechEd Yokohamaで「T3-301 .NETにおける動的言語への取り組み」を担当しています。参加者の方達からご要望が多かったようで「Aルーム」に決定したとの情報が公開されています。 現在、その準備を行っているわけですが、その内容をどうしようかと色々と考えている最中です。基本的な論点は、MD3で取り上げているのですが、資料の締め切り的にIronRubyの詳細まで取り組むことは難しいと思っています。そこで今回の中心になるものを何にしようかと考えていまして、言語依存のASTとDLRのASTの関係をお見せしてはどうかとも思ったりしています。ASTという話になるとインサイド的な内容になっていくので、レベル300(アドバンス)でどうなんだろう? と考えたりもしています。 IronPython2.0A2の内部的な動作として、以下のような動きをしています。 Pythonとしての抽象構文木(AST)を作成 実行時にこのASTをDLR用のASTへマップ DLR用のASTからCILを生成して実行  DLRがCILを作るときの方法論として「DynamicSite」が利用されています。DynamicSiteは関数やメソッドなどの呼び出しをキャッシュするメカニズムを備えています。このために繰り返し呼び出したりするときの実行速度を向上させる効果があります。どうもこのキャッシュメカニズムは、動的言語実装者の経験や色々な実験から導き出した方法論のようです。 またIronPython1.0から行われていた引数の数による関数やメソッド呼び出しのチューニングもDLRのソースコードに残っています。このように様々なチューニングメカニズムを採用することで、パフォーマンスの向上を狙っているようです。 PS.このBlogで動的言語関係を読まれている方には、ネタバレしそうなので困っているのが本音なのですが。また上記のような説明を行おうとすると、デモが地味になるので「Aルーム」だしなーと思ったりしています。まっ、Inside や Under Food的な内容を計画しているので、デモは地味になるのが当たり前と割り切っていたりもしますけど…


[MD3]動的言語とSilverLight1.1アルファの関係

DLRを利用する環境として、IronPythonとASP.NET Futures、そしてSilverLight1.1アルファがあることを既に説明しました。今回は、SilverLight1.1アルファとDLRの関係を考えてみたいと思います。4月のMIXで発表されたSilverLight1.1アルファを構成しているアセンブリは、以下のような構造になっています。 SilverLightはブラウザのプラグインとして動作します。そして「coreclr.dll」を起動します。coreclr.dllが、SilverLight用の共通言語ランタイム(CLR)となります。このCLRがWindows用とMacOS X用に用意されるのが、SilverLightの実行環境です。そしてプログラミング言語として、IronPython、Managed JScriptをサポートしています。このプログラミング言語がDLRに対応しているわけですが、SilverLightからDLRを利用する仲介役を果たしているのが、「Microsoft.Scripting.SilverLight.dll」アセンブリになります。このアセンブリを使って、「Microsoft.Scripting.dll」というDLRそのものを活用しています。 もう一度、図のアセンブリの構造を見てください。SilverLight用のCLRの上で基本となるクラスライブラリ(BCLとかFCLlと呼びます)を利用しているのがわかります。そしてCLRを利用しているということは、アセンブリをロードするのにセキュリティリスクを意識しないわけには行きません。何が言いたいかといえば、SilverLight用に提供されているmscorlib.dllは、通常のmscorlib.dllと異なるアセンブリ識別子を持つということです。このことは、Microsoft.Scripting.dllがキーペアによる署名を持っていることを表しており、IronPython 2.0A2で提供されるDLRはキーペアによる署名を持っていないということを表しています。 よってIronPython 2.0A2のリリースノートに記述されているように含まれているDLRをSilverLight1.1アルファで使用することができないということになるのです。このことを考えていくとDLRとSilverLightのバージョンアップの頻度がどうなるのかな? という疑問を持たざるを得ません。何故なら、以下のような違いがあるからです。 DLR自体は、ソースコードを公開するオープンソースに近いモデルで開発が進められていく。つまり、フィードバックなどによって素早いバグフィックスが行われていくことが予測できる。 SilverLightはセキュリティリスクに対応するためにキーペアによる署名を持つ。従って、緊急時のセキュリティ対応以外は、頻繁バグフィックスが行われないのではないかと考えられます。 もちろんDLRに何を取り込むかを決定するのは、Jim Hugunin氏が率いるDLRチームが決定しますから、定期的にSilverLightにもフィードバックが行くと考えれます。その証拠にIronPython 2.0A2のソースコードを見ると、あちらこちらに「#if !SILVERLIGHT」という記述を見つけることができます。これは明らかにIronPython用のDLRと同じソースコードでSilverLight用のDLRが開発されていることを示しています。このように提供されているソースコードには、色々な情報が含まれていますから、見て調べることによって気がついていない使い方を発見できるかもしれません。 PS:IronPythonの「clr.Use」の使い方は「ClrModule.cs」から見つけました。そして前回のメソッド呼び出しがデリゲートに委譲していることは「CallTargets.cs」から見つけています。