[TechEd] PowerShellについて

TechEdでリリース済みの動的言語ということでPowerShellを簡単に説明しました。PowerShellで実行できるコマンドには、以下の4種類があります。 コマンドレット:PowerShell独自のコマンドで「動詞-名詞」というネーミング。 関数:一連の手続きに名前を付けたもの。 スクリプトコマンド:各種のコマンドなどをファイルに保存したもの。 ネイティブコマンド:実行可能プログラム(EXEなど)。 特にネイティブコマンドは重要で、これを使うと「cscript.exe xxxx.vbs」などのWSHのスクリプトをPowerShellの中から実行することができます。つまり、既存のスクリプト資産を移行しなくてもPowerShellで操作できるように配慮されているのです。 デモでお見せした電卓は、以下のようなものです。 これはWindows Formsを使って作成しています。このGUIを作成するときに特徴的な書き方をしているのが以下のようなコードです。,”C”+1..3+,”/”+4..6+,”*”+7..9+,”-“,0,”.”,”=”,”+”|ForEach-Object {new-button $_}   「new-button」という関数をパイプラインで呼び出しています。パイプラインに渡している配列が、ボタンに表示されている文字列なんです。もちろんFor文やForEach文で作成するという方法もありますが、パイプラインを使ってForループと同じことができるんです。PowerShellって… デモでは、このようなGUIのサンプルもお見せしましたが、PowerShellでのGUIプログラミングには、鬼門も潜んでいます。何かと言うとPowerShell.exeは、マルチスレッドで動作している点がGUIと相性が悪いのです。たとえばWindows FormsのWebBrowserコントロールなどは、シングルスレッドでないと利用することができないという制約を持っています。このようなコントロールを普通には扱えないのです。もちろん、独自のコマンドレットを使ったりすれば可能ですし、そういうコマンドレットを公開している方達もいらっしゃいます。 慣れてくると便利なツールです。PowerShellって。I-Oリダイレクションもサポートしていますし、CSVなどもサポートしていますから。色々な情報を集めてテキストファイルへ出力とかが簡単なんですね。

1

[TechEd] DLR電卓について

TechEdのデモでお見せしたDLR電卓とは、以下のようなものです。 SilverLight1.1アルファのサンプルである、DLR Consoleを使って電卓アプリをPythonとJScriptから操作するというサンプルです。このサンプルをLL魂でもお見せしているのですが、LL魂で使ったコードから60%のリファクタリングを行ったものをTechEdでは使用しました。見た目は同じなのですが、UIの作成方法が完全に異なっています。具体的に異なっている点は以下です。 UIのコードをXAMLで定義。 XAMLファイルを動的に読み込む  UIのコードをPythonで作成していた部分を完全にXAMLに分離しています。分離したXAMLファイルをHTTP Requestを使ってXAMLを読み込まなければなりません。読み込んだXAMLをXamlReaderでオブジェクトにするという方法を使っています。というのもSilverLightはブラウザのプラグイン技術なので、クライアントサイドで動作するからです。メインのXAMLであれば起動時に読み込めるのですが、それ以外のファイルとなるとサーバーからファイルをHTTPを使って読み込む必要があるからです。このような理由からLL魂で使ったサンプルでは、XAMLではなくPythonコードのみで作成していました。 このサンプルを使って動的言語ということで、 動的にUIを作る。 動的にイベントハンドラを登録する。 という内容をお見せしました。コマンドを入力しながら、自由に操作できるという特徴をお見せしたかったからです。もっとも作り込まれたプログラムになると、インタラクティブにコマンドを入力するということは無いと思うのですが、作成途中を確認するコンソールという意味ではDLR Consoleが役に立つと私が考えているからです。

2

[TechEd]明日からTechEd横浜が始まります

明日から今年のTechEd Yokohamaが始まります。その準備に追われているのですが、実はまだデモの内容で悩んでいます。作成済みのデモコードを大幅に手直ししたり、新しいデモ内容を作ってみたりしています。というのも私の担当しているセッションの会場がAルームなもので、会場が広いからどのようなモノをお見せしたものかなという悩みがあるからです。このような状況ですので、さっきもデモの内容を確認したりしています。 デモのテーマとしては、以下のようなものを考えています。 現状でできること DLRのオブジェクト共有 Python ASTとDLR ASTを覗く IronRuby 1.0アルファでできること さてさて、どうしよう。

2

[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]LL魂 VM魂にパネラーとして出演させていただきました

Lightweight Language Split(LL魂)のVM魂にパネラーとして出演させていただきました。ご参加いただいた皆様、有難うございました。ご一緒させて頂いた、星さん、高井さん、西尾さん、戸松さん、鈴木さん、そして取り仕切って頂いた柴田さん、本当にありがとうございました。皆さんの発表や発言、会場からの質問を含めて私にとっても勉強になりました。もちろんは、私はマイクロソフトの荒井として参加させて頂いたのですけれど、動的言語が好きな一人の立場として発言させていただきました。一部、所属する会社からすればXXな発言もしていますけれど、動的言語における.NETの歩みと言いますか、これから目指して行こうとしているところ(私個人の希望も含んでいますけど)をお話させていただいたつもりです。 動的言語の実装において何よりも重要と私が考えるのは、互換性です。何故なら互換性が高ければ開発したスクリプトは、その実行環境を選ばないからです。例えばIronPythonでは、clrモジュールを使うことで.NET Frameworkとの連携をスムーズにしています。何故、clrモジュールという形式になったかと言えば、コミュニティからのフィードバックでCPythonと異なる機能は別モジュールにした方が良いという意見があったからです。IronPythonはclrモジュールを使わなければ、CPythonとほとんど同じ挙動を示します。clrモジュールを使うことで、型システムを自動的に.NET Frameworkへと拡張します。このようなモジュールによって、実装された環境の特徴を生かすようになっています。つまりプラットフォーム非依存(互換性)とプラットフォーム依存が共存する仕組みがあることによって、使われる人たちへ選択肢を増やすことができるのです。 DLRという考え方は、本当に素晴らしいと私には思えます。何故なら、自分の好きな言語で開発したライブラリが異なる言語で利用できるようになるからです。LLにしても様々な言語が存在しています。何故、様々な言語が存在するかと言えば、1つの言語で全てを行うのが難しいからです。不可能ではありませんが、適材適所で使う用途があるからこそ様々な言語があると思うのです。そういった言語の成果物がシームレスに連携できる世界が実現できたら素晴らしいじゃないですか。動的言語でそういう世界をDLRは目指しています。だから、私は素晴らしいと思うのです。

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’」と記述できると書きましたが、内部でアセンブリ識別子に置き換えていました。ですから、現在のプレアルファでは、アセンブリ識別子を記述するのが正しい方法のようです。

0

[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を動作させることができません。

0

[DLR]IronRubyプレアルファが出ました

John LamのBlogでIronRubyのプレアルファのアナウンスがされています。私も内容を見るのはこれからなのですが、どの程度の完成度なのかを確かめるのが楽しみです。 お知らせまで。 追記:内容を色々と確認しています。今回の提供はソースコードのみで、実行モジュールはVSかMSBuildを使ってビルドする形式になっています。これを使って、Windows Formsのインスタンスを作成するには以下のようにします。 require ‘System.Windows.Forms’ f = System::Windows::Forms::Form.new() f.ShowDialog() こんな感じでFormを表示することができます。

0

[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さん)。

0