[#12387] reducing logical operation — "Nobuyoshi.Nakada" <nobu.nakada@...>

なかだです。

17 messages 2001/03/07
[#12388] Re: reducing logical operation — EGUCHI Osamu <eguchi@...> 2001/03/07

えぐち@エスアンドイー です。

[#12389] Re: reducing logical operation — nobu.nakada@... 2001/03/07

なかだです。

[#12391] Re: reducing logical operation — EGUCHI Osamu <eguchi@...> 2001/03/07

えぐち@エスアンドイー です。

[#12404] fork in threads — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

14 messages 2001/03/09

[#12405] at_exit — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

15 messages 2001/03/09
[#12409] Re: at_exit — matz@... (Yukihiro Matsumoto) 2001/03/10

まつもと ゆきひろです

[#12411] Re: at_exit — keiju@... (石塚圭樹) 2001/03/10

けいじゅ@日本ラショナルソフトウェアです.

[#12425] bignum % の結果が負数になることがある — Hisayasu Nakao <h-nakao@...>

最近、ruby-1.6.2を使い出したばかりの中尾です。

39 messages 2001/03/12
[#12427] Re: bignum % の結果が負数になることがある — WATANABE Hirofumi <eban@...> 2001/03/12

わたなべです。

[#12463] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/13

In message <4518-Mon12Mar2001145434+0900-eban@os.rim.or.jp>

[#12464] Re: bignum % の結果が負数になることがある — matz@... (Yukihiro Matsumoto) 2001/03/13

まつもと ゆきひろです

[#12466] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/13

In message <984469222.234203.1007.nullmailer@ev.netlab.zetabits.com>

[#12475] Re: bignum % の結果が負数になることがある — matz@... (Yukihiro Matsumoto) 2001/03/14

まつもと ゆきひろです

[#12476] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/14

In message <984550885.417146.3670.nullmailer@ev.netlab.zetabits.com>

[#12480] Re: bignum % の結果が負数になることがある — matz@... (Yukihiro Matsumoto) 2001/03/14

まつもと ゆきひろです

[#12481] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/14

In message <984553493.009507.3747.nullmailer@ev.netlab.zetabits.com>

[#12488] Re: bignum % の結果が負数になることがある — matz@... (Yukihiro Matsumoto) 2001/03/14

まつもと ゆきひろです

[#12493] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/14

In message <984579430.080967.5569.nullmailer@ev.netlab.zetabits.com>

[#12578] require 'win32api' — Kazuhiro NISHIYAMA <zn@...>

require 'win32api'のエラーメッセージがわかりにくいと

21 messages 2001/03/20
[#12579] Re: require 'win32api' — nobu.nakada@... 2001/03/20

なかだです。

[#12598] Re: require 'win32api' — nobu.nakada@... 2001/03/21

なかだです。

[#12582] finalizer problem — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

20 messages 2001/03/20
[#12583] Re: finalizer problem — matz@... (Yukihiro Matsumoto) 2001/03/20

まつもと ゆきひろです

[#12585] Re: finalizer problem — keiju@... (石塚圭樹) 2001/03/20

けいじゅ@日本ラショナルソフトウェアです.

[#12591] Re: finalizer problem — matz@... (Yukihiro Matsumoto) 2001/03/20

まつもと ゆきひろです

[#12619] Re: finalizer problem — keiju@... (石塚圭樹) 2001/03/22

けいじゅ@日本ラショナルソフトウェアです.

[#12605] extern inline (ruby.h) ruby-1.6.3 — WATANABE Tetsuya <tetsu@...>

渡辺哲也です。

17 messages 2001/03/22
[#12606] Re: extern inline (ruby.h) ruby-1.6.3 — matz@... (Yukihiro Matsumoto) 2001/03/22

まつもと ゆきひろです

[#12607] Re: extern inline (ruby.h) ruby-1.6.3 — WATANABE Tetsuya <tetsu@...> 2001/03/22

渡辺哲也です。

[#12608] Re: extern inline (ruby.h) ruby-1.6.3 — matz@... (Yukihiro Matsumoto) 2001/03/22

まつもと ゆきひろです

[#12674] Was: [rubyist:0454] Re: to_str — Kenichi Komiya <kom@...1.accsnet.ne.jp>

21 messages 2001/03/25
[#12675] Re: Was: [rubyist:0454] Re: to_str — matz@... (Yukihiro Matsumoto) 2001/03/26

まつもと ゆきひろです

[#12678] Re: Was: [rubyist:0454] Re: to_str — Kenichi Komiya <kom@...1.accsnet.ne.jp> 2001/03/26

[#12681] Re: Was: [rubyist:0454] Re: to_str — matz@... (Yukihiro Matsumoto) 2001/03/26

まつもと ゆきひろです

[#12687] Re: Was: [rubyist:0454] Re: to_str — Kenichi Komiya <kom@...1.accsnet.ne.jp> 2001/03/27

[#12688] Re: Was: [rubyist:0454] Re: to_str — matz@... (Yukihiro Matsumoto) 2001/03/28

まつもと ゆきひろです

[#12710] Re: Was: [rubyist:0454] Re: to_str — Kenichi Komiya <kom@...1.accsnet.ne.jp> 2001/03/31

[ruby-dev:12377] Re: File::fnmatch? (was: Re: Dir::fnmatch?)

From: "Akinori MUSHA" <knu@...>
Date: 2001-03-06 10:53:48 UTC
List: ruby-dev #12377
At Tue, 6 Mar 2001 13:56:28 +0900,
matz wrote:
> まだ以下のことについて考えたいです。
> 
> メソッド名
> 
>         fnmatch, fnmatch?, namematch?, pathmatch?

 FNM_PATHNAME を付けない限り path 全体についてマッチするのでは
ないので、 dir とか path は付けない方がよいと思います。

 また ? を付けないと、(Regexp#match() からの類推で)マッチ結果を
返すような印象を与えるおそれがあるので、真偽値を返すことを明示
する意味で ? は付けた方がいいと思います。

 はじめの提案の際、 glob という語を入れてはどうかというご意見が
出ましたが、 glob という言葉はまとまりという意味ですから、個別に
マッチするかどうかテストするイメージには合致しないと思います。
ある条件のまとまりをパターンで指定する、というニュアンスで使う
のが一般的です。(glob(3), Dir::glob) まあ、 glob パターンという
言い回しも一般的になっていますけどね。

 さらに wildcard という語も出ましたが、 wildcard とは * や ? の
ことですから、これもやはり違うと思います。「マッチのパターンには
*, ? のようなワイルドカードや [...] によるキャラクタセットが使え
ます」というのが正しい用法だと思います。

 というわけで私には fnmatch? か namematch? が妥当だと思えるの
ですが、どちらも捨てがたいですねー。UNIX の fnmatch(3) が広く
知られている一方、 File クラスに入れるなら fn- などと妙な略し方を
しなくても、 namematch? と分かりやすくできるし。

 どちらか一つ、ということなら前者かなーと思いますが。

> マクロ名
> 
>         FNM_NOESCAPEなどをどうするか。intern.hに含めるのはま
>         ずい気がします(fnmatch.hと衝突するから)。

 確かにそうでした。

> 関数名
> 
>         rb_fnmatchにするの?
> 
> 個人的には今回のパッチでfile.cに加えられた変更はdir.cに追加
> でも良いかなって思ってます。そうすれば、externにする必要がな
> いので、衝突などの心配をしなくて済みますし。

 Static ではなくインターフェースを公開する場合は衝突を避ける
ために rb_ を付ける必要がありましたが、 dir.c に収めてよいのなら
問題ありませんね。

 ということで、パッチはまた単純になりました。どうでしょう?

> 欠点はFileの実装がio.c, file.c, dir.cに分散しちゃうことでしょ
> うね。ま、いいか。

 構造化プログラミング言語でオブジェクト指向言語を実装している
わけなので、そこは仕方のない妥協かも。 ;>

-- 
                     /
                    /__  __            Akinori.org / MUSHA.org
                   / )  )  ) )  /     FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ /  ( (__(  @ iDaemons.org / and.or.jp

"We're only at home when we're on the run, on the wing, on the fly"

Index: dir.c
===================================================================
RCS file: /mirror/ruby/src/ruby/dir.c,v
retrieving revision 1.33
diff -u -r1.33 dir.c
--- dir.c	2001/02/28 06:30:03	1.33
+++ dir.c	2001/03/06 08:34:43
@@ -872,6 +872,29 @@
     return rb_ensure(rb_Array, dir, dir_close, dir);
 }
 
+static VALUE
+file_s_fnmatch(argc, argv, obj)
+    int argc;
+    VALUE *argv;
+    VALUE obj;
+{
+    VALUE pattern, string;
+    VALUE flags;
+    int f;
+
+    if (rb_scan_args(argc, argv, "21", &pattern, &string, &flags) == 3) {
+	f = NUM2INT(flags);
+    }
+    else {
+	f = 0;
+    }
+
+    if (fnmatch(RSTRING(pattern)->ptr, RSTRING(string)->ptr, f) == 0)
+	return Qtrue;
+
+    return Qfalse;
+}
+
 void
 Init_Dir()
 {
@@ -905,4 +928,12 @@
 
     rb_define_singleton_method(rb_cDir,"glob", dir_s_glob, 1);
     rb_define_singleton_method(rb_cDir,"[]", dir_s_glob, 1);
+
+    rb_define_singleton_method(rb_cFile,"fnmatch?", file_s_fnmatch, -1);
+    rb_define_singleton_method(rb_cFile,"namematch?", file_s_fnmatch, -1);
+
+    rb_define_const(rb_cFile, "FNM_NOESCAPE", INT2FIX(FNM_NOESCAPE));
+    rb_define_const(rb_cFile, "FNM_PATHNAME", INT2FIX(FNM_PATHNAME));
+    rb_define_const(rb_cFile, "FNM_PERIOD", INT2FIX(FNM_PERIOD));
+    rb_define_const(rb_cFile, "FNM_NOCASE", INT2FIX(FNM_NOCASE));
 }

In This Thread