やっぱり違うな。訂正。 正しいというか、仕様が最も一貫しているのは $1 = '', $2 = 'a', $3 = 'b' だけ。 理由は後で書く。

http://www.siaris.net/index.cgi/Programming/LanguageBits/Ruby/Oniguruma.rdoc/style/printこの中で、ruby、鬼車、perlの仕様の違いが指摘されていた。 $ sruby -e '"abax" =~ /((a)*(b)*)*/; print #{$&}:#{$1}:#{$2}:#{$3}\n"' aba::a:b $ oruby -e '"a…

4.6.1と5.5.3をリリース。 bcc32でコンパイルした場合の問題と、[ruby-Bugs-8970]の対応。

bcc32でコンパイルして実行すると、例外が発生するという報告を受けた。bcc32ではallocaの宣言がmalloc.hの中にあるのに、鬼車はmalloc.hをインクルードしていないことが原因だそうだ。 [ruby-Bugs-8970]の件もあるので、今週中にリリースしたい。

4.6.0をリリース。 主な変更内容は、5.5.2と同じ。

ruby-talkの議論から私個人宛に、流れ弾が飛んできた。 named groupの書き方をPythonの(?P...)のようにしてくれ、という話のようだが、意味が無いので無視しよう。それとは別に、ブラケット以外にシングルクォートも使えるようにするのは、やっても良い気が…

5.5.2をリリース。 01/05に書いた、最適化処理の変更。(速度向上)

鬼車のErlangドライバ使用例を見つけた。 http://d.hatena.ne.jp/erlang/20061231

UTF16-BEが他と比べて遅い現象を解決しようとして調べているうちに、最適化情報の作成処理の中に問題があるのを見つけた。しかしこれはUTF16-BE固有の問題ではなく、全てのエンコーディングで起こる問題だった。/.a/のような簡単なパターンの場合でも、あま…

http://glozer.net/code.html#oregexp Erlangで鬼車を使用するためのbinding

前にも比較したことがあるが、そのときは文字エンコーディング指定がASCIIだった。今回はUTF-8で実行している。 処理時間。鬼車を1.0として。 鬼車5.5.1: 1.00 PCRE 7.0: 1.66かなり前に書いたことがあるが、鬼車はデフォルトの構成では指数関数的組合せ爆発…

最適化情報の内容を出力して確認してみた。 大体様子がわかった。最適化情報が良くない一部のパターンだけ物凄く遅くて、その他のパターンはUTF16-LEと殆ど変わらない速度で動いていると思う。

ベンチマークプログラムをgprofで調べてみた。 forward_search_range()とmatch_at()の呼び出し回数が、UTF-8とUTF16-LEの場合よりもUTF16-BEの場合に、かなり多くなっている。この結果から、BEのときに最適化情報の取り出し方が良くないことが原因だというこ…

ベンチマークプログラムを作成して、UTF-16の速度を初めて調べた。 UTF-8の場合を1.0として、処理時間を比較すると、 UTF-8: 1.00 UTF16-BE: 1.81 UTF16-LE: 1.14となった。(バージョン: 5.5.1) UTF16-BEが特に遅い。この結果は、ある程度予想していた。 UTF…

5.0を出したのが10/19で二ヶ月以上経過したが、バグ報告が予想外に少ない。これを喜ぶべきか、あまり使われていないだけなのか？ Unicodeで使用されることが少ないということも考えられる。

バイト値表記ではなく、コードポイント表記を使用するほうが良い。 ex. /\x{00}/

5.5.1をリリース。文字のバイトサイズに合わないバイト値表記のチェックを追加。 ex. /\x00/ in UTF-16 ==> error

Kmさん。確認ありがとうございます。 デフォルトでは今までと同じで\nだけが改行です。改行を\r\nにする方法として、正規表現の作成時のオプションとして指定するか、今と同じでビルド時点で変更する方法か、についてはまだ決めていません。 今の非公式の扱…

Kmさん、コメントありがとうございます。必要性は了解しました。\r\nの公式サポートを検討してみます。いつ頃になるかはわかりませんが、来年の課題ということで。 テストプログラム以外で気になる点は、\r\nを使用しない場合の速度に影響がないかということ…

公式と非公式の違いというのは、言われるまできちんと考えていませんでした。今回の\r\nの問題で考えてみると、この機能を実装した直後に幾つかのパターンで動作チェックしただけで、きちんとしたテストプログラムを用意していないということがあります。従…

Kmさん、コメントありがとうございます。 Windowsでテキストファイルを読むときに、テキストモードとバイナリモードのどちらで読むことが多いですか？Windows上でプログラムをあまり書かないので、その辺の見当がつかないです。他に、改行コードが\r\nでなけ…

数日前にも、改行として\r\nに対応して欲しいというメールを受けた。公式にサポートはしていない方法を説明したのだが、何故公式にサポートしないのか質問されてしまった。 改行が\r\nで処理しなければならない場合というのは、どの程度あるのだろうか？それ…

ほかの事をしていたので何の進展もないのだが、本当に調べたいことはUTF-16エンコーディングでの速度。UTF-16での速度は、どのバージョンの段階でも一度も調べたことがない。

5.5.0と4.5.1の速度比較をしてみた。(文字コードはUTF-8) 5.5.0のほうがかなり遅くなるのではないかと心配していたが、結果は殆ど同じだった。5.xでは、Unicodeの全コードポイントでのcase foldをサポートするように変更したので、意外だった。尤も、自作の…

トルコ語とアゼルバイジャン語のcase foldを使用する場合には、ONIGENC_CASE_FOLD_TURKISH_AZERIをcase_fold_flagとして指定する。 以下のように変換される。 I ==> U+0131 U+0130 ==> iしかしこの機能はデフォルトの状態では無効にしている。regenc.hの中の…

5.5.0をリリース。 ONIGENC_CASE_FOLD_FULLを廃止 ONIGENC_CASE_FOLD_TURKISH_AZERIを追加 case foldのバグ修正

トルコ語のcase foldを実装している最中に、バグを見つけた。対象文字をcase foldした結果の文字に対してunfoldをして、元の文字と異なるものを全部列挙しておかなければいけないのだが、それを忘れていた。複数文字にfoldされる場合などは処理していたが、…

昨日の補足だが、正式にサポートしていないのは、\r\nのように複数文字で改行を表す場合である。単に改行文字を\n以外にするのであれば、それほど難しくない。使用する文字エンコーディングデータ(OnigEncodingType)の定義を少し変更して、新しい文字エンコ…

/\s+?$/の結果がおかしいというメールを一週間前に貰ったのだが、再現しなかった。関係ないかもしれないが、もしかすると、対象テキストの改行コードが\r\nの場合についてかもしれない。この場合には、\nの直前の\rもマッチすることになる。鬼車は公式には改…

次のリリースでは、 平仮名と片仮名の曖昧マッチ Unicodeで、トルコ語/アゼルバイジャン語のcase foldに対応 のどちらかをやろうと思っている。1は必要かどうかよくわからないので、見送ったほうが無難かもしれない。