Feature #5820
closedMerge Onigmo to Ruby 2.0
Description
Ruby 1.9 では正規表現エンジンや M17N の基盤として Oniguruma を用いています。
これを 2.0 では Oniguruma の改造版である、k-takata さんの Onigmo に置き換えようという話です。
https://github.com/k-takata/Onigmo/tree/tmp/ruby-2.0.x
この取り込みによる影響は以下の通りです。
- 100%互換 (既存のテストが全て無修正で通る)
- いくつかの新機能 [ruby-dev:44410]
- 正規表現
* \K, \R, \X, (?(cond)yes|no), \g<0>, \g<+n>, (?au)
* Perl 5.10互換の名前参照(←Rubyには不要でしょう。)- Shift_JIS, EUC-JPで、全角アルファベットなどの大文字小文字同一視検索に対応。
- Shift_JIS, EUC-JPで、\p{Han}, \p{Latin}, \p{Greek}, \p{Cyrillic} に対応。
- 最適化
- 暗黙のアンカーによる最適化を実装。
- http://redmine.ruby-lang.org/issues/3568 で無効化された最適化を再度有効化。
- 正規表現
現状は POSIX 文字クラスに非互換があり、それが解決されればマージ可能と認識しています。
Files
Updated by naruse (Yui NARUSE) almost 13 years ago
= 現状の非互換について
Rubyへの取り込み方:
cd Onigmo
cp reg{comp,enc,error,exec,parse,syntax}.c reg{enc,int,parse}.h ~/ruby
cp oniguruma.h ~/ruby/include/ruby/
Onigmo: edf9df1cefc28472085a857116153529253ffab5 (tmp/ruby-2.0.x)
Ruby: r34150
- Failure:
test_parse_utf8(TestDateParse)
[/home/naruse/ruby/test/date/test_date_parse.rb:651]:
<"日本"> expected but was
.
原因: 解析に正規表現を用いており、
[:alpha:] が ASCII にしかマッチしない問題を踏んでいる。
- Failure:
test_iso_8859_1(TestISO8859) [(eval):7]:
Expected /^SS$/i to match "\xDF".
- Failure:
test_iso_8859_10(TestISO8859) [(eval):7]:
Expected /^SS$/i to match "\xDF".
Failure:
test_iso_8859_13(TestISO8859) [(eval):7]:
Expected /^SS$/i to match "\xDF".Failure:
test_iso_8859_14(TestISO8859) [(eval):7]:
Expected /^SS$/i to match "\xDF".Failure:
test_iso_8859_15(TestISO8859) [(eval):7]:
Expected /^SS$/i to match "\xDF".Failure:
test_iso_8859_16(TestISO8859) [(eval):7]:
Expected /^SS$/i to match "\xDF".Failure:
test_iso_8859_2(TestISO8859) [(eval):7]:
Expected /^SS$/i to match "\xDF".Failure:
test_iso_8859_3(TestISO8859) [(eval):5]:
Expected /^SS$/i to match "\xDF".Failure:
test_iso_8859_4(TestISO8859) [(eval):7]:
Expected /^SS$/i to match "\xDF".Failure:
test_iso_8859_9(TestISO8859) [(eval):5]:
Expected /^SS$/i to match "\xDF".
未調査
大文字小文字テーブル対応が壊れた?
Failure:
test_regexp_named_class(TestM17N) [/home/naruse/ruby/test/ruby/test_m17n.rb:543]:
Expected /[[:space:]]/ to match " ".Failure:
test_posix_bracket(TestRegexp) [/home/naruse/ruby/test/ruby/test_regexp.rb:716]:
Expected /\A[[:digit:]]+\z/ to match "0123456789".
POSIX 文字クラスが ASCII の範囲なため。
- Failure:
test_unicode(TestRegexp) [/home/naruse/ruby/test/ruby/test_regexp.rb:792]:
Expected /^\u0149$/i to match "ʼn".
2)-11) と同じ問題?
Updated by kosaki (Motohiro KOSAKI) almost 13 years ago
Ruby 1.9 では正規表現エンジンや M17N の基盤として Oniguruma を用いています。
これを 2.0 では Oniguruma の改造版である、k-takata さんの Onigmo に置き換えようという話です。
https://github.com/k-takata/Onigmo/tree/tmp/ruby-2.0.x
現状 onigurumaのupstreamは活動が止まっているという認識なので乗り換え自体は賛成です。
ただ将来的には libonigmo.so を動的にリンクするだけで済むような形態に移行できたらなあと
思っており(実際にディストリからそういう要望をつい最近受けたばかりであるし)、k-takataさんと
今後どのような形態で協力していくのか一回お話ししにいった方がいいんじゃないかと思ったり思わなかったり。k-tanakaさんにRubyのコミッタになって貰うか、なるせさんがonigumoのコミッタになるとかがベストだと思いますが、そういう敷居をあげる話をうっちゃっておくとしても、なんらかのコミュニケーションパスが確立されていて欲しいなあ。とかとか
非互換変更は Ruby 3.0まで入れられないから気にしてもしょうが無いかなあ・・・¶
Updated by k_takata (Ken Takata) almost 13 years ago
POSIXブラケットは、Perlでは/a指定時にはASCII範囲に限定されるので、Onigmoではそれに合わせてあります。
個人的にはあまり変更したくないのですが、変更すべきでしょうか。
変更するとしたら、挙動オプションを1つ追加して、Ruby文法の場合はそれを有効にすることになると思いますが。
残りの問題は未調査です。
Updated by naruse (Yui NARUSE) almost 13 years ago
Motohiro KOSAKI wrote:
ただ将来的には libonigmo.so を動的にリンクするだけで済むような形態に移行できたらなあと
思っており(実際にディストリからそういう要望をつい最近受けたばかりであるし)、
Ruby は Ruby 文法挙動オプション(コンパイルオプション)を指定した鬼車を用いているので、
普通のバイナリではたとえソースが一致していてもダメです。
この状況は鬼雲でも変わりませんから、そのような形態に移行するのは不可能なんじゃないかと思います。
k-takataさんと
今後どのような形態で協力していくのか一回お話ししにいった方がいいんじゃないかと思ったり思わなかったり。
そうですねぇ、現時点で鬼雲で追加された機能を Ruby 側でどうするかはちょっと悩んでいるところではあります。
k-tanakaさんにRubyのコミッタになって貰うか、なるせさんがonigumoのコミッタになるとかがベストだと思いますが、
そういう敷居をあげる話をうっちゃっておくとしても、なんらかのコミュニケーションパスが確立されていて欲しいなあ。
とかとか
k-tanaka さんがコミッタになって頂けるとわたしが楽ですね。
Ken Takata wrote:
POSIXブラケットは、Perlでは/a指定時にはASCII範囲に限定されるので、Onigmoではそれに合わせてあります。
個人的にはあまり変更したくないのですが、変更すべきでしょうか。
変更するとしたら、挙動オプションを1つ追加して、Ruby文法の場合はそれを有効にすることになると思いますが。
既定路線では 2.0 では非互換を導入しないという予定ですので、変更されない場合は 2.0 ではマージできない、
と言うことになると思います。
とはいえ、この辺はまつもとさんのさじ加減一つですが。
ところで、Ruby って /a のカスタマイズではなく、/u のカスタマイズではないでしょうか。
残りの大文字小文字の問題はこれが起因なんじゃないかと思います。
ので、仮に変更するとしたら、POSIXブラケットの変更ではなく、\d\w\sの変更でしょう。
Updated by k_takata (Ken Takata) almost 13 years ago
Yui NARUSE wrote:
この状況は鬼雲でも変わりませんから、そのような形態に移行するのは不可能なんじゃないかと思います。
同意見です。エンコーディング周りの変更もそう簡単にはマージできそうにないですし。
k-tanaka さんがコミッタになって頂けるとわたしが楽ですね。
Rubyのビルドすらしたことのない人がコミッタになるのは互いの不幸の元ではないかと。
既定路線では 2.0 では非互換を導入しないという予定ですので、変更されない場合は 2.0 ではマージできない、
と言うことになると思います。
なるほど、そうなってしまいますか。
ところで、Ruby って /a のカスタマイズではなく、/u のカスタマイズではないでしょうか。
残りの大文字小文字の問題はこれが起因なんじゃないかと思います。
ので、仮に変更するとしたら、POSIXブラケットの変更ではなく、\d\w\sの変更でしょう。
すみません。よく状況が把握できていません。
そうだとすると、regparse.c の OnigSyntaxRuby 構造体の中の ONIG_OPTION_ASCII_RANGE を
0 に書き換えると、大文字小文字の部分はパスしますか?
もし /u のカスタマイズだと、\d\w\sが常にASCIIの範囲内になってしまって、
/u/a の有用性がずいぶん落ちてしまいますね。(非互換を導入しないならそれも致し方なしですか。)
Updated by k_takata (Ken Takata) almost 13 years ago
すみません。大文字小文字の問題は、Onigmo 5.11.4でcase-insensitiveなBM法を
導入したときに混入したバグと判明しました。(どう修正すべきかまだ分かっていませんが。)
これが修正できれば、/a で POSIX 文字クラスを ASCII に限定しないオプションと合わせることで、
非互換点は解決できそうです。
Updated by k_takata (Ken Takata) almost 13 years ago
- File 0001-add-ONIG_SYN_POSIX_BRACKET_ALWAYS_ALL_RANGE-option.patch 0001-add-ONIG_SYN_POSIX_BRACKET_ALWAYS_ALL_RANGE-option.patch added
- File 0002-bug-ss-i-doesn-t-match-x-DF.patch 0002-bug-ss-i-doesn-t-match-x-DF.patch added
POSIX 文字クラスを ASCII に限定しないオプションの追加と、大文字小文字問題の修正パッチを作成しました。
特に問題なければ、Onigmo本体に反映したいと思います。
Updated by k_takata (Ken Takata) almost 13 years ago
- File 0001-add-ONIG_SYN_POSIX_BRACKET_ALWAYS_ALL_RANGE-option.patch 0001-add-ONIG_SYN_POSIX_BRACKET_ALWAYS_ALL_RANGE-option.patch added
- File 0002-bug-ss-i-doesn-t-match-x-DF.patch 0002-bug-ss-i-doesn-t-match-x-DF.patch added
前回のパッチはOnigmoのmasterブランチで作成したものでしたが、
tmp/ruby-2.0.xブランチにはそのまま適用できませんでした。
tmp/ruby-2.0.xブランチに適用できるようにパッチを作成し直しました。
Updated by naruse (Yui NARUSE) almost 13 years ago
ありがとうございます、大文字小文字問題は確かに直りました。
残っているのが一点、以下がマッチしなくなっています。
Bug #5208 と関連しているような気もしますが。
/\u3042\b[ a]/=~"\u3042a" #=> nil
Updated by k_takata (Ken Takata) almost 13 years ago
おや、おかしいですね。
手元では、/(?a)あ\b[ a]/ は "あa" にマッチしています。nilを返すべきところを返さなくなったということでしょうか。
(Ruby 1.9.3では、nilを返すようですが。)
私としては、Bug #5208にも書いたように\b,\Bは\w,\Wと連動しているべきだと考えていますので、マッチしていないとすれば想定外ですので、もう少し詳しく教えていただけますでしょうか。
#5208 note-3より
考えたんですが 1.9 では現状のままとします。
/u /a が将来取り込まれたらその時に改めて考えましょう。
ちょうど今がそのときでしょうか。
Updated by naruse (Yui NARUSE) almost 13 years ago
Ken Takata wrote:
おや、おかしいですね。
手元では、/(?a)あ\b[ a]/ は "あa" にマッチしています。nilを返すべきところを返さなくなったということでしょうか。
(Ruby 1.9.3では、nilを返すようですが。)
あああ、その通りです。書いててごっちゃになってました。
私としては、Bug #5208にも書いたように\b,\Bは\w,\Wと連動しているべきだと考えていますので、マッチしていないとすれば想定外ですので、もう少し詳しく教えていただけますでしょうか。
#5208 note-3より
考えたんですが 1.9 では現状のままとします。
/u /a が将来取り込まれたらその時に改めて考えましょう。ちょうど今がそのときでしょうか。
/u /a は Perl の挙動にあってる方がいいと思うんですが、無指定だとなぁ、うーん。
Updated by k_takata (Ken Takata) almost 13 years ago
- File 0003-support-for-Ruby-1.9.3-compatible-b-B-and-POSIX-brac.patch 0003-support-for-Ruby-1.9.3-compatible-b-B-and-POSIX-brac.patch added
/a /u はPerlに合わせて、無指定あるいは /d だとRuby 1.9.3と同じ仕様とすると添付のパッチのような感じでしょうか。
この仕様がよいのか正直決めかねているところですが。
Updated by naruse (Yui NARUSE) almost 13 years ago
0003-support-for-Ruby-1.9.3-compatible-b-B-and-POSIX-brac.patch で既存のテストが全て通ることを確認しました。
しかし、確かに perlre を見直すと、/d で 1.9 仕様というのもちょっと引っかかりますねぇ、うーん。
Updated by naruse (Yui NARUSE) almost 13 years ago
そういえば、/u って Ruby だと UTF-8 文字コード指定で既に存在するんですよね。
これもどうするか考えなければというか、いっそ /a /u 入れないのがいいんだろうか…。
Updated by k_takata (Ken Takata) almost 13 years ago
私としては、せっかく (?au) を入れたので使えないのはもったいないなと思います。Perlの他にはPythonでも /u 相当が使えることですし需要はあるでしょう。
/u がぶつかる問題は、大文字で /A/U にするとか?
/d は確かに悩ましいですが、/d で 1.9 仕様とするか、1.9 仕様は破棄して /a をデフォルトにする(/d は無し)か、どちらかしかないのではないかと思っています。(/a で 1.9 仕様とするのは \b の挙動を考えると選択肢からは除外したい。)
なお、#note-1 のマージ方法だと、enc ディレクトリ以下をコピーしていないため以下の制限があります。
- Unicode系エンコーディングで、\X, \R が仕様通りに動作しない。(OnigEncodingType にflagsメンバを追加して、それを参照しているため。)(鬼雲新機能)
- Unicode系エンコーディングで、\p{In_XXX} によるUnicodeブロック名が使えない。(鬼雲新機能)
- Unicode系エンコーディングで、大文字小文字変換テーブルがUnicode 6.0に対応していない。(鬼雲新機能)
- Unicode系エンコーディングで、\p{C} が正しくない。(\p{Cn} の範囲が含まれていない。)(Ruby 1.9のバグ)
- Unicode系エンコーディングで、\p{LC} (\p{Cased_Letter}) が使えない。(鬼雲新機能)
- Unicode系エンコーディングで、本来は内部実装用の \p{NEWLINE} が使えるようになってしまっている。(鬼車5.9.2のバグ(?))
- Unicode系エンコーディングで、なぜか 0x09~0x0d が \p{Print} に含まれている。(鬼車5.9.2のバグ(?))
- sjis/euc_jpで、全角アルファベット、キリル文字、ギリシャ文字の大文字小文字同一視検索ができない。(鬼雲新機能)
- sjis/euc_jpで、\p{Han}, \p{Latin}, \p{Greek}, \p{Cyrillic} が使えない。(鬼雲新機能)
8,9についてはJIS X 0208を基準にしているので、JIS X 0212や0213はどうするのかという課題があります。
tool/enc-unicode.rb (と tool/CaseFolding.py) もマージが必要です。
Updated by naruse (Yui NARUSE) almost 13 years ago
Ken Takata wrote:
私としては、せっかく (?au) を入れたので使えないのはもったいないなと思います。Perlの他にはPythonでも /u 相当が使えることですし需要はあるでしょう。
/u がぶつかる問題は、大文字で /A/U にするとか?
/A /U は今度は Perl が /A /U を導入した時に困るので、2.0 で /u を deprecated にして、どこかで変更ですかねぇ。
/d は確かに悩ましいですが、/d で 1.9 仕様とするか、1.9 仕様は破棄して /a をデフォルトにする(/d は無し)か、どちらかしかないのではないかと思っています。(/a で 1.9 仕様とするのは \b の挙動を考えると選択肢からは除外したい。)
そうですね、/d で 1.9 ですかね。
なお、#note-1 のマージ方法だと、enc ディレクトリ以下をコピーしていないため以下の制限があります。
tool/enc-unicode.rb (と tool/CaseFolding.py) もマージが必要です。
https://github.com/nurse/ruby/tree/onigmo マージしました。
以下のような変更をしています。r34236 は未マージです。
- enc/cp932.c 内の sjis.c への参照を shift_jis.c へと変更
- enc/cp932.c から enc/windows_31j.c に rename
- Windows-31J のエンコーディング定義を enc/shift_jis.c から enc/windows_31j.c に移動
- enc/koi8.c を削除 (KOI8ってエンコーディングは存在しないはず。これが何者なのかわからない)
- enc/cp1251.c を削除 (Ruby では enc/windows_1251.c)
8,9についてはJIS X 0208を基準にしているので、JIS X 0212や0213はどうするのかという課題があります。
まず、JIS X 0213 については、現在の Ruby は黙殺しています。
仮にサポートするとしても、Shift_JISX0213/EUC-JISX0213 などの 0213 系エンコーディングでの話でしょう。
また、SJIS 系エンコーディングでは JIS X 0212 を含むエンコーディングが存在しないのでこれも関係しません。
EUC-JP と eucJP-ms は JIS X 0212 を含むので、対応するのはありかもしれません。
Updated by k_takata (Ken Takata) almost 13 years ago
Onigmo 5.13.0を公開しました。ONIG_SYNTAX_RUBYにて、/d で1.9仕様としています。
tmp/ruby-2.0.xブランチも更新し、r34236もマージしています。(masterブランチにはr34236をマージすべきか判断が付かなかったので保留しています。)
enc/shift_jis.cは少し手を入れています。enc/windows_31j.cを使っても、\p{Han} の範囲が変更されていなかったようですので。
まず、JIS X 0213 については、現在の Ruby は黙殺しています。
そうであれば、Onigmoも当分そのままにしておこうと思います。
EUC-JP と eucJP-ms は JIS X 0212 を含むので、対応するのはありかもしれません。
こちらは頭の片隅にでも留めておきます。
Updated by naruse (Yui NARUSE) almost 13 years ago
Ken Takata wrote:
Onigmo 5.13.0を公開しました。ONIG_SYNTAX_RUBYにて、/d で1.9仕様としています。
tmp/ruby-2.0.xブランチも更新し、r34236もマージしています。(masterブランチにはr34236をマージすべきか判断が付かなかったので保留しています。)
r34236 をそのまま取り込むべきかは迷う所ですが、不正な文字の場合の戻り値が不統一という
視点自体は妥当なものなんじゃないかと思っています。
というわけで、テストの失敗もでなくなったので、特に異論が無ければ2月にはマージしますかね。
Updated by mame (Yusuke Endoh) almost 13 years ago
ほとんどの議論は横道 or 枝葉末節っぽい感じがしたので読んでないのですが、
結論としては onigmo を取り込む方向なんでしょうか。
あと、k-takata さんにはコミッタになって頂ける予定でしょうか。
もしそうだったら、早速ですが #1200 、#1201 あたりをご検討願いたいと¶
考えております。¶
--
Yusuke Endoh mame@tsg.ne.jp
Updated by naruse (Yui NARUSE) almost 13 years ago
Yusuke Endoh wrote:
ほとんどの議論は横道 or 枝葉末節っぽい感じがしたので読んでないのですが、
結論としては onigmo を取り込む方向なんでしょうか。
わたしが 1.9.3 やってて遅れているだけですね。
終わったら取り込みます。
あと、k-takata さんにはコミッタになって頂ける予定でしょうか。
なって頂けない感じなので当面はわたしがマージしようかと思っています。
もしそうだったら、早速ですが #1200 、#1201 あたりをご検討願いたいと¶
考えております。¶
なって頂けなくてもこの辺りは見て頂いているようなので検討していただけることを期待していますが、
#1200 は本家でなく Ruby 側のデザインで許可していない部分なので却下ですね、しました。
#1201 も named capture 使えよって感がありますがどうかな。
Updated by naruse (Yui NARUSE) almost 13 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
This issue was solved with changeset r34663.
Yui, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
- Merge Onigmo-5.13.1. [ruby-dev:45057] [Feature #5820]
https://github.com/k-takata/Onigmo
cp reg{comp,enc,error,exec,parse,syntax}.c reg{enc,int,parse}.h
cp oniguruma.h
cp tool/enc-unicode.rb
cp -r enc/