IronPython 2.6 ベータ2

リリースノート
http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27350
によると、

バグ修正のほかに、pdbや_ctypesが強化されてるようです。

pdb（デバッガーむけのインターフェイス）と聞いて、ひょっとしてpydevと一緒に使ったらeclipse上でステップ実行できるかも？と思って試してみましたが、まだ動かないようです。

もし動いたら、Java（Sunというかオラクル）で記述されたEclipse（IBM）上でPython（Google）とコンパチのIronPython（MS）インタプリタでデバッグ、という摩訶不思議な図になるのですが・・・

64ビットWindowsへの対応として、ipy.exe以外に、ipy64.exeが用意されたそうですが、リリースノートの説明を読んで一瞬「？」。

・ipy.exeは64ビットOSでも32ビットOSでも32ビットプロセスとして実行される。
・ipy64.exeは64ビットOSで動かすと64ビットプロセスとして、32ビットOSだと32ビットプロセスとして実行される。

この説明を、OSの方から整理してみます。

・64ビットOSでは、ipy.exeは32ビットプロセス、ipy64.exeは64ビットプロセスとして実行される。
・32ビットOSでは、ipy.exeもipy64.exeも32ビットプロセスとして実行される。

これでやっと腑に落ちました。コンパイルして配布するバッチプロセスでIronPythonを呼び出すときを想定してこうなってるんだなあ、と。

・32ビットプロセスとして実行したいときはipy.exeと書いておけば良い。
・64ビットプロセスとして実行したいときはipy64.exeと書いておけばよい。ただし、32ビットOSで実行された場合には、いきなり「64ビットOS用のコードは実行できません」エラーで終了するのではなく、32ビットプロセスとして実行してみる。

という動作になります。

(同日追記)

32ビットのマシンにインストールするとipy64.exeがコピーされない（あるいは作られない）ところを見ると、上記はバッチファイルよりはコンパイルしたものを想定した動作のようです。

命名「フタなし」

合理的というか、割り切ったというか・・・

台湾製の、G-Monster eSATA USBというSSDの話です。

大容量（128GB）で、書き込みも高速100MB/s（カタログ値）。サイズも小さい。

ただ、形が。ユニークというか。eSATA端子が四角いケースから生えているような感じで、キャップは付属してません。もちろん端子が引っ込んだりすることもなく。

箱から取り出した時の第一印象は「キャップどこ？」です。

よくよく調べてみたのですが、キャップが刺さる穴とかくぼみとか、それらしいものがありません。キャップなしのデザインらしい、と結論しました。端子を触ってみると、かなり頑丈そうに作ってありました。

それでもまだ半信半疑。

持ち運んでもeSATA端子が折れたり曲がったりしないか、無造作にかばんにほうりこんだ状態にしてテストしています。

今のところまったくヘーキっぽい。大したものです。

考えてみれば、短いケーブルとかはすぐにどっかにやってしまう私なので、フタなしで問題ないなら、そのほうがありがたいのですが・・・

心配性？

アマゾンよ、お前もか。あるいはクラウドに感じる不安の実体

記事「人の家に無断で上がり込んで蔵書に火を着けるAmazon, みぞーゆーの愚行」
http://jp.techcrunch.com/archives/20090717amazon-why-dont-you-come-in-our-houses-and-burn-our-books-too/
より。

「Amazonは今朝、Kindleの本をリモートで削除し始めた。」

iPhoneのアプリがリモートで削除されるのは知ってましたが・・・

電子ブックリーダーのKindleだと購入した書籍のデータもリモートで削除できるんですね。

アプリケーションならまだしも「マルウェアを削除する（してあげる）必要があるから」とリモートで削除機能の存在理由がつくのですが、いったんダウンロードしたデータが削除されるとなると、これはもう新しい次元の問題です。

「プライバシーは死んだ。次は、データの所有権だ。」とどっかの検索サイト企業が言い出しそうです。

このニュース、日本の某著作権団体も「この手があったか！」と注目してるんじゃないでしょうか。

(2009/07/19) タイポ修正。相変わらず気にしぃだ。

Re: IronPythonでマルチプラットフォームGUIの可能性 番外編

記事「MicrosoftはC#とCLIに特許を主張せず - .NET互換「Mono」への影響は?」
http://journal.mycom.co.jp/news/2009/07/09/019/index.html
より。

C#やCLIのうち、ECMAがカバーしている（つまり標準化された）部分については「Microsoftは特許などの権利を主張することはな」いんだそうです。

・・・Winformsは入ってませんけど。まあ。

最近、MSの動きが速くなったような？

IronPythonの、というかSharpDevelop 3.1ベータのハウを知る

Sharp Develop 3.1ベータを使って、IronPythonでGUIアプリを書く実験をしてます。

（IronPythonStudioだとUIをXAMLで記述することになるのですが、少し大げさすぎる気がするので。）

で、ちょっと気づいたこと。

●GUIデザイナで生成されたコードをいじらない方法

GUIデザイナ（というかデザインタブというか）でフォームにボタンやらラベルやらをぺたぺたと貼り付けるとUIのコードが生成されるのですが、

イベントハンドラ（というかボタンが押されたときに呼び出されるメソッド）の中身は、初期状態でpassになっていて、それを書き換えろと言わんばかりになっています。

もちろん書き換えたあとで、GUIデザイナを使ってボタンを足したり、とかは問題なくできるのですが、やっぱりなんとなーく気持ち悪い。

生成されたコードをいじらないで何とかならないか？ということで試行錯誤。

結果、成功した方法は、MainFormを継承したクラスを作るというもの。

(1) 生成されたクラスのMainFormはそのままにしておいて、MainFormを継承したクラスを作ってMyMainFormとする。

(2) MainFormのイベントハンドラ（であるメソッド）の中身を書き換える代わりに、MyMainFormでイベントハンドラのメソッドをオーバーライドする。

(3) エントリポイントとなるProgram.pyでMainFormを使っているところはMyMainFormに書き換える。（あるいは、Program.pyを書き換えるのがイヤならMyProgram.pyを作るのもアリです）

●アバウトダイアログをGUIデザイナで作りたい

どうも、GUIデザイナで触れるクラスはMainFormのみらしく、後からダイアログのクラスを付け足してGUIデザイナで作る、とかはできないらしい。

では、アバウトダイアログはガリガリ手書きするのか？いくらなんでもそりゃないでしょ、ということで。

試行錯誤した末、アバウトダイアログのためにひとつプロジェクトを作ってやる方法でうまくいきました。

(1) アバウトダイアログを付け足したいアプリのソリューションを右クリックして、新しいプロジェクトを作る・・・

(2) このとき、新しいプロジェクトのディレクトリが、元のアプリの子ディレクトリになるようにする。

たとえば、元のアプリがc:￥MySolution￥MyAppだったら、新しいプロジェクトはc:￥MySolution￥MyApp￥AboutDialogとかにする。

(3) 新しいプロジェクトを元のアプリのプロジェクトからインポートできるようにする。c:￥MySolution￥MyApp￥AboutDialogに__init__.pyを作る。

中身は、「from MainForm import MainForm」1行のみ。

これにより、新しいプロジェクトのMainForm.pyというファイルで定義されているMainFormというクラスを、元アプリからAboutDialog.MainFormという名前でアクセスできるようになる。

(4) 新しいプロジェクトのMainFormをGUIデザイナでアバウトダイアログとして設計する。

copyrightを書いたり、OKボタンを付けたり。

(5) 元アプリのメニューに「about」を作ってやり、そのイベントハンドラ（であるメソッド）の中身を

import AboutDialog
AboutDialog.MainForm().Show()

とする。