33972-34736

33682-36232 subjects 34159-34838

なぜ transcode.c  の  transcode_loop で from_utf8  が特別扱い
33972 [duerst@it ao] 中田さん、皆さん、こんにちは。
33980 [nobu@ru y- a] 256*78 + 64*985 = 83008byte

Test::Unit::Collector::Dirがtest_*.rb以外集めてくれない
33974 [itacchi@gm i] 以下のコミットで、Test::Unit::AutoRunner が test_*.rb 以外は対象外とするようになり、
+ 33981 [nobu@ru y- a] テスト自体は常にtest_*.rbになっているもので、--patternはそこから
| 33984 [itacchi@gm i] コードを眺めていると test_*.rb 派と *_test.rb 派があるようです。
+ 33982 [nobu@ru y- a] テスト自体は常にtest_*.rbになっているもので、--patternはそこから

Re: [ruby-cvs:22913] Re: Ruby:r15674 (trunk): * gc.c (add_heap): sort heaps array in ascending order to use
33983 [matz@ru y- a] ruby-cvsでやるのはやめましょう。
33985 [akr@fs j. rg] その void* の減算は現実的に問題です。
33987 [matz@ru y- a] すみません。中田さんのパッチ[ruby-cvs:22913]で問題は解決しま
33988 [akr@fs j. rg] それはそれで問題が出てますねぇ。

Hash#compare_by_identity breaks commutativity of Hash#==
33989 [akr@fs j. rg] 以下のように、h1 == h2 でないのに h2 == h1 ということになる

Maybe IRB bug!! by 09
33991 [akr@fs j. rg] 以下のように、irb が 09 で Maybe IRB bug!! と表示します。

debug.rb:221:in `debug_command': undefined method `callcc' for #<DEBUGGER__::Context:0xb7a85914> (NoMethodError)
33992 [akr@fs j. rg] 以下のように -rdebug を使うと、例外で終了します。

Re: [ruby-cvs:22935] Ruby:r15695 (trunk): * string.c (is_utf8_lead_byte, count_utf8_lead_bytes_with_ulong):
33993 [akr@fs j. rg] test_regexp.rb が失敗するようになっています。
33995 [naruse@ai em] おっと、手元の64bit環境だと閾値未満なので気づきませんでした。

printf "[%08f]\n", 0.0/0.0
33994 [akr@fs j. rg] 以下のように、printf で NaN, Inf で 0 padding が起こります。
33997 [nobu@ru y- a] テストも間違っているということでしょうか。
33999 [akr@fs j. rg] たぶん。

No definition for sym_succ  など
33996 [duerst@it ao] RDoc を作るときにはいつも No definition for sym_succ など

--program-suffix option of configure.bat(mswin32)
34000 [kimura.koich] configure.bat でmakefileを作成するときに、ヘルプでは出てきませんが
34001 [usa@ga ba ec] とりあえず未保証オプションということで。

sprintf("% e", Inf)
34002 [akr@fs j. rg] で、規格では space flag は効くとされているのですが、効きません。

Array#slice! may be too slow and allocate memory too much
34005 [mame@ts .n .] 以下のプログラムがやたら遅いです。また、メモリを大量に消費します。
34038 [matz@ru y- a] 遅くなりました。

11.divmod(3.5)
34006 [akr@fs j. rg] 以下のように、11.divmod(3.5) の結果の div 部分が浮動小数点数

local_variables contains strings
34008 [akr@fs j. rg] 以下のように、local_variables は文字列の配列を返します。

RUBY_*定数のencoding
34010 [zn@mb .n ft ] RUBY_DESCRIPTIONなどの定数のencodingがASCII-8BITになっていますが、

Should --verbose be equal to -v ?
34011 [yugui@yu ui ] リファレンスマニュアルやmanによれば起動オプション--verbose
34012 [matz@ru y- a] 意図したことです。ドキュメントを書き換えるべきでしょう。
+ 34013 [zn@mb .n ft ] ruby -hには--verboseがないようです。
| 34014 [matz@ru y- a] ません。
| 34015 [zn@mb .n ft ] 一画面におさめるために24行以内にしようとしているのなら、
| + 34016 [duerst@it ao] の代わりに
| + 34017 [matz@ru y- a] ううむ。だからといって無制限に増やす気にはならないのですが。
|   34018 [zn@mb .n ft ] 越えているので、おさめようとしているのなら、減らさないのかな、
+ 34045 [yugui@yu ui ] manを直しました。英文に自信はないですが。
  34047 [matz@ru y- a] ありがとうございます。直してもらっといて文句言うのは心苦しい
  34051 [yugui@yu ui ] 分けてみました。
  34053 [matz@ru y- a] いいんじゃないでしょうか。
  34054 [matz@ru y- a] あ、コミットしてくださいってことです。
  34055 [yugui@yu ui ] コミット権がありません。
  34056 [matz@ru y- a] <cvs-admin@ruby-lang.org>まで

DelegateClassのバックトレース
34019 [gonoguti@ya ] DelegateClassで委譲したオブジェクトのメソッドで発生した

MurmurHash problem
34020 [nobu@ru y- a] これではalignされていないwordアクセスを許さないシステムでは動き
34023 [matz@ru y- a] そうかあ。残念だなあ。またJenkinsハッシュに戻すかなあ。
34024 [naruse@ai em] C99 の stdint.h では uintN_t (N は 8,16,32,64) が必須になっていますから、
+ 34025 [usa@ga ba ec] 不可です。現状でもそれを検出して処理を分岐してるはずですけど
| 34026 [naruse@ai em] ...
| 34027 [nobu@ru y- a] inttypes.hをチェックしてないような気がします。
| 34028 [matz@ru y- a] ちゃんと動くようならコミットしてもらうとありがたいのですが。
+ 34036 [subscriber.j] /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  34039 [naruse@ai em] むむ、C99 だとたしかに持っていれば、になっていますね。

singleton class extended by a module with module_function
34021 [akr@fs j. rg] 以下のプログラムの挙動が 1.8 と 1.9 で異なりますが、意図的な

patch of lazy sweep gc
34022 [authornari@g] ...
34029 [matz@ru y- a] ありがとうございます。RubyのGCをいじる人は、このところ私だけ
34031 [authornari@g] なるほど。これはすぐに試せて有効そうですね。

uint32_t
34030 [kimura.koich] 例によって報告だけです。
34032 [naruse@ai em] この時点では uint32_t でなく unsigned int なので実際に uint32_t になるのは r15760 ですね。
34034 [usa@ga ba ec] ext/digest/defs.hでuint32_tをtypedefしようとしているせいで、
34040 [naruse@ai em] ...
34041 [usa@ga ba ec] Windows側の内容に多少の問題がなくもないですが、その辺は入った
34043 [naruse@ai em] 入れました。
34044 [usa@ga ba ec] いや、単に昨日入れたuint32_tの定義が残ってるから重複になって

ruby coding guideline
34033 [naruse@ai em] [ruby-dev:34024] をまとめ直して新しいスレッドにしてみます。
34035 [usa@ga ba ec] いきなり矛盾してますよぅ。
34065 [naruse@ai em] この部分は問題提起に枕のつもりでした。

Ruby performance gains on SPARC
34037 [matz@ru y- a] によるとSPARCではEXEC_TAGの前のFLUSH_REGISTER_WINDOWSは不要
34057 [akr@fs j. rg] 1.8 と 1.9 で試してみましたが、make test, test-all はとくに
34058 [matz@ru y- a] ありがとうございます。
+ 34063 [Tetsuya.WATA] ruby 1.9 trunk r15781 で試してみました。
+ 34088 [knu@iD em ns]  返事が遅れてすみません。

IOはこれからもEnumerableなのか
34042 [rubikitch@ru] Ruby 1.9ではStringがEnumerableではなくなりましたが、
34046 [matz@ru y- a] IOに関しては行単位に処理するというイディオムが定着している

CGI::Cookie.new  を高速化するバッチ
34048 [kwa@ku at -l] cgi.rb において、CGI::Cookie.new を (多少ですが) 高速化する
34049 [matz@ru y- a] 取り込みました。
34050 [kwa@ku at -l] すばやい対応、ありがとうございました。

IO should provide #each_char and #chars
34052 [yugui@yu ui ] IOにはバイトストリームだけではなく文字ストリームとしての機能
34064 [matz@ru y- a] (コミット権が来たら)コミットしてください。

putsでSEGV
34059 [rubikitch@ru] $stdoutに別のオブジェクトを指定した場合、putsでSEGVります。
34061 [nobu@ru y- a] スタックオーバーフローしてますね。原因は、r15564でKernel#putsが
34062 [nobu@ru y- a] もう一つ思い付きました。

Bignum#div
34066 [tadf@do rb o] 1.9 では、Bignum#div が Bignum#/ とまったく同じになっているようで、

Array#take,take_while,drop,drop_whlie
34067 [mame@ts .n .] ary.drop(1) は each を経由するので常に O(n) かかり、ちょっと遅いです。
+ 34069 [matz@ru y- a] コミットしてください。
+ 34074 [nobu_toyofuk] take と drop という言葉につられてついコードを見てしまった。
| + 34076 [mame@ts .n .] おおっと、ミスです。直してコミットします。
| + 34092 [nobu_toyofuk] 前のメールの最後にちらっとしか書かなかったので改めて。
+ 34123 [nobu_toyofuk] take の引数が負のときと大きな整数のときに enum と array で
  34124 [mame@ts .n .] ありがとうございます。
  + 34127 [matz@ru y- a] コミットしてください。
  + 34156 [nobu_toyofuk] len が LONG_MAX/3 を超えた辺りの、例えば 0x56000000 だと

lgamma_r requires _REENTRANT on Solaris
34068 [mame@ts .n .] Solaris で lgamma_r を使うためには _REENTRANT マクロを宣言する
34070 [nobu@ru y- a] pthreadが見付かれば、_THREAD_SAFEなどとともに定義されるはずなん
34075 [mame@ts .n .] されてました。
34078 [akr@fs j. rg] うぅむ。コミットしてください。

procを組み合わせた再帰呼び出しで例外が投げられない
34071 [s.wanabe@gm ] MinGW上のHEADで以下のスクリプトを走らせると、何のエラーメッセージもなしに強制終了してしまいました。

rb_memsearch optimization
34072 [naruse@ai em] ...
34073 [matz@ru y- a] なるほど。それは考えていませんでした。

異なるエンコーディングだと同じバイト列でも==にならない件
34077 [rubikitch@ru] Ruby 1.9では同じバイト列であっても異なるエンコーディングの場合は == にはなりません。
+ 34079 [matz@ru y- a] 違うエンコーディングであってもコンパチブル(他の処理で同一視
+ 34080 [yugui@yu ui ] エンコーディングは空気のような存在ではないに一票。
| 34082 [matz@ru y- a] 絶対反対というわけではないのですが、その場合にはどのような表
+ 34081 [yui.naruse@g] エンコーディングは空気ではありません、文字列の同定に必要不可欠な情報です。
  34083 [rubikitch@ru] エンコーディングの理解が不十分ですみません。
  34084 [yui.naruse@g] 状態を持つよりは常時の方がいいんじゃないですかね。

extend spawn to change attributes of child process.
34086 [akr@fs j. rg] spaen, system, exec, IO.popen で、起動する子プロセスの属性を
34506 [usa@ga ba ec] これですが、その後どうなっているでしょうか?
34507 [matz@ru y- a] えーと、「特に反対ではない」と田中さんに直接伝えたような気が
34508 [akr@fs j. rg] 入れてみました。

拡張ライブラリ初期化中でのmodule_eval
34093 [kou@co mi ng] 拡張ライブラリを初期化しているとき(Init_XXXを呼んでいるとき)
34104 [kou@co mi ng] これで動くようにはなります。
34734 [kou@co mi ng] ささださん、これはこういうものなのでしょうか?
34735 [ko1@at ot ne]  遅くなってすみません(他にもあったら催促して下さい).
34736 [kou@co mi ng] そういえば、

tempfile.unlink  後に tempfile.close
34094 [fumiyas@os t] Tempfile オブジェクトを unlink した後に close すると、
+ 34419 [fumiyas@os t] ...
+ 34424 [matz@ru y- a] 1.9では対応されてますね。以下のようなパッチが効くみたいです。

(再送)  Cygwin で Resolv.getaddress が失敗する
34095 [yanagi@sh ke] 以前、
34096 [ueda@ne fo e] cygwin 環境は使ってないのでご指摘の問題に遭遇したことが無いのですが、
34097 [yanagi@sh ke] あぁなるほど。
34098 [ueda@ne fo e]  Windows 環境で ruby_1_8 を svn co したら、PC がおかしくなってしまいま
34099 [nobu@ru y- a] どちらかというと、cygwinでwin32/resolv.rbを使っていることが疑問
+ 34102 [usa@ga ba ec] 私も同感です。
+ 34138 [yanagi@sh ke] これだと、今度は次のようなエラーになってしまいます。
  34139 [nobu@ru y- a] Win32::Resolvを使うところで require 'win32/resolv' するのがいい
  34199 [yanagi@sh ke] これを適用した結果、別のエラーになったのですが

delegate Kernel#{gets,readline,readlines} to ARGF
34100 [nobu@ru y- a] Kernel#putsやKernel#putcが$stdoutに委譲するように、Kernel#getsや
34101 [matz@ru y- a] なんか理由があってread系は委譲してなかったような記憶があるの

rational.rb, complex.rb and mathn.rb
34105 [tadf@do rb o] rational と complex が組み込みになったことで、lib/mathn.rb の意義は薄
34106 [tadf@do rb o] 現時点で rational.rb と complex.rb を残しているのは、それが無難だから
34107 [tadf@do rb o] lib/rational.rb はなくす。
+ 34108 [matz@ru y- a] いずれも賛成ですが、当面は空のrational.rbとcomplex.rbを残し
| 34121 [zn@mb .n ft ] ...
+ 34120 [keiju@is it ] rational.c の中に gcd 実際にはあるわけですよね? それを使えるようにした
| + 34125 [sinara@bl de] 私も Complex の組み込みは Rational とは比較にならないくらい、仕様が決め
| | + 34126 [matz@ru y- a] いいんじゃないでしょうか。PythonがComplex組み込みの先輩なんで
| | + 34130 [tadf@do rb o] といっても、標準ライブラリならいい加減でもいいというわけではないので、
| | | + 34131 [matz@ru y- a] Mathモジュールは伝統的にlibmのラッパーであったので、それを逸
| | | | 34132 [tadf@do rb o] それは、[ruby-dev:34106] でも書いたのですが、原さんもそういう意味で反対
| | | | 34135 [sinara@bl de] ちょっと私は勘違いしているところがあったみたいです。デフォルトの動作と
| | | | 34145 [tadf@do rb o] やはりちぐはぐな感じがしますね。
| | | | 34154 [sinara@bl de] 「同じ数値を Rational でも Complex でも表現でき」というところにふなばさ
| | | | 34157 [tadf@do rb o] isqrt というのは、
| | | | 34160 [sinara@bl de] 前者です。なぜそんなに速い整数の平方根にこだわっていたかというと、
| | | | 34167 [tadf@do rb o] isqrt はあってもいいと思いますが、一般的な sqrt としての可能性が制限さ
| | | + 34134 [sinara@bl de] いえ単純に、ルートの中身が負になるなるのは、ユーザが意図してない
| | |   34140 [nobu@ru y- a] (1+√3i)*(1+√3i) = 1+(-3)+2√3i = -2+2√3i = -2(1-√3i)
| | |   + 34141 [shigi@s5 di ] 極座標表示をしたときに、角度が一番小さいからではないでしょうか。
| | |   + 34143 [sinara@bl de] 書きながら表現が悪いなと思っていました、すいません。
| | |     + 34149 [masa16.tanak] 便法というか、複素数を
| | |     + 34151 [shigi@s5 di ] 関数をどう定義するかということになります。
| | + 34133 [sinara@bl de] すいません、書き間違い。-8 の立方根は -2 ですね。
| | + 34155 [sinara@bl de] みつけました。[ruby-math:00914] New methods of Integer から延々と続くス
| + 34129 [tadf@do rb o] それでもよいと思います。
|   34146 [keiju@is it ] メイルが錯綜していますが...
|   34147 [tadf@do rb o] そういうことです。
+ 34252 [tadf@do rb o] 以下のようにしようと思います。

LP64: date.rb:321:in `convert': integer 86400000000000 too big to convert to `int' (RangeError)
34109 [akr@fs j. rg] LP64 なマシンで test-all が動かなくなっています。
34110 [tadf@do rb o] 別の理由で、test-all が手元でできないですが、こんな感じでどうでしょう。
34111 [akr@fs j. rg] 症状がおさまります。

Module#define_methodがprivateなわけ
34112 [rubikitch@ru] ずっと前から疑問ですが、Module#define_methodはなぜprivateなのでしょうか?
34115 [matz@ru y- a] そうです。

Is 'Class.new(Class)' valid?
34114 [rucila@ya oo] RHGの逆襲に向けて class.c を読んでいて気がついたのですが

Improving Fixnum#gcd(Fixnum)
34116 [knu@iD em ns]  常に Integer#gcd(Integer) を使うのは遅いので Fixnum#gcd(Fixnum) を
34118 [matz@ru y- a] 1.9ではRationalは組み込みになってまるごとCで実装されています

backporting features from 1.9 to 1.8
34117 [knu@iD em ns]  一日遅れましたが、Ruby 1.8.7に向け、1.9からバックポートする

Process.daemon kills other threads
34119 [akr@fs j. rg] 思い出したんですが、現在の Ruby 1.9 の Process.daemon では他

--disable=all --enable=gems
34122 [zn@mb .n ft ] % ruby-trunk -v --disable=all --enable=gems -e 'p $"'

enumerator with certain built-in methods dumps core
34128 [mame@ts .n .] 以下で 1.9 が落ちます。

thread.c (fastthread)の状況
34136 [techml@sg pe] DebianでRubyをパッケージングしているのですが、ユーザから要望があったので、ちょっ
34137 [matz@ru y- a] 完全に状況を把握しているわけではないのですが、上記URLのペー
34142 [nobu@ru y- a] 最終的に1.8.6ブランチにバックポートされたのはr13495なので
34148 [techml@sg pe] まつもとさん中田さん、ありがとうございます。

[質問2点] C からの定数参照 & thread switching コストの低減
34144 [nagai@ai ky ] すみませんが,2点質問させてください.
34234 [nobu@ru y- a] クラス/モジュールだけならrb_path2class()がありますが、任意の定数
34246 [nagai@ai ky ] 回答をありがとうございます.
34253 [nobu@ru y- a] あ、evalじゃなくても、class/module限定ならばrb_protect()経由で

sigsetjmp significantly slower on OSX.
34150 [matz@ru y- a] [ruby-core:16023]に示された
34152 [nobu@ru y- a] すいません、こっちを見落としてました。
34153 [matz@ru y- a] これでOS Xでのパフォーマンスが戻るなら。誰か確かめられません

Complex組み込み
34158 [masa16.tanak] Complexが組み込みになるそうですが、これはcomplex.rbを踏襲して、
+ 34161 [sinara@bl de] なぜ今まで気づかなかったのか。すごくいいアイデア!
| + 34164 [nobu@ru y- a] 少なくともC90には複素数型はないと思いますが…。
| | 34171 [masa16.tanak] これは、C99の複素数型、あるいはそれ以前でも
| + 34168 [tadf@do rb o] complex.rb は、いろいろ問題なり課題があるので、そのままつかうには無理が
| | 34186 [sinara@bl de] なんか発言している人たちの任意の二人で意見が食い違ってるみたい…皆さん
| | 34187 [tadf@do rb o] それは、Complex ではなく、ruby の / 演算子の振舞いが原因なので、解決す
| | + 34193 [matz@ru y- a] ごめんなさい。ここで言う「前向きに検討」とは具体的にどのよう
| | | 34203 [tadf@do rb o] ruby では、両辺が整数である場合と、そうでない場合の違いがありますが、
| | | 34215 [matz@ru y- a] では、どのように「なんとかする」か考えましょう。
| | | 34224 [tadf@do rb o] 一番の問題は、/ が悪い意味で多義的だからだと思います。
| | | 34225 [matz@ru y- a] まあ、それは認めます。
| | | 34227 [tadf@do rb o] たぶん、あってます。/ を quo の意味にする、ということです。
| | | 34228 [matz@ru y- a] ちなみに、私の心づもりとしては「quoはもっとも正確に近い値を
| | | + 34229 [tadf@do rb o] 正確というのがどういうものかわかりませんが、基本的には、それでいいと思
| | | | 34230 [matz@ru y- a] さっきコミットしたコードではrdiv, quoはRationalを返すように
| | | + 34232 [muraken@gm i] ふなばさんが [ruby-dev:34229] で仰っているように,浮動小数点数は
| | |   34233 [matz@ru y- a] それは無理でしょうね。誤差のことまで考えると特に。
| | |   34235 [tadf@do rb o] この件に限らず、基本的に ruby では (c) なんだと思います。
| | |   34237 [matz@ru y- a] そうなんですかね。ただ、そうするとRationalを返さないことがあ
| | |   34240 [tadf@do rb o] 結局名前にひっぱられてるだけで、何をしたいのかはよくわからいところがあ
| | |   34242 [matz@ru y- a] そうですね。結果が必ずRationalになる除算が欲しいと言った人は
| | + 34205 [muraken@gm i] 数学では累乗根は R->R,R->C,C->C のどれかで定義されていると思っていた
| | | + 34209 [tadf@do rb o] Math.sqrt(Rational(1,4)) #=> Rational(1,2)
| | | | 34210 [matz@ru y- a] Math.sqrtが現状オブジェクト指向でもなければ総称的でもないの
| | | | 34211 [tadf@do rb o] そこに拘りがあるのであれば、そうするしかないですね。だとすると、CMath
| | | | 34212 [matz@ru y- a] Math.sqrtが複素数を返すとこんなにうれしいという実際の例を聞
| | | + 34216 [shyouhei@ru ] ここにいます。
| | |   34218 [sinara@bl de] ちょっと本題から離れるけど、前からわからなかったのですが、C の math ラ
| | |   34220 [shyouhei@ru ] roundじゃなくてfloorですか?仕様では決まってない気がします。
| | |   34221 [sinara@bl de] 例えば、素数判定を
| | |   34231 [shyouhei@ru ] 数学家ではないので美しさに関して判断できかねますが、このケースではat
| | + 34217 [sinara@bl de] 私は、「/ のほうを変更する」事を考えていません。また、Complex も現状の
| |   34226 [tadf@do rb o] それとこれとは、とりあえず関係がないと考えています。深いところでは、関
| + 34170 [masa16.tanak] 共存できるとよいことですが、仕様とかでもめそうかも。
+ 34166 [tadf@do rb o] それは考えましたが、あくまで実装の都合ですね。浮動小数点数のみからなる
| 34172 [masa16.tanak] 最初に言っておきますが、気を悪くされたのならすみません。
| 34174 [tadf@do rb o] 気にしないでください。
| + 34175 [masa16.tanak] 捨てずに、共存できるかもしれないということは、
| | 34177 [tadf@do rb o] 常になにかしらの面で遜色があって当然じゃないですか。しかも、具体的に困っ
| + 34179 [muraken@gm i] Ruby を科学技術計算に使うために最適化する事を良いと感じてらっしゃらないんでしょうか.
|   34181 [tadf@do rb o] 良くないというか、無理というか。現時点で、ruby として出来るだけのこと
|   34182 [muraken@gm i] Ruby の用途ではなく複素数ライブラリ (Complex クラス) の用途が知りたかったですよね.
|   34183 [tadf@do rb o] 調査したこともないので、それは知りません。
|   34204 [muraken@gm i] 田中昌宏さんとのやりとりで,real と imag を VALUE で持つか,
|   + 34206 [naruse@ai em] え、それ間違ってませんか?
|   + 34208 [tadf@do rb o] どこからが、田中さんの話の延長なのかわからないのですよ。
+ 34176 [shiba@ma l2 ] 斎藤と申します。鋭いかは分かりませんが、できるだけ短めに別角度のツッコミを。
  34178 [masa16.tanak] 考えていなかった観点をご提示いただき、参考になります。
threads.html
top