近況報告たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。動向はもえじら組ブログで。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。2010半分眠ったまんまで作業してたのでしょーもないregressionを仕込む→修正して公開→またregressionということを繰り返した結果、既に0.13.3になってしまったわけですが、バージョン0.13.0で結構大きくいじりました。機能的には全然変わってないですが。2をサポートしなくなりました。3の間で大きく変わったAPIの両方に対応するためのめんどくさい場合分けをゴソッと削除できたりしたので、だいぶスッキリした気がします。ウィンドウごとに分ける必要がないコードでXPCOMコンポーネント化してなかった物は積極的にJavaScriptコードモジュール化しました。Thunderbird専用のコードは、XPCOMコンポーネントにしてはあったものの、そんなに汎用性が無かったので、これも全部JavaScriptコードモジュール化しました。検索でヒットした箇所が多い時に、Safari風の強調表示等の機能を有効にしているとフリーズしてしまう問題について、ヒット箇所の強調表示を段階的に非同期で行うようにしてみました(0.13.4)。1.9.2以降ではnsIDOMWindowUtilsのnodesFromRect()を使うようにしたので、見えているスクロール位置から検索を始める処理が相当速くなりました。Rangeから検索用のテキストを取得する部分が爆速になりました。4.0b2preではページ内検索のストレスがほとんど無くなったと思います。clipboardがfixされたおかげです。これまでXUL/Migemoのページ内検索が非常に重かったのは、Rangeを一旦文字列にして正規表現でマッチングして、その結果を使ってもう一度ページ内検索するという仕組みに理由があります。この時、RangeをそのままtoString()で文字列にすると、CSSで非表示になっている要素のテキストまで一緒に取得されてしまうのですが、その後rangefindで検索する時は非表示のテキストは検索対象にならないため、場合によってはヒット箇所が飛ばされてしまったり検索が止まってしまったりという問題が起こります。textNode.nodeValue.length)というやり方で個々のテキストノードの可視・不可視の状態を判別して不可視のテキストを除外した結果を取得して、正規表現のマッチングに使うようにしていました。この方法は、テキストノードの数が増えると判断の回数も同じだけ増えてしまうため、MXRのページのように内容が小さなテキストノードに分断されているページだととんでもなく処理に時間がかかってしまいます。39098で入った変更によって、テキストリンクの高速化の時にも使ったnsIDocumentEncoderに、「非表示状態のテキストを結果の文字列に出力しない」というオプションが加わりました。Minefield上では、この機能を使ってRangeの中の可視状態のテキストだけを一気に取得するようにしました。0.13.xを入れてMXRのページでページ内検索してみると、効果の程がよく分かると思います。3.6を窓から投げ捨ててしまいたくなりました。あとはJägerMonkeyが入ってくれれば......ところで、他のアドオンからXUL/MigemoのAPIを呼び出す時はちょっと注意が必要になってます。前に「ユーザ辞書の内容がWebページのスクリプトから取れてしまうのはセキュリティ的に宜しくない」という指摘を受けたんですが、どうやってこの問題を回避すればいいものか悩んで、結局、グローバルなJavaScriptのプロパティのmigemoオブジェクトから機能を呼び出す時には常にシステム辞書の内容だけを返すように仕様を変えました。ユーザ辞書に追加された単語も含めた正規表現を取得したい場合、Components.utils.import('resource://xulmigemo-modules/service.jsm')でユーティリティを読み込んでXMigemoCoreの各メソッドを呼ぶか、Cc['@piro.sakura.ne.jp/xmigemo/factory;1'].getService(Ci.xmIXMigemoFactory).getService('ja')てな感じでXPCOMコンポーネントを直接呼び出すかする必要があります。RegExp()してやる必要があります。辞書が絡まない機能はmigemoのメソッドを使って問題ありません。XUL/MigemoのUI周りでもそうしてます。gFindBarの遅延初期化には対応した。})で、遅延初期化のタイミングで初期化を行える。XPCOMコンポーネントの登録方法の仕様変更にも対応した。これから先、できれば仕様は変わらないでいて欲しいけど......classDescriptionにホワイトスペース文字が入ってると、カテゴリへの登録がうまくいかないかも。nsUpdateTimerManagerに対応するマニフェストファイルなんかを見てみた感じでは、実装のクラス名をそのままclassDescriptionにするといいのだろうか?nsSidebar.jsに対応するマニフェストファイルを見て分かったけど、今までカテゴリマネージャに登録する必要があったケースは全部マニフェストファイルでやるという事のようだ。マニフェストファイルの方に書いておかないと、ちゃんと認識されなかった。4.0b2pre基準にする事にする。2用のコードは全廃する事にした。rangefindを使う時に注意がいる。他アドオンとの連携にも注意がいる。しないといけないなーと思ってる課題。Minefieldに既に入ってる、スマートロケーションバーの候補として出てきたplaceが既にタブで開かれている場合にそのタブに切り替える機能への対応。フォルダペイン内での絞り込みはできるようにしとかないと......とは思ってる。スマートロケーションバー関係を調べて分かった事。Minefieldは、タブで閲覧中のページをtabbrowserが持ってるプログレスリスナで常時監視してて、タブで閲覧中のplaceの一覧をmoz_openpages_tempという名前のテーブルに保存している。このテーブルはplace_idとopen_countという2つのカラムを持ち、ページの遷移に応じて内容が随時更新される。検索でヒットしたplaceについて、このmoz_openpages_tempのopen_countが0より大きい物は、オートコンプリートの候補として返される時にURIの前にmoz-action:switchtab,という文字列が付与され、lichlistitemのtype属性用の値にはactionという値が設定される。スマートロケーションバーのオートコンプリートの実装はいつの間にかJavaScriptになっていた。Cより読み慣れてるから助かる。この機能が有効になるのは、オートコンプリート用のtextboxのautocompletesearchparam属性の値にenable-actionsという文字列が含まれている時だけのようだ。機能が無効になっている時は、単に上記の「URIの前にmoz-action:switchtab,という文字列が付与され~」という処理がスキップされる。この事から分かる通り、moz_openpages_tempのopen_countはオートコンプリートの候補の並び順には影響しない。frequencyベースで検索していて、ヒットした候補の中にたまたま現在タブで開かれているplaceが含まれていた場合にだけ、この機能が発動するという仕様のようだ。ロケーションバーへの入力時に「タブで開いてる奴だけ表示」という風に制限する時の既定のキーワードは「%」。0.12.xで、機能を他のアドオンとかから呼び出すためのAPIを刷新してみたよ。古いAPI(はてなブックマーク拡張とかが使ってくれてるやつ)は僕自身が色々よく分からないまま作った物だったために、引数を文字列で渡さないといけないとか戻り値も正規表現オブジェクトではなく文字列だとか、色々と使い勝手が悪かったと思う。メインウィンドウ以外では呼び出す時にいちいちXPConnect使わないといかんし。新しいAPIは、それに比べたらものっそシンプルになった。XPConnect使わなくてもmigemo.getRegExp('hoge')とか書くだけで使えるし、戻り値もすぐに使える正規表現オブジェクトが返ってくるし。互換性を保つために旧APIはそのまま残してあるので、旧APIを使ってるアドオンが動かなくなるということはないけど、今後は使うなら新APIの方を使うのがお勧めです。このAPIはWebページ内のスクリプトでもCPUの使用率を取得できるようにするAPIを提供する例のアドオンの技術の応用なので、Webページ内のスクリプトからもXUL/Migemoの機能を利用できてしまいます。スクリプトの実行権限の関係で、上記のmigemo.getRegExp('hoge')のような、正規表現オブジェクトを直に受け取る機能は使えません。0.12.2以降が入ってる環境でこのページを表示してれば、以下のデモを試せるはず。コーラ日本酒ビールページ内検索系のメソッドもあるんだけど、多分使いでがなさそうなので解説は用意してないです。上でもリンクしてるけど、エンジンごとページ内に埋め込めるJavaScript/Migemoという実装もあるから、XUL/Migemoを入れてるFirefoxユーザでないと使えないこのAPIってなんか意味あんの?と言われそう。このエントリでは、「Webページ上のスクリプトからもmigemo.getRegExp('hoge')のようにして正規表現を取得して利用できる」という風な書き方をしてたけど、これは大間違いだった。戻り値の正規表現オブジェクトが生成された実行コンテキストがUniversalXPConnect特権のある場所なのに対して、呼び出し元は特権のない普通のWebページ上であるため、それぞれの権限が違うので本来ならその正規表現の各メソッドは実行できないのが正しい。3.5)以前のバージョンにはバグがあって、上記のようなセキュリティのチェックが働かないために、戻り値の正規表現の各メソッドを呼べてしまう状態になっていた。いうエラーがエラーコンソール上に出力される。いうことで、JavaScript/Migemo互換のAPIとして正規表現オブジェクトのソース文字列だけを返すような機能を0.12.2で新たに加えた。1.9.2以降でもWeb上で使える。Magazineさて、もう一つの検索方法である「英語(辞書アシスト検索)」であるが、これは英単語を入力するとその対訳となる日本語の単語が検索されるというモードだ。筆者の環境ではうまく機能しなかったのだが、一応使い方を説明しておく。そんな機能実装した覚えないんですけど......英語モードは、僕が正式にXUL/Migemoを引き継いだ後に行った大改造において、将来的に日本語だけでなく中国語や韓国語などのIMが必要な他の言語に対応できるよう、言語依存の主要モジュールを差し替え可能にした時に、日本語特有の処理(ローマ字入力を平仮名に変換するなどの処理)を含まないプレーンなモジュールの実装例として用意した物だ。Firefox自身の通常の検索機能と比較して、このモードで具体的に起こる変化としては、「ext」まで入力した時点で「extension」「extend」等の英単語が強調表示されるようになる、という感じなんだけれども......これってぶっちゃけ無意味なんだよね。日本語では、入力した文字列(ローマ字)とページ内のヒット箇所(仮名漢字交じり)の文字列とが一致しない。「kanj」と入力した段階で登録済み単語の「漢字」にヒットしてくれれば、総キータイプ数が少なくなる。→メリットがある!英語では、入力した文字列とページ内のヒット箇所とが原則として一致する。補完が無くても元々キータイプ数は最小で済む。→メリットが無い!あとは、発音記号付きのアルファベット等を区別せずに検索できるようになるけど、それとて日本語用のエンジンに既に包含されている機能だし。言えば、日本語とかローマ字とか全然興味がないし必要も無いという英語圏のユーザの人が、Safari風の強調表示だけ利用する時に、ほとんど何も余計なことをしないから邪魔にならない......ということくらいだろうか。英語モードのメリットは。「これこれこういう凄いことができるようになる」といった類の意義は皆無だ。そのモードを作った本人が言うんだから、間違いないよ。2009今の所、XUL/Migemoの辞書ファイルは全部普通のテキストファイルなんだけど、これをSQLiteデータベースに置き換えてみようかなと思ってる。メリットがあるのかどうかは分からないんだが。現在の辞書周りは基本的にはplus7さんが作られた物を踏襲していて、起動時に全ての内容を読み込み、JavaScriptの普通の文字列としてオンメモリで保持しておくようになってる。これだとFennecで動かすのって多分きついだろうなあ、とは思ってた。Fennecのデフォルト設定を見た限りでは、履歴の保持日数はFirefoxと同じ90~180日となってるから、これを全部メモリ上に読み込んだらエラい事になるよねぇ。それとも、これは単にFennec開発陣がSQLiteを過信あるいはモバイルプラットフォームを甘く見てただけで、実は全部オンメモリになっちゃいますとか?まあとりあえず実装するだけしてみて、それから考えてみよう............とりあえずやってみたけど、なんか、めさめさ重い......ちゃんと作ってないから単にどっかで無限ループしてるのかもだけど。それを抜きにしても、辞書が約4MBだったのがSQLiteにしたら9MBに膨れ上がってしまった。モバイルで使うなんてのはますます非現実的な領域だ。工夫しないと全然お話にならんね......追記。進めてみたけど、余計泥沼に嵌ってる気がしてきた。バックエンドのSQLite化は無しだな、というのが現時点での結論ですわ。3.5でも機能に影響を与えない範囲で内部的なSQL文がいくつか修正されたそうでるかもしれないそうだ。fasterでもTrunkにチェックインされたパッチを見ても、どうしてこれで速くなるのか、何が良くなかったのかが、さっぱりわかんない。Hacksの件で明らかなように僕のSQL知識不足は深刻なので、きっと物凄いオーバーヘッドがあると思う。誰か改善してくれないかなあー。2009次の版をリリースする前にやっとかなきゃ、と毎回毎回思いながら放置してた、ロケーションバーまわりの自動テストを昨日の晩からちょっとずつ作り始めてる。places.test.jslocationBarOverlay.test.jsどっちもUxU用のテストケースです。3.1で導入されたキーワードによる絞り込みのテストは以前書いてたので、それ以外の、SQL文を生成したりとかデータベースから結果を取り出したりとかの部分のテストを今作ってる。後回しにしてしまってたかというと、Placesのデータベースが絡んでくるから、Railsのfixtureみたいなのを上手くやれる仕組みができないことにはどうにもならないと思ってたせい。プロファイルを指定してテストを実行する機能を使えば問題ないんだけど、これはテストの実行がめちゃんこ遅くなるからなるべく使いたくないわけで......(←ひどい)でもそれを言い訳にしていつまでも放置してる方が良くないよなと思ったので、一念発起して、Placesデータベースとの間でべったりだった所とかメソッド間の依存でシッチャカメッチャカになってた所とかを整理して、純粋にロジックだけの単体テストをしやすいように修正を進めてる。千里の道も一歩から......ちょっとずつ切り崩して、ゴールに近づいていこう。Railsやってて、前は既に動いてたプロジェクトのお手伝いという立場だったんだけど今回はゼロからのスクラッチだったから、何か作ってはすぐテスト書いて......みたいなサイクルで作業してて、その影響だと思う。テスト書かなきゃ気持ち悪い、みたいな。Rubyばっか書いてたから、ついつい普通のハッシュでhash.eachとか書きそうになってしまったり、メソッドの最後のreturnを書かずに値だけ書いてしまいそうになったり、行末のセミコロンを書き忘れそうになったり、ハッシュの前後を囲うブラケットを書き忘れそうになったり、メソッドを呼び出す時に括弧を書き忘れそうになったり、functionと書くべき所をdefと書きそうになってしまったり、だんだん思考が侵食されてきてて困る。