[#26664] refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
山本です。
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
[#26711] --with-static-linked-extするとrequireできないライブラリがある — IWATSUKI Hiroyuki <don@...>
岩月と申します。
なかだです。
[#26721] TkVariable.new_hash 経由だと trace が発生しない — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
[#26723] Fixnum演算メソッド中のcoerceの削減 — Tadashi Saito <shiba@...2.accsnet.ne.jp>
斎藤と申します。
[#26743] zsuper in a method with optional arg — "NAKAMURA, Hiroshi" <nakahiro@...>
-----BEGIN PGP SIGNED MESSAGE-----
まつもと ゆきひろです
-----BEGIN PGP SIGNED MESSAGE-----
[#26745] TkCheckbutton#variable as getter? — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
永井@知能.九工大です.
山本です。
永井@知能.九工大です.
[#26753] some questions about tcltklib.c — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
永井@知能.九工大です.
山本です。
[#26764] multi-thread and logger — Nobuhiro IMAI <nov@...>
いまいです。
[#26791] Failure: test_block_passing(TestIterator) — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
まつもと ゆきひろです
[#26800] reducing PUSH_TAG in rescue, and useless exceptions — nobu@...
なかだです。
[#26808] test/nkf/test_kconv.rb — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
[#26817] test/socket/test_tcp.rb freeze on windows — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
こんにちは、なかむら(う)です。
山本です。
山本です。
こんにちは、なかむら(う)です。
山本です。
こんにちは、なかむら(う)です。
山本です。返信が遅れてすみません。
[#26829] cannot check EOF of pipe on windows — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
山本です。
こんにちは、なかむら(う)です。
山本です。
なかだです。
山本です。
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
山本です。
[#26840] [BUG] oniguruma + utf-8 — "NAKAMURA, Hiroshi" <nakahiro@...>
-----BEGIN PGP SIGNED MESSAGE-----
[#26851] ripper for 1.8 — Tanaka Akira <akr@...17n.org>
ruby-1.8 で動かす gonzui で、ruby code の解析をしたいという要望があっ
[#26872] irb -I/ruby -Iと$LOAD_PATH — akira yamada / やまだあきら <akira@...>
Debianユーザからruby -Iとirb -Iで
なかだです。
nobuyoshi nakada wrote:
けいじゅ@いしつかです.
けいじゅ@いしつかです.
なかだです。
けいじゅ@いしつかです.
まつもと ゆきひろです
けいじゅ@いしつかです.
[#26883] top level include on load(filename, true) — Shugo Maeda <shugo@...>
前田です。
[#26897] fail on make install — KIMURA Koichi <kimura.koichi@...>
木村です。
こんにちは、なかむら(う)です。
木村です。
木村です。
木村です。
こんにちは、なかむら(う)です。
木村です。
こんにちは、なかむら(う)です。
なかだです。
山本です。
なかだです。
なかだです。
山本です。
こんにちは、なかむら(う)です。
なかだです。
まつもと ゆきひろです
山本です。
なかだです。
[#26900] multiplying empty string — nobuyoshi nakada <nobuyoshi.nakada@...>
まつもと ゆきひろです
In article <1125327516.070646.12845.nullmailer@x31.priv.netlab.jp>,
まつもと ゆきひろです
In article <1125356798.802509.8788.nullmailer@x31.priv.netlab.jp>,
まつもと ゆきひろです
In article <1125369966.174424.13781.nullmailer@x31.priv.netlab.jp>,
[ruby-dev:26693] Re: show information of '--enable-pthread'
永井@知能.九工大です.
まとめてリプライします.
From: Takahiro Kambe <taca@back-street.net>
Subject: [ruby-dev:26690] Re: show information of '--enable-pthread'
Date: Tue, 2 Aug 2005 00:32:39 +0900
Message-ID: <20050802.003233.11903290.taca@back-street.net>
> > 同一マイナーバージョンのバイナリが複数存在した場合,
> > いずれも <install-dir>/<arch>/rbconfig.rb を
> > 読んでしまいますよね?
> そういった場合に <install-dir>/<arch> 以下は共有して使用できるものなの
> でしょうか? (共有ライブラリもあるかもしれませんし。)
う〜む.
「使用できる場合もあれば使用できない場合もある」としか
言えないですね.
> > そうすると,得られるのは「最後にインストールしたバイナリ
> > での設定」であって,それが正しい情報かはわからない.
> 最後にインストールしたバイナリ以外にも動作保証をしなければならないので
> しょうか。最後にインストールしたもの以外は動作しなくても、当然の帰結な
> 気がします。
動作を「保証」する必要はないと思います.
気にしているのは嘘の情報を提示してしまうことだけです.
ですが,「rbconfig.rb が信用できないなら,同ディレクトリの中身自体が
信用できず,結果として『正しい』と言える情報が存在しなくなる」
というのも確かですね.
バイナリに埋め込んでしまえば,少なくともそのバイナリに関しては
正しい情報を提示することができるわけですが,
From: Yukihiro Matsumoto <matz@ruby-lang.org>
Subject: [ruby-dev:26691] Re: show information of '--enable-pthread'
Date: Tue, 2 Aug 2005 06:38:26 +0900
Message-ID: <1122932308.634645.6744.nullmailer@x31.priv.netlab.jp>
> |# バイナリに埋め込んでしまえば,そんな心配も無縁になるのですが.
>
> もちろんなんでもバイナリに埋め込めばそんな心配も無縁になりま
> すが、逆に肥大化の原因になるわけで、そこはトレードオフだと思
> います。今回は永井さんご自身が「そんな場合あるのか?」と突っ
> 込むようなケースですから、そこまで心配する必要はないと思って
> います。
というように,肥大化が懸念されることも分かります.
「めったに使われない情報でバイナリが大きくなることは望ましくない」
というのは確かに正論ですね.
そうすると,今回の件に関しての結論は,
・「正しい」と言える情報を提示するようにするには,
色々な意味でコストがかかりすぎ,得られる効果に
対して割が合わない.
したがって,何の対策もせずに現状のままとする.
つまり,rbconfig.rb で情報を得ることはできるが,
それが正しい情報かどうかは不明であり,
それに基づいて判断する処理を書いたとすると
不具合の元となる危険が大きい.
・perl の -V オプション相当の実装はあってもいいかも.
( 誰がそれを実装するかは別として.)
ということですね.
正直なところ,--enble-pthread オプションのように
動作に致命的とも言えるような影響を与えるものだけでも
ライブラリ require 時にチェックできればと思ったのですが...
...と考えてみると,configure オプション一般の話に
なってしまったことがそもそもの間違いですね.(^_^;
というわけで,問題を変更しての再提案です.
「現在稼働中の ruby が native-thread をサポートして
動作しているかを確認する手段があってもいいのでは?」
現在は ruby のレベルで native-thread を操作することは
ないですから,C のレベルでチェックする手段でも十分でしょう.
ですので,「そのような関数を用意するか?」,
用意するなら「関数の名前はどうするか?」,
「関数を入れる場所 (ファイル) はどこにするか?」
というところが議論点かと思います.
検討いただけますと幸いです.
# 付随的には,
# 「そのようなものは native-thread サポートだけか?」
# という議論もあるかもしれません.
--
永井 秀利 (九工大 知能情報)
nagai@ai.kyutech.ac.jp