[#45910] [ruby-trunk - Bug #6694][Open] Thread.new without block. — "ko1 (Koichi Sasada)" <redmine@...>

24 messages 2012/07/04

[#45913] [ruby-trunk - Bug #6698][Open] MacOSXではDir.globが返すファイル名の内容はUTF8-MACですがencodingがUTF-8になっている — "imkira (Mario Freitas)" <imkira@...>

10 messages 2012/07/04

[#45933] [ruby-trunk - Bug #6716][Open] FileUtils.mv でリンク先がないシンボリックリンクファイルを指定すると ENOENT エラーになる — "tommy (Masahiro Tomita)" <tommy@...>

8 messages 2012/07/10

[#45976] [ruby-trunk - Bug #6756][Open] FileUtils.rm_rf がアクセス権のない空ディレクトリを削除しない — "fumiyas (Fumiyasu SATOH)" <fumiyas@...>

9 messages 2012/07/20

[#46012] [ruby-trunk - Feature #6812][Open] Refactor gc.c — "authorNari (Narihiro Nakamura)" <authorNari@...>

13 messages 2012/07/30

[ruby-dev:45937] Re: [ruby-cvs:43524] kosaki:r36348 (trunk): * include/ruby/ruby.h: Removed RUBY_GLOBAL_SETUP complely. It is

From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2012-07-11 06:29:26 UTC
List: ruby-dev #45937
2012/7/9 Nobuyoshi Nakada <nobu@ruby-lang.org>:
> なかだです。
>
> At Tue, 10 Jul 2012 05:39:10 +0900,
> SASADA Koichi wrote in [ruby-dev:45928]:
>>  こちら,残しておいてもいいかもしれない,とちょっと思っています.
>>
>> (1) 何かしら,今後定義したいかもしれない
>> (2) 空の定義を残しておけば,これまでのアプリ組込みのコードが動く
>>
>>  (1) のような,「今後あるかも」系の提案は evil かもしれません
>> が....core だけの話なら,後で revert すればいいんですが,libruby を使っ
>> てる人のコードがあることを考えると躊躇する次第です.

なにか誤解があると思うのですが、このコミット前ですと空マクロなので例え、
librubyをリンクしているアプリケーションがが RUBY_GLOBAL_SETUP を使っていたとしてもNOPに
展開されてしまっているので、今後librubyの RUBY_GLOBAL_SETUP が
置き換わったとしても動作はしません。libruby系の話をするなら ruby_platform_setup()
みないな関数を作って、かつ組み込みアプリケーションはそれを必ず呼ばないといけないというようなドキュメントがないとうまくいかないと考えています。意味のある動作をしているコードがあるならコードを読んで理解しろという態度も成り立つ余地もありますが現状NOPなわけですし。

> 削除には反対します。ここで互換性を壊す必要があるほどジャマなコー
> ドでもないし、実際[Feature #5053]のチェックを実装してみる際にも
> 使ったりしています。
>
> 元のMacOSの分岐は無意味になっているので消して構わないと思います
> が、@deprecatedというコメントはrevertしなくていいです。

つぎにこちらについてですが、どうにも使い道がない、それほど邪魔ではないのどちらともTrueであると考えているのでrevert自体には反対しません。しかしこれを他の目的に再利用することには反対します。マクロがライブラリ境界を超えている事自体が良くないので、こいつはそのまま誰にも使われてないまま死んでいくべき。

[Feature #5053]
のチケットにはなかださんのパッチは添付されていないようですので、そちらにはコメントできませんが普通に関数呼び出しで比較するようなつくりに出来ない理由が思いつきません。


追伸: オブトピックですが、現状5053ではRUBY_DESCRIPTION
を比較する案が提案されてますが、コンパイルオプションを変えて性能比較する最中にミスるとかのケースを考えると単にコンパイル時刻を埋め込んで比較するのがシンプルでいいんじゃないかな

In This Thread

Prev Next