今日は標準添付ライブラリ csv の修正、久々の bignum.c のリファクタリング(?)などがありました。
csv の変更でツッコミを入れたいのですが bugs.ruby-lang.org が障害発生中らしいので後で。忘れないようにしないと……。
nobu:r43821 2013-11-24 00:44:34 +0900
r43818 で Bignum の RVALUE への埋め込みできるサイズのマクロ RBIGNUM_EMBED_LEN_MAX で条件分岐するようにしていたのは静的に(コンパイル時に)決定可能なので #if で分岐してマクロ定義自体を分岐するようにしています。
mrkn:r43822 2013-11-24 01:08:23 +0900
拡張ライブラリ bigdecimal の BigDecimal_power() で指数部の値? を変換するのに FIX2INT() を使っていたところを FIX2LONG() を利用するように修正しています。代入先は SIGNED_VALUE 型なので、long と一致するとも限らないんですよね(VALUE はポインタと同じサイズ)。
jeg2:r43823 2013-11-24 08:12:11 +0900
標準ライブラリ csv でコメント行として扱う文字を指定する :skip_lines オプションに文字列が渡された時に Regexp に変換(コンパイル)して使うようにしています。これまでも String を渡したら String#match が呼ばれていたのだと思いますが、このメソッドだと引数の方を pattern とするのでマッチせずに動作しなかったのだと思います。
ただ、今の実装だとエスケープせずに Regexp.new に渡しているので、たとえば skip_lines: "." のような指定をすると任意の文字がコメント行の指定になってしまってデータが取れなくなるので Regexp.escape したほうがいいんじゃないと思います。ということでチケットを作ろうと思ったのですが bugs.ruby-lang.org が Internal Server Error を返しているので作れず……。
tmm1:r43824 2013-11-24 09:22:19 +0900
拡張ライブラリ objspace の ObjectSpace.dump_all で出力時の fprintf(3) の size_t に対するフォーマット指示子を PRIuSIZE に修正することで Window 環境でのオーバフロー対策をしています。
jeg2:r43825 2013-11-24 09:44:41 +0900
標準添付ライブラリ csv.rb でヘッダの配列を freeze しておくようにしています。ヘッダの内容は Hash のキーとして利用されるため、String の場合は動的に dup + freeze されるので先に freeze しておくと処理が省けて効率的になるためです。 [ruby-core:58510] [Feature #9143]
けど渡された引数を破壊的に変更してしまうのはいまいち。
tmm1:r43826 2013-11-24 10:20:54 +0900
NEWS ファイルに ObjectSpace.dump と ObjectSpace.dump_all の追加について、また C API の節に rb_postponed_job_register()、rb_profile_frames()、TracePoint の新しい C API からのみ利用できるイベントの追加などデバッグやプロファイルに利用できる新機能について追記しています。
akr:r43827 2013-11-24 13:51:33 +0900
久々に akr さんの bignum.c のリファクタリング。 int128_t が利用可能な時に BDIGIT_DBL に利用していたのをやめています。 int128_t がいつも高速とは限らないから、というコミットログなので、何らかのエミュレーションによる int128_t が提供されている場合があって、そのケースで利用する利点はないからってことかと思います。
nobu:r43828 2013-11-24 16:17:52 +0900
r43823 の ChangeLog エントリの日付のタイムゾーンを修正。また r43816 の ChangeLog エントリの typo 修正も。
akr:r43829 2013-11-24 18:15:34 +0900
SIZEOF_ACTUAL_BDIGIT というマクロを定義して、RVALUE に Bignum の数値が埋め込めるかの判定にこの新しいマクロを利用するようにしています。 SIZEOF_BDIGITS は sizeof(BDIGIT) とは異なる場合があるため。よくわかりませんが BDIGIT に unsigned short を利用していて short が long の半分以下のサイズの時は SIZEOF_BDIGITS は sizeof(short) ではなくて sizeof(long)/2 に丸め(切り上げ)られていて実際に必要なサイズよりも大きい可能性があるようです。おそらくメモリアライメントの都合じゃないかなと思います。
akr:r43830 2013-11-24 22:27:14 +0900
bignum.c の Bignum のビット演算を処理する関数 bigxor_int(), bigor_int, bigand_int() で long の値を BDIGIT に対して利用する時に BIGLO() マクロでマスクするようにしています。 SIZEOF_BDIGITS が SIZEOF_LONG よりも大きい場合のコードなのでおそらく y が負数の時の promotion で上位 bits が 1 埋めされる可能性があったのではないかと思います。
