[#16708] includedir — nobu.nakada@...
なかだです。
[#16732] sharing sub-regexp — Tanaka Akira <akr@...17n.org>
Oniguruma についてひとつ要望があります。
Tanaka Akiraさんの<hvopu1hxfyd.fsf@coulee.a02.aist.go.jp>から
まつもと ゆきひろです
In article <1017890618.302241.17865.nullmailer@ev.netlab.jp>,
Tanaka Akiraさんの<hvo7knn93ug.fsf@coulee.a02.aist.go.jp>から
In article <20020405044506.D4784349@helium.ruby-lang.org>,
Tanaka Akiraさんの<hvopu1e4omy.fsf@coulee.a02.aist.go.jp>から
In article <20020410025054.C8DF0915@helium.ruby-lang.org>,
In article <hvor8lnchak.fsf@coulee.a02.aist.go.jp>,
前田です。
In article <87pu15z80q.wl@studly.priv.netlab.jp>,
前田です。
In article <87g01x1e6m.wl@studly.priv.netlab.jp>,
西山和広です。
In article <20020416180631.988E.ZN@mbf.nifty.com>,
前田です。
In article <87u1qaj0xe.wl@studly.priv.netlab.jp>,
前田です。
まつもと ゆきひろです
In article <1019116103.420173.12691.nullmailer@picachu.netlab.jp>,
前田です。
なかだです。
In article <200204181023.g3IANgM21124@sharui.nakada.kanuma.tochigi.jp>,
まつもと ゆきひろです
In article <1019140164.869863.14833.nullmailer@picachu.netlab.jp>,
[#16757] === — "Akinori MUSHA" <knu@...>
Array, Hash, Proc などで、 === が以下のように定義されていると
[#16761] StringIO — tadf@...
ふなばです。
なかだです。
ふなばです。
なかだです。
ふなばです。
青山です。
まつもと ゆきひろです
In article <1022740594.117106.6073.nullmailer@picachu.netlab.jp>,
前田です。
In article <874rgqdt3x.wl@studly.priv.netlab.jp>,
青山です。
まつもと ゆきひろです
青山です。
まつもと ゆきひろです
青山です。
まつもと ゆきひろです
青山です。
[#16776] Ruby 1.7.2 segfault — takuma ozawa <metal@...>
小澤といいます。
なかだです。
[#16790] Ruby Shim — "Akinori MUSHA" <knu@...>
1.7 early access kit という仮称で提案した構想ですが、先ほど
新井です。
At Tue, 9 Apr 2002 02:12:27 +0900,
なかだです。
[#16816] remove_const: cannot remove constant — Koji Arai <JCA02266@...>
新井です。
[#16833] math.c 1.10 — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
まつもと ゆきひろです
さくです。
なかだです。
まつもと ゆきひろです
[#16868] make error on debian potato — Wakou Aoyama <wakou@...>
青山です。
[#16869] Makefiles dependency — nobu.nakada@...
なかだです。
わたなべです。
なかだです。
わたなべです。
なかだです。
わたなべです。
なかだです。
[#16894] compile failure in process.c, setpgrp() & setpgid() — Ryo HAYASAKA <ryoh@...>
早坂@北陸先端です.
[#16923] Module::new with block is useful? — "Shin'ya Adzumi" <adzumi@...>
あづみです。
[#16978] Re: [rubyist:1343] Re: another sample for the Method — Koji Arai <JCA02266@...>
新井です。
[#16989] making Proc in C (Re: [rubyist:1356] Re: another sample for the Method) — nobu.nakada@...
なかだです。
[ruby-dev:16944] Re: Iconv
なかだです。
At Wed, 17 Apr 2002 19:25:18 +0900,
Tanaka Akira wrote:
> > Iconv.iconvで複数のStringを渡されたときに、エラーになったString
> > 以降がそのまま収められるようになってます。で、最初failedはやめ
> > ちゃおうかと思ったんですが…。
>
> 理解しました。「以降」というところがわかっていませんでした。ふむ。
>
> えぇと、理解した第一印象は必要以上に複雑なのではないかというものです。
> Iconv.iconv という一番複雑なところの都合で通常の用途が面倒になってしま
> うのは気に入りません。CGI#[] が Array を返すのに似た匂いがするといいま
> すか。そもそも Iconv.iconv はいちいちインスタンスを生成せずに済む簡易
> 的な使用法として位置付けられている(と思う)のに、それが面倒臭さの原因に
> なっているところが引っかかります。
なるほど。統一しようと思い立っても踏み切れない違和感はそのへん
かも知れません。
> しかも、(ちゃんとソースを読んでいるわけではないので推測になりますが)
> E2BIG な時には自動的に iconv(3) が繰り返し呼ぶことによって出力バッファ
> を抽象化していることを考えると、渡した文字列のそれぞれと iconv(3) の呼
> び出しが一対一で対応するわけでもなく、何が起きたのかを完全に把握できる
> わけでもなさそうです。まぁ、これは Iconv.iconv だけではなくて
> Iconv#iconv でもそうなのでしょうが。
たしかに完全にエラーリカバリしようというのは難しそうです。
> 思うに、むしろ Iconv.iconv を単純化するか、捨てるかした方がいいのでは
> ないかという気がします。たとえば、Iconv.iconv は廃止して、
(snip)
> どうせ、文字列ひとつをともかく難しいことは考えずに変換したいという場合
> が一番多いでしょうから、その文字列を単純に渡せば変換して terminate も
> してくれた文字列が返ってくる、というインターフェースのがお気軽でいいの
> ではないかと思います。
nkf互換のインターフェースは用意しようかと思ってたので、そのくら
いがちょうどいいのかも知れません。
> 複数の文字列に分けて呼び出したいっていうのはどんな場合がありますかね?
> 文字が別れていた時に Iconv::InvalidCharacter が発生して欲しい場合?
> 実行効率? 他にはなにがあるでしょう?
ないかも知れませんねぇ。いらないか。
> > でもiconv_tは複製されないから結局同じですよ。たぶん、どこかで
> > closed iconv (ArgumentError)といわれるのがオチじゃないかと。
>
> ちっ。
(^^;)
> > エラーのときにyieldするというのはどうかなとか、今ふと思ったんで
> > すが。
>
> 今回の私の用途でいえば、failed がブロックに渡されて、ブロックの返り値
> で処理が続行すると都合がいいですね。ただ、これで扱える話って一般的なの
> かなぁ。
successは要らないでしょうか。
--
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
中田 伸悦