約15年前にEPWINGの全文検索を試みた事があったのですが、それの焼き直しです。

Hyper Estraierを利用するの前回と同様ですが、専用のインデキサを用意して、直接インデックスを作成できるようにしました。 Lookup 1-4+mediaに対応コードを入れたので、インデックスがあれば自動的に使用できます。

かつて、Logic等の音楽制作ソフトを手がけていたemagicという会社がありました。 会社は2002年にアップルに買収され、LogicはLogic Proとして、現在もアップルが販売しています。 emagic社はいくつかのハードウェアも販売していましたが、そのひとつにemi 2|6というオーディオインターフェースがありました。

音質とか性能の話はおいておいて、このデバイスはUSB経由でファームウェアを読み込ませる事でUSB audio class compliantなデバイスとして動作します。 Linuxではドライバはただのfirmware loaderであり、ファームウェア読み込み後は標準のオーディオドライバで動作しています。 また、このデバイスはACアダプタからの電源供給も可能で、その場合、ファームウェア読み込み後は電源が切れるまでUSB audio class compliantなデバイスとして振る舞います。

Windowsへの対応については、メーカーがアップルに買収された事もあり、以降は新たな環境向けのドライバなどは提供されませんでした。 ただし、初期化さえ済ましてしまえば現在のWindowsでも動作は可能です。 そこで、現行のWindowsで動作するfirmware loaderを書いてみました。

前回の続きです。

Hyper Estraierのインデックスがoptimizeで壊れる問題はHyper Estraier側の問題でした。

1. 転置インデックスが複数ファイルにまたがる (通常1.5GiB以上)。
2. 複数回の書き込みが行われている。

上記に当てはまるインデックスにoptimizeをかけるとひっそりと転置インデックスが壊れることがあります。また、

1. ドキュメントの数がとても大きい (確認したものでは約580万)。
2. 各ドキュメントに共通するテキストがとても多い (英語主体で、N-gramを有効にしたインデックスで確認)

上記に当てはまるインデックスにoptimizeをかけると転置インデックスの1ファイルに2GiB以上書き込んでしまい、壊れてしまう事があります。

修正内容はGitHubのリポジトリを参照してください。ついでに2GiB以上のキャッシュサイズの指定に対応していますが、その3倍弱くらいのメモリが必要になるケースがありました。

タグ：Hyper Estraier QDBM

以下の記事は間違いでした。変更で挙動は変わったのですが、変更する前のコードは正しく、挙動が変わった原因は現時点では不明です。

前回に引き続き、QDBMのバグ報告です。

cbdatumcat関数およびCB_DATUMCATマクロが必要なバッファの大きさを1バイト少なく見積もるというものです。 手元ではなぜかSEGVにはならずにプログラムは実行されてしまいますが、Hyper Estraierで巨大なインデックをoptimizeするとインデックスが壊れてしまい、searchできるが不適切な結果が返るようになるバグが修正されました（「巨大な」は必須条件ではく、その方が起きやすいというだけです）。前回分と併せてGitHubのリポジトリで公開しておきます。

タグ：QDBM Hyper Estraier

かなり今更ですが、久しぶりにHyper EstraierとQDBMを自分でビルドしたらうまく動作せず、結局 QDBM のバグだったので一応お知らせしておきます。

最初はsourceforgeにあるHyper EstraierのMLに投稿したのですが、unsubscribeしていたみたいでモデレータ送りになった為、こっちで公開することにしました。