Hatena::ブログ(Diary)

Windchase

2008.1.25

InputSwitcher 0.6 リリース

Thunderbird との相性が悪いので、Firefox に加え、Thunderbird も例外として扱うようにしました。

http://limechat.net/inputswitcher/index_ja.html

InputSwitcher ユーザへのお願い

追記3 (2009.8.28)

Snow Leopard で、「書類ごとに異なる入力ソースを使用する」オプションが復活したので、解決しました。

Leopard で無くなった「ウィンドウごとに入力ソースの状態を保持する」オプションを復活させるように、Apple にバグレポートを送ってください。

いまのままでは、10.6 まで改善される見込みがないそうです。みなさんの声が多ければ多いほど、Apple 内部の開発者が改善に動きやすくなるようです。

ぼくが InputSwitcher を開発したのは、Leopard を使い始めてすぐにここが不便だと思ったからです。しかし、InputSwitcher は一時的な回避策でしかなく、根本的に解決するには OS で対応してもらうしかありません。

というのも、ソースを見てもらえればわかりますが、TextInputSource API がうまく動かないケースがあるので、それを回避するために泥臭い対策を講じたり、Firefox や Thunderbird で挙動がおかしくなるのでそれらを例外的に扱ったりしているのですが、この方向では完全に動くようになる見込みがないからです。

バグレポートは、http://bugreporter.apple.com/ から送ってください。開発者に直接声が届きます。(ADC の無料アカウントが必要)

Apple のウェブサイトからだと途中でフィルタリングされるらしく、開発者に届く可能性はかなり低いようです。

参考までに、ぼくが送ったレポートを載せておきます。

"Allow a different input source for each document" is missing on Leopard

Hi,

Leopard seems to exclude the option "Allow a different input source for each document" in the International preference. It's an essential function for multilingual people like me. I suggest that the option should be added again.

I'm a Japanese and always use Japanese and English input sources. For example, I did chatting in Japanese on a window, and then moved to a terminal window, the input source remains Japanese even if I want to input English in terminal windows.

It's very inconvenient for me. Then finally I developed a software, InputSwicher.

It allows a different input source state for each application even on Leopard. But it doesn't work for Carbon applications. It is not perfect.

I love Mac OS X since NeXTSTEP. I want to continue using OS X. Please add the option to Leopard again.

Satoshi Nakagawa

追記 (2008.1.26)

レポートを送ってからしばらくすると duplicate で close されてしまうと思いますが、それは気にしないでください。

バグレポートが少ないことが早期に改善しない理由になっているようなので、まずはレポートを送って声を届けることが大切です。ここらへんは日本と文化が違うところですね。

追記2 (2008.1.26)

一応、Apple のウェブサイトから日本語でフィードバックを送れます。

https://regist.apple.co.jp/feedback/macosx/

こっちは、上で

Apple のウェブサイトからだと途中でフィルタリングされるらしく、開発者に届く可能性はかなり低いようです。

と書いたほうなんですが、それでも送らないよりは送ったほうが絶対にいいので、英語がきついという人はこちらから送ってみてください。

2008.1.9

RubyCocoa の dangling pointer 問題を直した

LimeChat for OSX には、かなり低い確率で解放済みのメモリにアクセスしてしまう問題があって、ずっと原因がわからずに困っていた。

今日、たまたま RHG を読み直していたら、あっ、これだっ!!!という項目を見つけた。

http://i.loveruby.net/ja/rhg/book/gc.html

GC対策のvolatile

スタック上のVALUEはGCが面倒を見てくれると書いた。
それならば ローカル変数としてVALUEを置いておけば
そのVALUEは確実にマークされるはずである。
しかし現実には最適化の影響で変数が消えてしまうことがある。
例えば次のような場合は消える可能性がある。

  VALUE str;
  str = rb_str_new2("...");
  printf("%s\n", RSTRING(str)->ptr);

このコードではstr自体にアクセスしていないので、
コンパイラによっては str->ptrだけメモリに残して
strは消してしまうことがある。
そうすると strが回収されて落ちる。
こういう時は仕方がないので、

  volatile VALUE str;

とする。

つまり、ruby の C 拡張で GC に回収されないためには、VALUE がスタックに積まれているか、VALUE がルートからたどれる必要があるらしい。

実際に、RubyCocoa のコードを grep しながらよく調べてみるといくつか危ない箇所があったので、volatile をつけておいた。

送られてきたクラッシュレポートのスタックトレースから判断すると、十中八九これが原因のようだ。

他にも、ruby の文字列から C ポインタを取り出すのに STR2CSTR() を使っている箇所があって、上と同じ問題を引き起こす可能性があるので、全部 StringValuePtr() に書き換えてコミット。(RubyCocoa r2165)

char* を取り出す場合、version 1.6 以前では「STR2CSTR()」というマクロを使っていましたが、これは to_str() による暗黙の型変換結果が GC される可能性があるため、version 1.7 以降では obsolete となり、代わりに StringValue() と StringValuePtr() を使う事を推奨しています。

(ruby の README.EXT.ja より)

この問題以外に、C レベルでクラッシュしたというレポートはまったく来ていないので、RubyCocoa はこれでかなり安定するはず。何はともあれ、RubyCocoa 1.0 までに見つけられてよかったと思う。

2008.1.7

LimeChat 2.22 リリース

http://limechat.net/

3カラムレイアウト (左からサーバツリー、ログ、メンバリストのような表示) を選択できるようにしました。

今までは、常時入っているチャンネル数が多いと、どうしてもメンバリストが狭くなってしまっていたのですが、これでウィンドウの縦幅を大きくしなくてもすべての情報が表示できるようになりました。

設定ダイアログのレイアウトページから指定できます。

  • 3カラムレイアウトに対応した。
  • ログイン時に送信するコマンドを指定できるようにした。
  • ASCII以外の文字をURLの一部として認識するオプションを追加した(デフォルトはオフ)。
  • バルーンを表示する設定をメニューから切り替えられるようにした。
  • mode +h を認識するようにした。
Connection: close