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

記事「R.Stallman氏、「MonoやC#への依存を減らそう」と呼びかけ」
http://sourceforge.jp/magazine/09/06/29/050217
より。

「Stallman氏はその理由として、米Microsoftが将来的に、ソフトウェア特許を使うことでMonoなどあらゆるフリーのC#実装に対し脅威になる可能性がある」

まあ、この辺は言いたいこと分かるというか。2007年の例もありますし。

むしろ、Mono開発者の↑への反論

Apebox.orgの記事「Here we go again – why Mono doesn’t suck」
http://www2.apebox.org/wordpress/rants/124/
より。

「System.Windows.Forms are not included by default, and are rarely used in Free applications anyway (because WinForms looks like ass, amongst other things)」

にちょっとへこみました。

System.Windows.Formsってそんなにひどいかなあ。GTKとかと流儀が違うっていうのは分かるけど。

BOF: 妥協してはならぬ、ただし

「技術においては絶対に妥協してはならぬ。ところが、うっかり政治的にそんな行動をとったら、この変動する社会で、ついには命を落とすことになる。」

書籍　佐貫亦男、佐貫亦男のひとりごと　より。

名言、というか身につまされすぎです。

メモ: JStyle, spidermonkey-bin

調べごとをしているうちに、何となくアンテナに引っかかったツールたち。

(1) JStyle

Eclipseで等幅！改行文字もきれいに表示。
名前だけから、Janeなんたらと勘違いして尻込みしてました。
某大掲示板から。

開発元
http://mergedoc.sourceforge.jp/

(2) spidermonkey-bin

Javascriptのインタラクティブシェル。
微妙に便利。

高林哲さんの「SpiderMonkey で JavaScript のインタラクティブシェル」より。
http://0xcc.net/blog/archives/000048.html

(2009/07/01)
「等幅」とすべきところを「同幅」になっていたので修正。
ついでに「等幅」の読み方が「とうはば」なのを知りました。
いままでずーっと、「とうふく」だと思っていたので。

IronPythonでマルチプラットフォームGUIの可能性 #2

(#1 から続く）

マルチプラットフォームのためには、この便利なやつ、winforms.pyはあきらめるしかないのでしょうか？

それはちょっとなあ、ということで試行錯誤。

結局、

winforms.pyの1つ目の利点は使うが、2つ目の利点は使わない

というところで妥協することにしました。

具体的には、

(1) Windowsマシン上で開発し、winforms.pyを使って対話モードでGUIを作る。

(2) ただし、最終的なコードではwinforms.pyを取り除けるようにするため、winforms.*といった名前を使わない。

あるいは、(2)の代案として、

(2') 最終的なコードがUbuntuでも実行できるようにするため、パッケージ名のショートカットの部分だけを提供するような偽winforms.pyを用意する。

という風にすれば良さそう（少なくとも小さなサンプルを2, 3試した限りでは）。

実際には、Monoと.Netとでは機能の有無以外にも「ちょっとした」振る舞いの違いとかがありそうなので、コードがUbuntuでも動作するかどうか、開発中はこまめにチェックする必要があると思います、と但し書きを付けておきます。

ちなみに。

いろいろやってるうちに気がついたのですが、（PYTHONPATHのIronPython版である）環境変数IRONPYTHONPATHでは、パス区切り文字が「￥」ではなく「/」とするらしい。

IronPythonのチュートリアルのディレクトリに入っているwinforms.pyにパスを通すには、

set IRONPYTHONPATH=C:/Program Files/IronPython 2.0.1/Tutorial

となります。違和感ある。

IronPythonでマルチプラットフォームGUIの可能性 #1

ちょっと時間を取って、IronPythonでいわゆるWinformsを使うGUIを試してみます。Windowsで動くのは当然として、できれば、Ubuntuでも動いてくれるとうれしい。

Ubuntu 9.04のMonoは2.0、要は.Net Framework 2.0相当なので、このバージョンの機能ならおそらく動いてくれるはずです。

いろいろやって気がついたのは、IronPythonの配布ファイルに含まれている、winforms.pyはMonoでは動かないこと。

これは惜しい。このwinforms.pyは2つの意味で便利なので。

1つ目は、winfoms.pyをインポートすることにより、対話モードでGUIを試すことができます。

IronPythonのシェルから、対話的にフォームを作って、ボタンを貼り付けて、テキストや色を変えて、と、いろいろ実験するにはうってつけです。

2つ目は、winforms.pyはパッケージ名のいわばショートカットを提供すること。

本来は、System.Windows.Forms.FormとかSystem.Drawing.Pointみたいに別個のパッケージに分かれているのを、winforms.Form, winforms.Pointといった名前で使うことができます。

Monoでwinforms.pyが動かない原因は、winforms.pyがスレッドを裏で作ってメッセージポンプ（今はそんな言い方しないかも）を回す、という機能が、Monoでは提供されていないコンポーネントで実現されていることでした。コードを見る限り、Monoで動くwinforms.pyの代替品を用意することは難しそうです。

マルチプラットフォームのためには、この便利なやつ、winforms.pyはあきらめるしかないのでしょうか？

（続く）

boolはintだった

Pythonを使っていて、

if isinstance(item, int):
　ほげほげ
elif isinstance(item, bool):
　ふがふが

というコードを書いてハマりました。

itemがTrueのとき、「ふがふが」のところを通りません。

デバッガで追いかけてやっと、isinstance(True, int)が真になるからだと分かりました。

何故か？それはboolはintのサブクラスだから。

以下はPython 2.6では全部成立します。

isinstance(True, int) == True
isinstance(False, int) == True
issubclass(bool, int) == True
1 == True
0 == False

もうだいぶ使っているのですが、ちーとも気づいていませんでした。

あー、バッドノウハウっぽい。

Python json: 不思議。

jsonパッケージをちょっと試してみようと思って、疑問が。

自前で定義したクラスのオブジェクトをシリアライズ（要はjsonの表現に変換）したいですが、

いくつかサンプルを当たってみると、

どうやら、シリアライズするときはヘルパクラスを用意して、復元（デシリアライズ）するときはヘルパ関数を用意するらしい。

なぜ非対称になってるんでしょうか？

不思議。

2CPU × 4コア × 2ハイパースレッド

「うひゃ」と思わず声が。

タスクマネージャの「CPU使用率の履歴」が16本。カタログスペックとしては知ってたけど、実際に目にすると、実感わきまくり。

今、（あんまりスペックをだらだら書くのはアレなので簡単に）Mac Proを買ってきてVista 64bitをインストールしたマシンをいろいろいじっている最中です。

真っ当にOS Xを使ってる人には怒られそうな使い方ですが・・・。

明日からのテストが楽しみです。

(2009/06/23 一部修正)

日進月歩、万歩計

健康のために一駅歩こう、というのを最近やっていて、そのノリ（？）でとうとう万歩計を買ってしまいました。

いろいろ比べてみて、結局シチズンのTW700にしました。

使い初めにいろいろ登録しないといけなくて、ちょっと辟易しました。時計合わせ、歩幅（取説に身長から換算する表が付いてました）、体重、果ては１日あたりの目標歩数まで。

が、いざ使うとなると、操作する必要がなさすぎて拍子抜け。電源スイッチすらない。ボタンを押すのは情報を引き出したいときだけ。歩数、移動距離、消費カロリーまで、いろいろ出ます。１日ごとに集計されたものが。

USBでPCと接続してデータを吸い上げることが可能らしい。一応選定理由の一つだったのですが、本体だけでも十分な気もしてきて、まだやってません。

まー、数年前（十数年前だったか）に見た万歩計とは比べ物にならないくらい、きっちり進化してますね。

この分だと、１年後にはGPS内蔵して移動ルートも記憶するようになったりして。
・・・って、それはもはや万歩計とは呼ばないか。

Original Sin、て分かってたことなのに

記事「"Original Sin" (Would Java be Better Off Without Primitives?)」
http://www.infoq.com/news/2009/06/java-without-primitives

（日本語訳
http://www.infoq.com/jp/news/2009/06/java-without-primitives
）

より。

プリミティブ型を排してすべてをオブジェクトにすべきだ、というもの。

そうすれば、「charが16ビットであるために、最初は文字だったのが、エンコードされたコードポイントを扱わなくならなくなった」といったような事態をさけることができたはず、という議論です。

言いたいことはわかるけど、ほんとの原因はそこかなあ？という感想。

Write once, run anywhereなどというスローガンのために、intのビット数とか、桁あふれしたときの丸め方とかまで仕様として決める必要があったわけで（記憶によると）。それがなかったら、Javaが今のように普及してたかどうか。

特に、charに関して言えば、当時から日本では16ビットの文字集合に非難ごうごうだったわけで、馬耳東風で採用した段階でこうなるのは見えてたわけだし。

個人的には、言語のプリミティブを変更できるほど、コミュニティに体力（気力）が残ってるのかなあ、というのも疑問です。