Hironytic Status

Haiku のビルド

CoveredCalc Haiku 版を作るための作業としてまずは Haiku を用意することにしました。うちでは既に実機は用意できない状態なので、Windows 上の VMware Player を使います。なお、CoveredCalc for BeOS 1.10.0 は実は VMware 上の BeOS で開発しました。(^^;

Haiku Files にある vmware イメージだと開発ツールが付属しないのですが、Senryu だと余分なものがありすぎるということで、ソースからビルドすることにしました。その方が Haiku の更新も追いやすいですしね。

だいたい、次のサイトを参考にさせてもらってビルドに成功しました。
・muraiさんのHaikuインストールメモ（Linuxホスト編）
・SHINTAさんの白 Be 全般

さらに詳しく

[CoveredCalc] version 1.10.0 リリース

CoveredCalc version 1.10.0 を リリースしました。
キー定義のカスタマイズがメインです。
1.9.0 をリリースしたのが 去年の 11 月。もともとキー定義のカスタマイズも 1.9.0 で実現する予定でしたが、規模が大きくなるので見送ったのでした。ただ、1.10.0 のリリースまでにこんなに時間がかかるとは思ってませんでした。まあ、CoveredCalc の開発ばかりしてたわけでもないので、放置期間もあったわけですが。(^^;;;

さて、この次のバージョンでは、少し大幅な変更を加えたいなと思っています。
Windows 版を内部 Unicode 動作のアプリにするとか（現在は ANSI/MBCS 動作です）、Win64（64ビットWindows）への対応準備とか。
BeOS 版は Haiku バージョンを作りたいとか。
他にもいくつか、いい機会だと思うので、根本的なところを修正していく予定です。
リリースまでには 1.10.0 にかけた時間よりもっとかかるかもしれませんね（爆）

[CoveredCalc for Windows] メッセージの横取り

Windows版のおはなし。

現在開発中の CoveredCalc のメインはキーカスタマイズなのですが、そのカスタマイズを行うダイアログではどのキーとどの機能を結びつけるかを設定します。「どのキー」を指定するためにキー入力して押されたキーを表示するコントロールを作りました。作りましたっていってもただの Edit コントロールをサブクラス化しただけなんですが‥‥。このコントロールにフォーカスを移した状態で、例えば Shift キーと H キーを押せば、コントロールに「Shift+H」と表示されて Shift+H に対する機能の割り当てができるわけです。
ところが、Alt キーと他のキーを押したとき、コントロールには「Alt+××」と入力されるのですが、そのあと、ダイアログ上のアクセスキーが反応してしまって、別の機能が実行されます。例えば「割り当て(A)」というボタンがあるのですが、Alt+A を押すとこのボタンが押されたことになってしまいます。
‥‥というのが今月のあたまに起こっていたこと。

WM_SYSKEYDOWN メッセージで処理したよと返してやってもシステムが勝手にやっちゃうみたいなんで、BeOS の BMessageFilter みたいに通常のディスパッチに流れる前にメッセージを横取りして、場合によってはディスパッチしなきゃいいんじゃない？と思って、自分のメッセージループにメッセージを横取りする仕組みを加えました。ところが、ダイアログ上ではメッセージが横取りできませんでした。それもそのはず、モーダルダイアログが表示されているときは、Windows API の DialogBox() 関数の中の Windows の用意したメッセージループにいるのです。自分のメッセージループでは横取りできません。ぐはー。
‥‥というのが 2 週間ほど前に起こっていたこと。

どうやって解決しようかなー、MFC みたいにモーダルダイアログに見えるけど実はモードレスダイアログで作って自分のメッセージループを回していましたー的な方法はどうかなー？ と思いながら、すごく面倒くさくなって 2 週間プログラムを放置してました。おかげでドラクエ IV が結構進みました（爆）
昨日になって、ようやく、その似非モーダルダイアログを実装してみました。その結果、期待した動きを得ることができました。つーか実装に 1 時間もかかってない気が‥‥。2 週間の放置はなんだったんだろう。

Subversion のビルドとか

CoveredCalc は Windows 版で一応キーカスタマイズのダイアログができた程度です。BeOS 版をこれから実装。キー入力コントロールを作るところから。遅遅として進みません。
それはそうと、そろそろ Haiku 版も作ってみたいところ。ちょこちょこ Haiku の VMware イメージとかもいじってみたりしています。

ところで、Haiku でも使われている Subversion はファイル名やログメッセージを内部で UTF-8 として保存しています。svn クライアントはローカルの文字コードと UTF-8 の相互変換を行ってくれますので、ユーザーは特に気にしなくていいのですが。‥‥ですが、BeOS 版としてパッケージされているやつは非 ASCII なログメッセージに対応していません。こんな感じになります。

baron@:~# svn log http://coveredcalc.googlecode.com/svn/trunk -r HEAD
------------------------------------------------------------------------
r42 | hironytic | 2008-03-22 18:56:14 -0800 (Sat, 22 Mar 2008) | 7 lines

?\232?\168?\173?\229?\174?\154?\227?\131?\128?\227?\130 ....

この現象は 4 年ほど前、Subversion 1.0.0 リリースの直前頃に経験しているのでなんとなくわかってます。きっと、BeOS 上でビルドしたとき APR-Utility の apu.h で APU_HAVE_ICONV が 0 になってたんだろうと想像しています。APR_HAVE_ICONV が 0 だと APR-Utility で変換が必ず失敗するんで、svn は非 ASCII 文字を仕方なく文字コード表記にするのです。ただ、BeOS はローカルの文字コードが UTF-8 なので、特に変換を行わないように改変すればそれで問題ないんです。

というわけで、今まで BeOS 上ではこのときビルドした version 0.37 (1.0.0-RC1) を使っていたのですが、この機会に（何の機会だ？）最新 stable の 1.4.6 （のクライアント）をビルドしてみようと思いました。

‥‥結果からいうと、make 中にリンクエラーが出て、そこで挫折しています。細かいことはもう少し調べてからまた書きます。

ちなみに Subversion は大きなバージョンアップである 1.5.0 がそろそろ出そうな感じなんですけどね。

gcc をバージョンアップ

ふと思いついて、BeOS 版開発環境の gcc を新しいのに入れ替えてみることにしました。
BeBits にある gcc-2.95.3-beos-070218です。
以前にもそれを考えたことがあったんですが、BeOS 環境が 1 つしかなく、その環境の構築にも苦労していたので、入れ替えて問題があって元に戻せなかったら嫌だなあという思いがあって実行していなかったのでした。今回、VMware Player の仮想マシンで BeOS の開発をできる環境ができたので、すぐに元に戻せるという気楽さからやってみました。

入れ替え自体は README に書かれているとおりで簡単にできたのですが、それで CoveredCalc を make して実行すると Segment Violation になりました。
最適化を OFF にするとこの問題は発生しません。それで、このページを見たところ、どうやら、
・Be コンパイラは、自動的に生成された関数を、それが使われているところのオブジェクトファイルに入れる。これは gcc でいうところの multiple symbol spaces。
・このバージョンの gcc は最適化が OFF のときのみ multiple symbol spaces を使う。
・古いコンパイラでは dynamic_cast などで生成される typeinfo-functions が使っているオブジェクトファイルに入っていたが、このバージョンでは最適化時に single symbol space を使うので‥‥。
・（※私の英語読解力が低いのでよくわからないが）、Beライブラリが持ってる BDirectWindow-typeinfo-function が変なので困ると。

それで、この gcc にはなんか対処は入ってるみたいなんですが、それでも CoveredCalc は落ちているわけで、ためしに multiple symbol spaces を強制してみました。（コンパイルオプションに -fmultiple-symbol-spaces を追加）
すると落ちなくなりました。ばんざーい。

で、実際にこっちの gcc を使うかどうかについてはまだ悩むなぁ。