[#38121] regex performace tuning and ABI compatibility — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
Yuguiです。
なかだです。
なかだです。
[#38131] Bug when daemonizing — rubikitch@...
るびきちです。
[#38145] MSの方との相談に先立って — masayoshi takahashi <maki@...>
高橋征義です。どこに投げるのがベストか判断つかなかったので、
[#38153] [feature:trunk] warning when Kernel#p is used — Yusuke ENDOH <mame@...>
遠藤です。
[#38191] big time — Tanaka Akira <akr@...>
思い立って、time_t を越える範囲を Time で扱うことに挑戦して
まつもと ゆきひろです
> 思い立って、time_t を越える範囲を Time で扱うことに挑戦して
In article <20090328.134401.209982445.tadf@dotrb.org>,
卜部です。
In article <49CF6641.7010204@ruby-lang.org>,
Tanaka Akira さんは書きました:
In article <49D07B1B.7000602@ruby-lang.org>,
卜部です。
In article <49D0E3D1.5020206@ruby-lang.org>,
Tanaka Akira さんは書きました:
In article <49D33295.3000600@ruby-lang.org>,
卜部です。
In article <49D39822.6070505@ruby-lang.org>,
[#38218] rinda/eval.rb — Masatoshi SEKI <m_seki@...>
咳といいます。
In article <F01982B3-FBB5-497F-BA36-38FA250E7D69@mva.biglobe.ne.jp>,
咳といいます。
こんにちは、なかむら(う)です。
In article <20090401095853.B00A.C613B076@garbagecollect.jp>,
まつもと ゆきひろです
こんにちは、なかむら(う)です。
[#38222] *BSD で fork できない理由 — "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>
きしもとです
At Tue, 31 Mar 2009 18:48:46 +0900,
卜部です。
In article <49D308AD.4040303@ruby-lang.org>,
Tanaka Akira さんは書きました:
きしもとです
[ruby-dev:38127] Re: ENCODING_FIXED と ENCODING_NONE の廃止
In article <49A98323.7060508@airemix.jp>,
"NARUSE, Yui" <naruse@airemix.jp> writes:
> 必要ならば定数を作った方がいいのでしょうね。
もう作ってしまいました。
> うーん、それってレイヤーが違うような気がします。
>
> 例えば、
> /ss/ui =~ "\u00df".encode("iso-8859-1")
> はマッチしてもいいと思いますが、
> # Unicode の U+0000 から U+00FF までは ISO-8859-1 と一致するはずだし
> ignorecase の挙動に関してはエンコーディングとは
> 別のレイヤーで処理するべきかと感じます。
> # やるかは別として、Regexp::IGNORECASE_COMBINE を作りつつ、
> # エンコーディングごとにデフォルトを変えるとか
レイヤが違うといわれても oniguruma はエンコーディングのとこ
ろでやってますし。
> ちょっとずれますが、
> /\s/ =~ "\u3000" #=> 0
> /\s/e =~ "\u3000".encode("euc-jp") #=> nil
> とか。
これもエンコーディングを気にしないといけない例ですね。
こういう例も含めて、正規表現の機能にはエンコーディングを気に
する必要があるものがあり、気にする正規表現を書いたときは書い
た時点で固定してしまうのが適切だと思っています。
気にしないときには //e じゃなくて // と書けばいいんじゃない
でしょうか。
> 例えば以下のようになるわけで、あまり強い意味を持たせるのはどうなんですかねぇ。
>
> % ruby_1_8 -Ku -e'p /a/s =~ "a\xE3\x81\x82"'
> 0
> % ruby_1_9_1 -Ku -e'p /a/s =~ "a\xE3\x81\x82"'
> -e:1:in `<main>': incompatible encoding regexp match (Windows-31J regexp with UTF-8 string) (Encoding::CompatibilityError)
/a/ ならいいかもしれませんが、/fi/i とか /ss/i は意図してい
ない動作になるかもしれないしなぁ。
> 「明確だった」使い方とは、例えば
私が感じているのは、//e は EUC-JP を想定していると理解して問
題なさそうだということです。
>> /\xB9\xA5/ =~ "\xA5\xB9\xA5\xC8"
> => 1
>> /#{"\xB9\xA5"}/e =~ "\xA5\xB9\xA5\xC8"
> => nil
> とか
>> /#{"\\\\"}/s =~ "\x95\x5C"
> => nil
>> /#{"\\\\"}/ =~ "\x95\x5C"
> => 1
> でしょうか。
> どちらもバイト構造に起因する誤マッチを防ぐためのものに見えます。
> この種のバイト構造に起因する誤マッチは、Ruby 1.9 ではわざわざ
> fixed_encoding を付けなくても回避できるので、これの防止では不要に思えます。
1.9 では文字列が文字境界を知っているというのはそうですね。
1.8 の /\xB9\xA5/e はどうなんですかねぇ。上の例では #{} で避
けてますが。1.9 でそうしろっていわれてもできませんけれど。
> 他に何かマッチ対象のエンコーディングを絞りたいような利用例ってありましたっけ。
oniguruma にはエンコーディングを気にする必要がある機能があり
ますから。
--
[田中 哲][たなか あきら][Tanaka Akira]