[ipy]IronPython Studio

IronPython Studioなるものが公開されています。内容を見ると、Visual Studio 2008 Shellを使ったフリーのIDEのベータ(CTP)だそうです。これはVisual Studio 2008 Integrationに基づく、カスタムIDEです。ライセンスはMS-PLで配布されていて、作成者は CLARIUS Consultingというシアトルの会社です。 #只今、PCの環境整備中です。引っ越しでPC1台がお亡くなりになったので。

1

[PS] PowerShellの書籍がまもなく発売になります

Blogの更新も滞っていたのは、プライベートでも忙しかったためです。長期に渡ってプライベートの時間でPowerShellの書籍を執筆していました。この書籍もやっと最終局面に入ってきて、残すは最後のチェック作業のみになりました。私は気がつかなかったのですが、Amazonに予約販売で掲載されていました。 タイトル:プログラマブル PowerShell  ~プログラマのための活用バイブル~出版社:技術評論社ISBN:4774133329価格:2480円(税抜き)発売予定日:2008/1/9 サブタイトルが「プログラマのための」となっていますが、スクリプトを記述する人向けとするために可能な限り、文法を重視して記述しました。以下に目次を掲載します。Capter1. PowerShellとは1.1.  PowerShellの概要1.2.  PowerShellの導入1.3.  コマンド1.4.  その他の機能と特徴1.5.  インタープリタの機能1.6.  まとめChapter2. スクリプトの開発2.1.  PowerShellと.NET Frameworkの関係2.2.  PowerShell固有の癖2.3.  リテラルの定義2.4.  変数の定義2.5.  データ型2.6.  演算子(オペレータ)2.7.  フロー制御2.8.  関数2.9.  ファイル処理2.10. 例外処理2.11. デバッグ2.12. まとめChapter3. PowerShellの使い方3.1.  .NET オブジェクト3.2.  .NET流なファイル処理3.3.  正規表現3.4.  GUIアプリの開発3.5.  インターネットにアクセスする3.6.  Webサービス3.7.  XMLを使う3.8.  データベースプログラミング3.9.  COMやWMI3.10. まとめChapter4. PowerShellを活用するために4.1.  タイプシステム4.2.  コマンドレットを作る4.3.  他の言語から使用する4.3.1.  PowerShellとC#やVB         ・PowerShellからC#やVBを使用する         ・C#やVBからPowerShellを使用する4.3.2.  PowerShellとIronPython         ・PowerShellからIronPythonを使用する         ・IronPythonからPowerShellを使用する4.4.  スレッド4.5.  セキュリティ4.6.  まとめAppendix執筆時間が長かったため、PowerShell v2.0の最初のCTPも公開されてしまいました。このCTPでは、v1.0を置き換える形でインストールするためにv1.0とv2.0のサイドバイサイドの実行はできませんが、v1.0との互換性を重視しているためv1.0で作成したスクリプトのほとんどが実行できます。

4

[IPY]NWSGIが始まったようです

IronPython向けのPEP-333(WSGI)を実装するプロジェクトが始まったようです。プロジェクトのTopページに書かれているサンプルを見ると非常に興味深いです。以下にサンプルを引用します。def application(environ, start_response): “””Simplest possible application object””” status = ‘200 OK’ response_headers = [(‘Content-type’,’text/plain’)] start_response(status, response_headers) return [‘Hello world!\n’] これで、http://仮想ディレクトリパス/スクリプト.pyで呼び出します。

1

[IPY]台湾中国語版「IronPythonの世界」

今年の春に出版した「IronPythonの世界」の台湾中国語版が「博碩文化」社から翻訳出版されました。ISBN 9789862010587です。私には中国語を読むことができないのですが、見本誌が届く予定なので届いてから中身を見てみたいと思います。 追伸:IronPython 2.0A6がリリースされています。この中にToyScriptが含まれていますので、DLRを使って独自の言語実装を考える方には勉強になる例題だと思います。

5

[DLR]MS-PL,MS-CLが承認されました

DLR、そしてIronPython2.0、IronRubyが採用するライセンスであるMicrosoft Public License(MS-PL、元々はPermisiveだったのがPublicに名称変更されています)がOSIで承認されました。 オープンソースライセンスになったことで開発に協力していただける方達が、増えることを祈っています。 PS:IronPythonは2.0A5がリリースされています。2.0A5に対応したFePyのIPCE R6もリリースされています。

3

[dlr]OSC2007でお見せしたデモ内容について

オープンソースカンファレンス 2007 Tokyo/Fall でお見せしたデモ内容は、以下のようなものです。 IronPythonにおける Pythonデータ型と.NET データ型のシームレスな統合IronPythonでサウンドを鳴らす。 DLR Consoleを使って、IronPythonの関数とManaged JScriptの関数の相互利用(共有オブジェクト) IronRubyで使って、Windows Fromsを使う。IronRubyへ追加した独自モジュールの使い方。 IronPythonからRubyスクリプト(Windows Formsのサンプル)を読み込んで、Windows Formsのインスタンスを操作する 1.Pythonデータ型と.NETデータ型のシームレスな統合 IronPython起動直後は、Python互換モードで起動されます。例えば文字列を定義するとそのデータ型はpythonの「str」型となります。このためstr型が提供されるstrip()メソッドなどを利用することができます。この状態で「import clr」によってclrモジュールを読み込むと文字列のデータ型がpythonの「str」型に「System.String」の型の特徴が付与されます。このためpythonのstrip()メソッドに相当する.NETのTrim()メソッドも使用できるようになります。このようにデータ型を.NETの型へのシームレスに移行させるのもclrモジュールの役割の一つです。このような実装方法になった理由は、コミュニティからのフィードバックによるものです。Python互換を標準状態が良いというコミュニティの意見を尊重した結果です。 2.DLR Consoleでの複数言語間のオブジェクト共有 言語にPythonを選択して、以下のような関数を作成しました。def pyfunc(a): return a + ‘ by IPY’  この関数をPythonから呼べるのは当たり前として、言語をJScriptに切り替えてpyfuncを呼び出してみました。次に、JScriptで以下のような関数を作成しました。function jsfunc(a) { return a + ” by JScript”; } このJScriptで定義した関数を言語をPythonに切り替えて呼び出してみました。DLR Console上では、PythonとJScript間で言語に依存しないで関数を共有できることをお見せしました。これが共有オブジェクトの機能です。 3.IronRubyからWindows Formsを使用する RubyForgeに公開されているIronRubyの実装では、.NETのアセンブリを読み込むのに「require ‘アセンブリ識別子’」を指定する必要があります。このためwinforms.rbというスクリプトの中に「require ‘System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’」という記述をしていることを説明し、「hellowinform.rb」というスクリプトの中でWindows Formsのインスタンスを作成しています。イベントハンドラについては、以下のように記述していることを説明しました。my_button.Click do |sender, args| # Labelコントロールを作成 my_message = Forms::Label.new my_message.Text…

1

[dlr]OSC2007 FallでDLRを説明させていただきました

オープンソースカンファレンス2007 Tokyo/Fallが開催されています。今回は、DLRに関して説明をさせていただきました。ご参加した方々、私の話を聞いてくださいまして有難うございます。スタッフに資料は渡しましたので、その内に公開されると思いますが、念のためこのエントリに添付させていただきます。説明の使った資料のPDFデータとIronRubyでデモに使用したサンプルコードを入れています。参加された方から、「実装言語のオブジェクトがDLRを介して全てを利用できるのか?」というご質問をいただきました。確かに、言語実装者がDLRを介して公開できるように実装しなければ、その言語内に閉じたオブジェクトになります。DLRでは、SymbolicDictionaryという辞書でオブジェクトへのポインタを管理しています。この辞書からオブジェクトのポインタを取得して、プロパティやメソッドを持っているかを問い合わせします。持っているという返事を貰った場合に、Invokeするという仕組みを採用しています。この問い合わせに答えない実装もあります。事実、IronRubyではメソッドやクラスはIronRubyのRuntimeの中に閉じていまして、外部からは使うことができます。現状のIronRubyの実装では、変数や.NET Frameworkのライブラリのインスタンスが、DLR上のファーストオブジェクトとして扱われています。この機能を使ってIronRuby側でWindows Formsのインスタンスを作成して、IronPythonでそのオブジェクトを操作するというデモを行いました。この辺りは、言語実装者がオブジェクトなどをどのようにDLRに公開するかにかかっているのだと思います。この意味では、Managed JScriptは、IronPythonにかなり近い実装方法を取っていると考えられます。このために、DLR Consoleで双方から自由にオブジェクトを操作できるようになっています。 追記:添付のPDFの中に「マル秘」となったスライドが1枚だけあります。これは参加された方たちだけが知っている内容になりますので、ご容赦ください。追記:PDFのつもりが間違っていました。ファイルは差し替えています。既にダウンロードされたかたは、Copyright表記に従って、ご利用くださいませ。 OSC2007.zip

1

[DLR]IronPython 2.0A4の-X:PreferComDispatchについて

IronPython 2.0A4が9/7にリリースされていますが、このリリースノートに「-X:PreferComDispatch」オプションが追加されたとあります。このスイッチの使い方をWackyさんが解説して下さっています。私は、このスイッチの使い方をソースコードの「src\Tests\test_cominterop.py」から知りました。私の個人的な予測は、DLRに実装する前の実験的な実装としてIronPython2.0に入れているんじゃないかということです。なので最終的には、DLRにCOMサポートとしてのIDispachサポートが入って欲しいと考えています。 PS:IronRubyと組み合わせて試される場合は、IronRuby PreAlphaとIronPython 2.0A3にして下さい。RubyForgeで公開されているIronRubyでは、IronPython 2.0A4のDLRと実装が異なっていますので。

3

[PS]WMIの取り扱いについて

暫く更新が滞っていました。私事で忙しかったせいですが、今回はPowerShellとWMIで気がついた点を記載します。 Windows Vistaを使ってPowerShellでインストールされたソフトウェアの一覧を表示しようとして、WMIのWin32_Productクラスを使ってみました。 PS (1) >Get-WmiObject Win32_Product Get-WmiObject : エラーです 発生場所 行:1 文字:14 + Get-WmiObject <<<< Win32_Product このようにエラーになってしまいました。一部のソフトウェアが表示される場合もありますが、必ず「Get-WmiObject : エラーです」となってしまいます。色々と調べていくと、Windows Vista のWMIのWin32_Productクラスのバグらしいということが判明しました。この情報はネットニュースのpowershellの中にありました。この内容を見ると既知のバグでVista SP1で修正される予定だと書かれています。じゃあ、他の方法を使わないとWindows Vistaでインストール済みのソフトウェアの一覧を取得できないことになります。で思いついたのが レジストリを列挙する。 Windows Installer APIを使用する。 という方法です。今回は、Windows Installer APIを使用してみたいと思います。 PS (2) >$wi = New-Object -ComObject WindowsInstaller.Installer PS (3) >$wi | Get-Member TypeName: System.__ComObject Name MemberType Definition —- ———- ———- CreateObjRef Method System.Runtime.Remoting.ObjRef CreateObjRef(…

5

[Arch]実現可能性をどうみるか

何か硬いタイトルですが、何気に以下のような図を見てください。 図の良し悪しは置いといて、ようはサーバーという役割とクライアントという役割が物理的なコンピュータとして分離しているよということを表しています。このような構造になった時に、ソフトウェアを開発する立場として何を考えるでしょうか。 何を実現しようとしているのか。 どういう機能の役割分担なのか。 ネットーワークはどうなっているか(プロトコル、回線、etc)。 言語は何か? 要求を考える時に重視するべきことは、「何を狙いとしているのか」という点でしょう。そしてソフトウェアで実現すべき機能は何かということになるでしょう。 サーバーとクライアントが物理的なコンピュータとして分離されていますから、通信手段や言語も気になるかも知れません。でも物理的なネットワークの回線で繋がるということから、コンピュータ同士が通信を行う取り決めを行えばどのようなコンピュータとも通信そのものは可能なはずです。つまり、以下のようなことを決めれば通信は可能だと考えることができます。 通信プロトコルを合わせる。 メッセージの種類と役割、データの項目を合わせる。 これ以外にも考えるべきことはあるでしょうが、通信プロトコル(たとえばHTTPを使うか、TCP/IPなのか)と交換するメッセージを決めれば、通信可能であることを予測することができます。サーバーとクライアントのソフトウェアやOSを気にする必要はありません。何故なら、純粋に接続可能かどうかを見極めることが大切だからです。 次に考えることはコストと実現可能期間かもしれません。コストを考える上で、同じOSで同じプログラミング言語で作成されていることは重要かもしれません。何故なら、標準で通信手段が提供されていたりするからです。異なるOSや異なるプログラミング言語の間で通信を行う必要があるかも知れません。通信手段を簡単に実現するライブラリがそれぞれに存在すれば、コストを削減することができます。もちろん独自に通信手段を確保することもあり得ます。ようはコストや信頼性、パフォーマンスと言った指標とのトレードオフで今回の実現手段を選択すればよいのです。この選択した実現手段を関係者に対して、適切に説明できて、実現手段を提示できれば良いだけです。 ここで重要なのはプログラミング言語でもOSでもありません。通信が可能かどうかであり、それが必要十分な手段(コストや納期など)で実現できるかどうかです。 ついでに言えば、このような物理的な構成になった時の弱点も考えられることが大切です。具体的に言えば、通信方式が同期式なのか非同期なのかです。そして大量のデータを送受信する必要があるかどうかなども通信方式を決定するときの、重要な事項になります。一般的にHTTPサーバーへ大量のデータを送信するとタイムアウト時間のチューニングが必須になります。タイムアウト時間を延ばせば、サーバーで管理するセッションオブジェクトなどの破棄タイミングをどうするかなどの懸案事項も生まれてきます。この問題を根本的に解消するには、大量データの送受信では非同期処理を採用するとか、別の手段を用いるなどが必要になるわけです。 これらの懸案事項というのは、実現可能性を考えるときに必要な機能を洗い出せていれば事前に検討材料にすることが可能になります。これらの実現可能性を漏れなく考えて実現方式を検討していくのがアーキテクチャ設計ではないかと私は考えます。 ここまで考えて行く上でプログラミング言語は、それほど重要なことでは無いという事実も重要な点です。もちろん逆でプログラミング言語から構造を考えていくという手段もあるでしょう。この手段の欠点は、プログラミング言語が提供する以上の構造を作れない点です。つまり限界は、プログラミング言語が持つということです。 PS.誰でもよーく考えれば思い浮かぶ事だと思っています。でも忙しすぎて、慣れた手段で実現していくことで、新しい方法や手段を考えなくなることが怖いと私は思っています。自戒の意味で。

1