[#22195] IO::for_io and TCPServer#bind — GOTOU Yuuzou <gotoyuzo@...>

test_drb が IPv4 射影アドレスが有効な環境でないと動かないこ

16 messages 2003/12/09
[#22198] Re: IO::for_io and TCPServer#bind — matz@... (Yukihiro Matsumoto) 2003/12/09

まつもと ゆきひろです

[#22205] yet another inconsistency about EOF between StringIO and IO — Tanaka Akira <akr@...17n.org>

StringIO の

24 messages 2003/12/10
[#22206] Re: yet another inconsistency about EOF between StringIO and IO — nobu.nakada@... 2003/12/10

なかだです。

[#22214] Re: yet another inconsistency about EOF between StringIO and IO — Tanaka Akira <akr@...17n.org> 2003/12/10

In article <200312100725.hBA7P8Ac011112@sharui.nakada.kanuma.tochigi.jp>,

[#22222] Re: yet another inconsistency about EOF between StringIO and IO — nobu.nakada@... 2003/12/10

なかだです。

[#22234] Re: yet another inconsistency about EOF between StringIO and IO — Masahiro Sakai (酒井政裕) <sakai@...> 2003/12/11

さかいといいます。

[#22262] Re: yet another inconsistency about EOF between StringIO and IO — Tanaka Akira <akr@...17n.org> 2003/12/13

In article <20031211.214041.71090239.sakai@tom.sfc.keio.ac.jp>,

[#22328] Re: yet another inconsistency about EOF between StringIO and IO — Tanaka Akira <akr@...17n.org> 2003/12/23

In article <87k751dzyf.fsf@serein.a02.aist.go.jp>,

[#22331] Re: yet another inconsistency about EOF between StringIO and IO — matz@... (Yukihiro Matsumoto) 2003/12/23

まつもと ゆきひろです

[#22334] Re: yet another inconsistency about EOF between StringIO and IO — Tanaka Akira <akr@...17n.org> 2003/12/23

In article <1072167374.096702.13473.nullmailer@picachu.netlab.jp>,

[#22343] Re: yet another inconsistency about EOF between StringIO and IO — matz@... (Yukihiro Matsumoto) 2003/12/23

まつもと ゆきひろです

[#22330] core dump with ungetc — Tanaka Akira <akr@...17n.org>

次のように ungetc を使うと core を吐く場合があります。

14 messages 2003/12/23
[#22332] Re: core dump with ungetc — nobu.nakada@... 2003/12/23

なかだです。

[#22366] `to_s': method `to_s' overridden (TypeError) — Tanaka Akira <akr@...17n.org>

そういえば、次の `to_s': method `to_s' overridden (TypeError) というの

12 messages 2003/12/24

[#22385] Tk.callback_break causes seg-fault or hang-up — Hidetoshi NAGAI <nagai@...>

永井@知能.九工大です.

19 messages 2003/12/24
[#22387] Re: Tk.callback_break causes seg-fault or hang-up — matz@... (Yukihiro Matsumoto) 2003/12/24

まつもと ゆきひろです

[#22393] Re: Tk.callback_break causes seg-fault or hang-up — Hidetoshi NAGAI <nagai@...> 2003/12/24

永井@知能.九工大です.

[#22395] Re: Tk.callback_break causes seg-fault or hang-up — matz@... (Yukihiro Matsumoto) 2003/12/24

まつもと ゆきひろです

[#22396] Re: Tk.callback_break causes seg-fault or hang-up — matz@... (Yukihiro Matsumoto) 2003/12/24

まつもと ゆきひろです

[#22397] Re: Tk.callback_break causes seg-fault or hang-up — Hidetoshi NAGAI <nagai@...> 2003/12/24

永井@知能.九工大です.

[#22418] ruby-1.8.1 build failed on HP-UX 11.11 — MIYAMUKO Katsuyuki <k-miyamuko@...>

みやむこです。

29 messages 2003/12/25
[#22419] Re: ruby-1.8.1 build failed on HP-UX 11.11 — matz@... (Yukihiro Matsumoto) 2003/12/25

まつもと ゆきひろです

[#22420] Re: ruby-1.8.1 build failed on HP-UX 11.11 — matz@... (Yukihiro Matsumoto) 2003/12/25

まつもと ゆきひろです

[#22424] Re: ruby-1.8.1 build failed on HP-UX 11.11 — MIYAMUKO Katsuyuki <k-miyamuko@...> 2003/12/25

みやむこです。

[#22491] Re: ruby-1.8.1 build failed on HP-UX 11.11 — MIYAMUKO Katsuyuki <k-miyamuko@...> 2004/01/05

みやむこです。

[ruby-dev:22160] Re: Dir.glob と Shjift_JIS について

From: nobu.nakada@...
Date: 2003-12-05 11:46:37 UTC
List: ruby-dev #22160
なかだです。

At Fri, 5 Dec 2003 20:21:38 +0900,
H.Yamamoto wrote:
> >見直してもいいんじゃないかと思いますが、具体的にはどういう構造
> >を考えてますか?
> 
> 今頭にあるのは、fnmatch を glob に合わせて、
> 
> * ? [ ] { } **/ '\0'区切り
> 
> を使えるようにして、パス区切りは / に統一して、\ はエスケープ専用にする。
> ('\?' は '?' にマッチ:? は任意の1文字)
> FNM_CASEFOLD は そのまま
> FNM_PATHNAME は **/ があるので廃止
> FNM_NOESCAPE は '\' がほしいときは '\\' とすることにして廃止
> FNM_DOTMATCH は よくわかりません。

fnmatchでも**を扱えるようにするというのはいいかもしれませんが、
FNM_PATHNAMEって意味は逆じゃありませんでしたっけ。

> FNM_CASEFOLD は、環境によってデフォルトを変えてもいいかもしれません。
> Win32ではON、UNIXではOFFという具合に。

Win32というよりはDOSISHでしょうね。

> >> これから最適化に入ります。nobuさんに指摘された、*p == '\0'の場合
> >> 単に ++p でいいんじゃないかというのは、最適化の最終でやるつもりです。
> >
> >これは最適化というよりも、むしろ無用にNext()が複雑化しているの
> >が、使ってはいけないところにまで使おうとしているせいなんじゃな
> >いかと思うのですが。
> 
> 無用にというのは、greater((p) + 1, (p) + mblen(p, INT_MAX)) の部分でしょうか?
> mblenはエラーのとき(マルチバイト文字が不完全だったとき?)-1 を返すそうなのですが、
> それは起こらないとしていい?

あー、それはどうすべきでしょうねぇ。基本的にutil.cのmblen()しか
想定してないはずなので。例外にするべきか、単独バイトとして扱う
ほうがいいのか。

> 個人的には、シングルバイト文字に Next() を呼ぶオーバーヘッドよりも、

全然オーバーヘッドを気にしているわけではなくて、ターミネータを
越えてアクセスしようとするところが、バッファオーバーランを誘発
しそうでなんとなく気になってます。

> aa/aa/aa/aa/* みたいに、最後が magic なパターンで glob_helper を呼んだ場合に、 / の度に
> 
>     p = sub ? sub : path;
>     if (!has_magic(p, 0, flags)) {
> #if defined DOSISH
> 	remove_backslashes(path);
> #else
> 	if (!(flags & FNM_NOESCAPE)) remove_backslashes(p);
> #endif
> 
> が呼ばれる部分の方がマルチバイト環境では気になります。

これはまぁ、以前から若干思わないでもなかったのですが、トータル
としてはそう大きくはならないだろうと思ってます。

> 特に、extract_path をマルチバイト対応にするときかなり遅い実装にしてしまったので、
> これをなんとかしたいです。

それは個別に改善を図るということで。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

In This Thread