mono::

Recent Mono’s Apps.

最近すっかりと忘れてしまっているぽい? mono に関連したアプリを、いろいろビルド・インストールしてみた:
beagle (v0.2.4):
リソースの大食らいは相変わらずだけれども (改善策はあるようだ)、検索 UI が変更になったり (実行形式名も best から beagle-search に変わった)、検索フィルタが増えたり、主観的だけど 0.1.x 系と比較して一次検索結果が出るまでのパフォーマンスも良くなったような気がする。よく落ちるけど。
UI の変更に伴って ja.po も更新しておいた。ただ、beagle/Util/StringFu.cs クラス経由で表示される年月日 (MMMM d yyyy) は DateTime クラスをそのまま文字列に変換しているので、strftime 的な順番で翻訳できないみたいだ:
夏目漱石を引き合いに出したのは、特に理由はありません
beagle-search-2006041301.png
検索速度が速くなった分、エントリを入力する際に何か引っかかる感じがする
beagle-search-2006041302.png
mono-debugger: (v0.12)
K26/GLibc に依存するため、今まで何回か Try してきたけれど、Ubuntu の環境にして、何とかまともにビルドできたという感じ。未だあまり使ったことがない。

aihana@mikeforce2:~>mdb ./work/Projects/blogtk-sharp/src/blogtk-sharp.exe
Mono Debugger
(mdb) help
List of families of commands:
aliases -- Aliases of other commands running -- Running the program breakpoints -- Making program stops at certain points catchpoints -- Dealing with exceptions threads -- Dealing with multiple threads stack -- Examining the stack files -- Specifying and examining files data -- Examining data internal -- Maintenance commands obscure -- Obscure features support -- Support facilities
Type "help" followed by a class name for a list of commands in that family. Type "help" followed by a command name for full documentation.
(mdb)

heap-buddy: (v0.1)
ヒープ領域のメモリ・プロファイラ。このバージョンではメモリ使用量をレポートする機能のみ。もう少し追ってみる必要ある結果:

aihana@mikeforce2:~>beagled --fg --debug-memory --heap-buddy
*** Running with heap-buddy ***
Debug: Starting Beagle Daemon (version 0.2.4)
Debug: Running on Mono 1.1.13.6
Debug: Command Line: /usr/lib/beagle/BeagleDaemon.exe --fg --debug-memory --heap-buddy
Debug: Memory usage: VmSize=31.2 MB, VmRSS=10.8 MB,  GC.GetTotalMemory=319488
Debug: Starting main loop
Debug: Starting messaging server
Debug: Starting QueryDriver
Debug: Found index helper at /usr/lib/beagle/beagled-index-helper
Debug: Found 2 backends in /usr/lib/beagle/Backends/EvolutionBackends.dll
Debug: KMail folders not found. Will keep trying
Debug: Starting Inotify Backend
Debug: Memory usage: VmSize=53.3 MB, VmRSS=31.2 MB,  GC.GetTotalMemory=2355200
Debug: Memory usage: VmSize=53.3 MB, VmRSS=31.9 MB,  GC.GetTotalMemory=2883584
Debug: Memory usage: VmSize=55.5 MB, VmRSS=32.2 MB,  GC.GetTotalMemory=2985984
Debug: Memory usage: VmSize=55.5 MB, VmRSS=32.2 MB,  GC.GetTotalMemory=2985984
Debug: Memory usage: VmSize=55.5 MB, VmRSS=32.2 MB,  GC.GetTotalMemory=2985984
Debug: Memory usage: VmSize=55.5 MB, VmRSS=32.2 MB,  GC.GetTotalMemory=2985984
...
aihana@mikeforce2:~>ll ./outfile.beagled
Directory: /home/aihana
-rw-r--r-- aihana   aihana   2006-04-13 23:46         2556276  outfile.beagled
1 entries,  1 regular files with 2556276 bytes total siz
aihana@mikeforce2:~>heap-buddy  ./outfile.beagled summary
SUMMARY
Filename: ./outfile.beagled Allocated Bytes: 12.3M Allocated Objects: 308736 GCs: 19 Resizes: 8 Final heap size: 4.3M
Distinct Types: 290 Backtraces: 5729

monodevelop: (v0.10)
先日リリースされた v0.10 を使ってみた。前のバージョンから大きく変わったね。IDE のいろいろな機能がモジュール・スタイルになったのか。AddInマネージャ で最新版をダウンロードして利用するなんて Eclipse みたい。基本的な IDE 機能 (ソリューションの作成とかエディタとか) は前よりも良くなっていて、ちょっと嬉しい:
monodevelop-20060412.png
GUI デザイナがデフォルト AddIn として搭載されているようなので、使ってみた。右下のプロパティ・ボックスでいろいろ属性を変更できるんだけど、ちと使いづらい。
monodevelop-designer-20060412.png
ちょっと想い出しがてら、久々に Gtk# アプリでも作ってみたくなったよ。

A beagled is a hog.

今日、帰宅してメールを同期してみるとメールを取得できない旨のエラー・ダイアログが出た。Network は特に問題がないようだし。ハテ!? 再び同期してみると『ファイルを保存できない』とのこと。Evolution を終了しても設定ファイルさえも保存できないのか応答が返ってこない。その瞬間、A disk is full であると直感し df -h すると、ホントに 100% の使用率だった。
このような状態の場合、急いで原因を突き止めて対処しなければならないけれど、一般的に何を推測しどう対処するものなんだろうか。
自分の場合、今まで経験した同じ状況を思い出して、一瞬で推測した原因はそれほど多くない:

  1. セキュリティ?
    一応 Firewall を介しているものの常時接続ということで、まず外部からの第三者による侵入の可能性
  2. ローカル・システム?
    ローカルシステムでシステム・デーモンやユーザ・デーモンがはき出すログや出力ファイルの肥大化
  3. 物理デバイス?
    HDDが物理的に逝ってしまった可能性
  4. パルプンテ?

事は重大で緊急性を要すわけだから、内心ではアドレナリンが放出され精神的なストレスを受けつつ頭の中はフル回転する訳だけれど、見覚えのない突然の出来事なんで、開いている端末から ls やら df やらのコマンドを連発するなど、次にすべき行動としては頼りないものが多い。こんな状態だとコマンドからの応答性も不確実なものだし、思い浮かぶ原因なんかも完璧に的を射た選択肢ってそれほど多くないな。
思い浮かぶ順番だって結構重要だ。本当なら考えられる原因を同時に複数のオペレーションによって調査しないといけないものな。
と前置きが長くなったけれど、タイトルにあるとおり Beagle が犯人だった。システムは問題なく、/home 以下だけが 100% 使用率だったので、ウェブ・ブラウザやメールのキャッシュや ccache のキャッシュやら片っ端から考えられそうな場所で du -hs を実行してみた結果なんだけど:
(順番に怪しそうなディレクトリを削除しているので空き容量はやや増えているが、問題発生当初はもちろん残り 0M)
Beagled_is_a_hog.png
バージョン 0.1.x になってから動作の方は安定したのか、メモリの大食い とか ディスクの大食い なんていう別の (深刻な) 報告が ML に流れていたんだけど、まさか自分も遭遇するとは。その対応として、Search & Indexing という設定ダイアログが導入されインデックスを生成するフォルダを指定できるようになったとはいえ、遅かれ早かれ、いつかはパンクするよな。
問題が発生したときの設定:
(毎日作業している場所がホームだからな。ちょっと恐ろしいな)
beagle-setting-20051102.png
セッション起動時に beagled を起動するのを止めるかな。必須アイテムというわけにはいかないな。

Mono upgraded, and yet another Music Player comes in.

Mono の v1.1.9 が リリースされていた。64bit対応とか Cairo-1.0 対応か。ついでに ARM への移植も進んでいるようで、Nokia 770 上で Mono も 動くようだ
すごいねぇ〜。もしかしたら Linux Kernel を他のアーキテクチャに移植するよりも、エキサイトする開発だったりして :D

--with-static_mono=yes,no      link mono statically to libmono (faster)

てのも気になるが、一応無効でビルド・インストールしておく。
で、Mono 対応の GNOME デスクトップ・アプリとしては、新しくなった inotify 対応の Beagle-0.1.0 がリリースされた他に、The GNOME Journal でも取り上げられていた Banshee 楽曲プレイヤー がリリースされた。CD からのリッピングはもちろん、Apple iPod との同期や再生、演奏一覧の編集など (ipod-sharp 対応)、Rhythmbox よりも気になる Features が盛り込まれている。再生エンジンは GNOME デフォルトの GStreamer の他に RealPlayer/HelixPlayer にも切り替え可能。ということで、日本語メッセージ翻訳を開始するも自身が iPod 持っていないので訳に不安が残るし、完訳までもう少し時間がかかりそう。誰か貸してくれ〜 =)
出来の方は楽曲ライブラリを再読込できず∞ループ状態に入ったりして、まだまだ不安定だし、i18N の方も以前調査した Mono の決定的な i18N 問題 を引きずった感じ:
banshee-20050917.png
Bealge もビルド・インストールしたけど、以前よりは exception 吐くこともなく安定している。インデックス作成などの設定ができる capplet が追加されているので、こちらの日本語メッセージも更新しないとな (以前は、これも i18N 問題で翻訳した文字が全く表示されていなかったが、どうだろうか)。

“Mono – A Developer’s Notebook” in Japanese.

O’Reilly Japan から 開発者ノートシリーズ – Mono の見本 (印刷第一号) が届きました。想像していたよりも厚い (総ページ数は約300ページで、原本の厚さとさほど変わらない) のでちょっとびっくりした:
mdn-20050722.png
丸ごと一冊の本を翻訳するのは、もちろん初めての経験で、いろいろと苦労した点がありましたが良い経験になりました。関係者の皆さんにお礼申し上げます。
原本は昨年リリースされたもので、使用している Mono のバージョンや開発環境の違いなどがあり、その辺りは (注意書きを挿入して) 本文を変更したり、適宜訳注を追加したりして対応してあります。まぁ、この手の技術本はホント “生もの” なので、そのうち賞味期限切れになってしまう部分が出てくるのはやむを得ないのですが…:$
あとは、GNOME に関連するトピックやリンクも充実させてあります (ただ、印刷物なので長い URL を手入力しなければならないですが)。
他に苦労した点というと、原本をお読みになった方は分かると思いますが、原本自体に “誤植” が多かったこと。ここにある Errata の他にもいろいろありました。そういう部分は直接、Edd 氏や Niel 氏とメールでやりとりして修正したり、独自の判断による修正も行いました。なので、総合的に原本よりも内容が充実しているということになりますので、こっちの日本語版を読むことをお奨めします :P
また、噂では原本の 2nd Edition が予定されているとのこと。誤植の数からみても、その方が妥当かと思う。
さてさて O’Reilly さんから頂いた本、どこか (誰か) に献本したいけど、どうしたものか。

Custom Toolbar in BloGTK#.

オリジナルのアイコン (Gtk.Image) を持つツールバー・ボタン (Gtk.ToolbarButton) を作る場合は、GladeXML ではなく、ツールバー (Gtk.Toolbar) の メソッド を使い、ウィジットを後付けしていく。これにより、ボタンのラベルやツールチップに対して Catalog.GetString() が使えるので .po ファイルを使った I18N 表示が可能になる。
実際の GladeXML には、コード上で生成したツールバーを格納するためのコンテナだけ配置する:
blogtk-glade-20050626.png
1段目は、これまた直接実装することになるメニュー・ウィジットを格納する Gtk.Vbox で、2段目は GladeXML に記述したストック・アイテムを使ったツールバー、3段目がカスタム・ツールバーを配置する部分で、Gtk.HandleBox の上に Gtk.Toolbar を配置し、必要なボタンの数だけコンテナを確保しておく。
実装の手順としては、
1. オリジナル・アイコンをストック・アイテムに登録しておく:
GTK+ が標準で提供しているアイコン (ストック・アイテム) に加え、オリジナルのアイコン・ファイルを登録する。これにより、標準のストック・アイテムを扱う方法で、オリジナルのファイルを利用できるようになる:

// Variables :: Stock Icons
private static readonly string [] stock_icons = {
"b-32",
"blogtk-icon",
"blogtk-logo",
"stock_insert-image",
"stock_insert-table",
"stock_link",
"stock_para",
"stock_text_indent",
};
// StockIcon::Initialize() public static void Initialize () { IconFactory factory = new IconFactory (); factory.AddDefault ();
// Stock Icons foreach (string name in stock_icons) { Pixbuf pixbuf = new Pixbuf (null, name + ".png"); IconSet iconset = new IconSet (pixbuf); factory.Add (name, iconset); } }

このように、アイコン・ファイル *.png をストック・アイコン・ファクトリに登録する Initialize() メソッドを持った StockIcon クラスを用意しておき、プログラムを起動して初期化処理を行う際に一緒に呼び出しておく。
すると、例えば 閉じる なアイコンを画像データにする

Gdk.Image icon = new Gdk.Image (Gtk.Stock.Open, Gtk.IconSize.Menu);

場合と同じように、オリジナルのファイルからアイコンを生成できる:

Gdk.Image icon = new Gdk.Image ("stock.para", Gtk.IconSize.Menu);

2. ツールバー・オブジェクトを取得しておく:
GladeXML に記述したウィジット名を、そのままコードの中から引用できるようなメンバで宣言しておく:

[Glade.Widget] private Toolbar    toolbar2;

3. AppendItem()を使ってボタンを作成し配置する:
あとは、ツールバー toolbar2 のメソッド AppendItem() を使って、順番にボタン (やセパレータ) を後付けする。その際に、ラベルやツールチップの文字列を I18N 化したり、アイコンを指定したり、イベント・ハンドラを指定する:

Gtk.Widget paraToolButton =
toolbar2.AppendItem (
Catalog.GetString ("Paragraph"),
Catalog.GetString ("Insert Paragraph Tag"),
null,
new Gtk.Image ("stock_para", toolbar.IconSize),
new Gtk.SignalFunc (paraToolButtonClicked));

その結果、mcs でコンパイルすると、次のようなツールバーとなって表示される。ツールチップも ja.po で翻訳されたものが表示される:
blogtk-customtoolbar-20050626.png
ということで、2段目の標準ツールバーやその他のラベルも、上のような GladeXML ではなく、直接コードで実装しなければならない。とどのつまり、Glade-2 で構築するのは、ただ単に UI をパッキングするためのコンテナだけになってしまい、確実にC言語アプリの場合よりも UI 構築の効率が悪い。