[#40528] [Feature #2833] 絵文字エンコーディングの提案 — Kenta Murata <redmine@...>
Feature #2833: 絵文字エンコーディングの提案
まつもと ゆきひろです
むらたです。
> Feature #2833: 絵文字エンコーディングの提案
チケット #2833 が更新されました。 (by Yui NARUSE)
むらたです。
[#40573] [bug:1.8] ossl_ssl_session.c:110: warning: implicit declaration of function 'TIMET2NUM' — Tanaka Akira <akr@...>
Ruby 1.8 で、以下の警告が増えています。
2010/3/7 Tanaka Akira <[email protected]>:
[#40597] Re: [ruby-list:46898] 重複組合せは組込みにならないのでしょうか? — "KISHIMOTO, Makoto" <[email protected]>
きしもとです
まつもと ゆきひろです
遠藤です。
> 同様に、repeated_permutation/combination のデフォルト引数にも反対
まつもと ゆきひろです
[#40614] [Bug #2956] segfault — Tomoki MAEDA <redmine@...>
Bug #2956: segfault
[#40623] Enumerable#interleave — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
2010年3月13日22:44 Yukihiro Matsumoto <[email protected]>:
まつもと ゆきひろです
2010年3月14日0:04 Yukihiro Matsumoto <[email protected]>:
まつもと ゆきひろです
[#40641] [Bug #2965] method `===' called on hidden T_STRING object (NotImplementedError) — Kenta Murata <redmine@...>
Bug #2965: method `===' called on hidden T_STRING object (NotImplementedError)
チケット #2965 が更新されました。 (by Shyouhei Urabe)
[#40649] [Feature #2968] 数値の正負を返すメソッド — Yui NARUSE <redmine@...>
Feature #2968: 数値の正負を返すメソッド
チケット #2968 が更新されました。 (by Yui NARUSE)
> チケット #2968 が更新されました。 (by Yui NARUSE)
成瀬です。
> 成瀬です。
[#40650] [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Yui NARUSE <redmine@...>
Feature #2969: String#to_f が -h.hhh±pd を解釈できるように
質問ですが、この形式は入力だけでなく、なんらかの方法で出力でも利用でき
成瀬です。
> String#to_f は従来から指数表記を許していたので、
成瀬です。
> to_i がデフォルトで prefix を見ないのは、0377 のような、
成瀬です。
> 先のパッチの対象関数が ruby_strtod である通り、
成瀬です。
> strtod(3) の解釈対象に含まれていない 2 進や 8 進を否定することが、
(2010/03/26 3:05), Tadayoshi Funaba wrote:
> なぜ同じなのでしょう。
(2010/03/26 4:02), Tadayoshi Funaba wrote:
>> strtod(3) を参考にしたり、影響されたりすることは普通にあるとは思います
(2010/03/27 18:19), KOSAKI Motohiro wrote:
えぐち@エスアンドイーです
(2010/03/27 20:26), EGUCHI Osamu wrote:
> つまり、ふなばさんは 16 進よりも 2 進や 8 進形式が好みであるところ、
まつもと ゆきひろです
[#40672] URI methods for application/x-www-form-urlencoded — Tanaka Akira <akr@...>
最近、成瀬さんが追加した URI.encode_www_form など、
[#40695] keiju, please check tickets assigned to you — Yusuke ENDOH <mame@...>
いしつかさん
けいじゅ@いしつかです.
いしつかさん
けいじゅ@いしつかです.
遠藤です。
[#40735] [Bug #2995] TestHash#test_recursive_check fails — Shugo Maeda <redmine@...>
Bug #2995: TestHash#test_recursive_check fails
[#40746] [Bug #1031] -U オプションの説明が --help にない — Yusuke Endoh <redmine@...>
チケット #1031 が更新されました。 (by Yusuke Endoh)
[#40779] [Feature #3018] UNINITIALIZED_VAR() マクロの導入 — Motohiro KOSAKI <redmine@...>
Feature #3018: UNINITIALIZED_VAR() マクロの導入
まつもと ゆきひろです
> |Linuxではこの問題にたいして以下のようなマクロで解決しており、同様の手法を導入したいと
まつもと ゆきひろです
本題じゃないですが、
[#40805] Improvement of Fiber switching cost with system dependent way — SASADA Koichi <ko1@...>
ささだです.
こんにちは、なかむら(う)です。
[#40832] Process.daemon() returns -1 on failure ifndef HAVE_DAEMON — "Akinori MUSHA" <knu@...>
Process.daemon() 失敗時の挙動が、 HAVE_DAEMON 定義時と非定義時
2010年3月29日19:52 Akinori MUSHA <[email protected]>:
> 2010年3月29日19:52 Akinori MUSHA <[email protected]>:
[#40833] [Bug: trunk] Fiber transfer limitation — SASADA Koichi <ko1@...>
ささだです.
[#40855] revert 1.9 \w limitation to ASCII — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#40884] [Feature #3065] [TypedData] という名前について — Tadashi Saito <redmine@...>
Feature #3065: [TypedData] という名前について
[ruby-dev:40676] Re: Enumerable#interleave
2010年3月14日16:36 Yukihiro Matsumoto <[email protected]>: > > 確かにzipはちょっと揺らいだことがあって、ruby-coreで議論した > ことがあります。結局、その時はレシーバーの長さ優先という結論 > を出したのですが、今思えばあまり良くなかったなあと。たとえば、 > with_indexのようなものをzipを使って作る場合、連番が先頭に来 > れないというのはかなり大きな制約のような気がします。 えぇと、たとえば 0から無限に連番を作る iota と 有限の配列 ary があったとして、 ary.each.with_index {|e,i| } は ary.zip(iota) {|e,i| } と実現できるが、 iota.zip(ary) {|i,e| } は無限ループになってしまう、という意味ですか? % ./ruby -e ' iota = Enumerator.new {|y| i = 0; loop { y << i; i += 1 } } ary = %w[a b c] ary.zip(iota) {|x,y| p [x,y] } iota.zip(ary) {|x,y| p [x,y] } ' ["a", 0] ["b", 1] ["c", 2] [0, "a"] [1, "b"] [2, "c"] [3, nil] [4, nil] [5, nil] ... でも、かなり大きな制約、というのはよくわかりません。 どうせブロック引数で受けとるなら、順番はどうにでもなるのでは? 連番を先頭に表示したければ、 ary.zip(iota) {|e,i| p [i,e] } とすれば可能ですよね。 議論をしたという [ruby-core:14738] からのスレッドを読むと、 レシーバの長さを優先するとユーザが繰り返しの終了を選べるが、 最短ので止まると選べない、という点が指摘されていて、それには共感を覚えます。 連番は先頭に置いた方がわかりやすい、というならわからないでもないですが、 その利点が、ユーザが選べるという利点を越えるとは感じません。 > 考えたのは、interlave対象に無限列を含む場合です。たとえば > with_indexをflattenしたようなものを得る時に、停止しないのは > 使いにくかろうと。 iota.interleave(ary) {|x| p x } が 0, "a", 1, "b", 2, "c", 3, 4, 5, ... となるのは使いにくい、と。 ふむ。それはそんな気がしないでもないですね。 zip とは違って、ブロック引数でどうにかすることはできませんからね。 でも、停止したとしても、それをどう使うかというのを考えると 結局は使いにくいという結論になるかもしれないとも思います。 > どうも、具体的になりきれないのがいけませんね。 そうですね。具体例があれば、その例について便利かどうかを考えられるんですが、 ここで出てきている例くらいだと、具体性が足りなくてそういうことを考えるのは 難しいです。 Hash[k1,v1,k2,v2,...] は ks = [k1,k2,...] vs = [v1,v2,...] とすると Hash[*ks.interleave(vs)] と書けて、 interleave が有用な例のような気がするんですが、 これ自体は他の方法で解決されているし、 同じような困り方をした他の例は思い出せないんだよなぁ。 -- [田中 哲][たなか あきら][Tanaka Akira]