[#2796] ext/socket.c — WATANABE Tetsuya <tetsu@...>
わたなべてつやです。
[#2810] [BUG] IO#eof? when Thread using — keiju@... (Keiju ISHITSUKA)
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
はじめまして、中井と申します。
まつもと ゆきひろです
[#2815] Kconv.guess — WATANABE Hirofumi <watanabe@...>
わたなべです.
[#2820] experimental release 1.1b9_24 — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
[#2854] experimental release 1.1b9_25 — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
前橋です。
前橋です。
[#2872] OPENSTEP for Mach / NeXTSTEP 3.3J patch for ruby1.1b_25 — SHIROYAMA Takayuki <psi@...>
まつもと ゆきひろです
[#2881] Re: [ruby-list:8337] Re: TkMenu's bug — NAGAI Hidetoshi <nagai@...>
永井@知能.九工大です.
まつもと ゆきひろです
永井@知能.九工大です.
まつもと ゆきひろです
[#2899] Re: [ruby-list:8388] Re: what type are true and false — keiju@... (石塚圭樹 )
けいじゅ@日本ラショナルソフトウェアです.
[#2911] experimental release 1.1b9_26 — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
わたなべです.
まつもと ゆきひろです
前橋です。
まつもと ゆきひろです
永井@知能.九工大です.
まつもと ゆきひろです
1.1b9_26をコンパイルしてみたのですが、
[#2928] RSHIFT() について — EGUCHI Osamu <eguchi@...>
お久しぶりです。
[#2940] experimental release 1.1b9_27 — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
ruby-1.1b9_27 での話です。システムに依存している可能性もある
From: matz@netlab.co.jp (Yukihiro Matsumoto)
ふなばです。
[#2951] RE: diff for ruby-1.1b9_25 (mswin32) — 助田 雅紀 <masaki.suketa@...>
助田です。
[#2961] Regexp の実行が遅い気がします — Kazunori NISHI <kazunori@...>
西@九大です。
[#2965] feature freeze for 1.1c — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
From: matz@netlab.co.jp (Yukihiro Matsumoto)
ごとけんです
>>>>> "M" == Yukihiro Matsumoto <matz@netlab.co.jp> writes:
まつもと ゆきひろです
わたなべです.
まつもと ゆきひろです
>>>>> "M" == Yukihiro Matsumoto <matz@netlab.co.jp> writes:
まつもと ゆきひろです
[#2991] RE: feature freeze for 1.1c — "YANAGAWA Kazuhisa" <kjana@...>
in [ruby-dev:2965] feature freeze for 1.1c
[#3030] [BUG] string[n..m] = 0 => Bus Error — gotoken@... (GOTO Kentaro)
ごとけんです
わたなべです.
[#3048] grand renaming — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
[#3056] experimental release 1.1b9_28 — matz@... (Yukihiro Matsumoto)
subject says all.
前橋です。
立石@JAISTです。
前橋です。
ふなばです。
立石@JAISTです。
[#3065] [REQ] caller binding — keiju@... (Keiju ISHITSUKA)
けいじゅ@日本ラショナルソフトウェアです.
[#3067] collect{}.sort{} bug? — Inaba Hiroto <inaba@...>
バグだと思いますが、何がわるいんでしょう?
[#3086] Re: Enumerable#reverse ([ruby-list:8579]) — gotoken@... (GOTO Kentaro)
ごとけんです
けいじゅ@日本ラショナルソフトウェアです.
ごとけんです
ひわだです。
[#3110] Re: bignum of ruby11b9_28 — 助田 雅紀 <masaki.suketa@...>
助田です。
[#3122] Ruby/Tk unofficial patch — NAGAI Hidetoshi <nagai@...>
永井@知能.九工大です.
[#3146] [REQ] trace_func — keiju@... (Keiju ISHITSUKA)
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
けいじゅ@日本ラショナルソフトウェアです.
[ruby-dev:2906] Re: what type are true and false
けいじゅ@日本ラショナルソフトウェアです.
In [ruby-dev :2903 ] the message: "[ruby-dev:2903] Re: what type are
true and false ", on Jun/18 11:29(JST) Yukihiro Matsumoto writes:
>まつもと ゆきひろです
> (1) 以下のコードが不自然
>
> eval "foo = 1"
> foo # => NameError
>
> (2) 以下のコードが不自然
>
> proc{
> eval "foo = 1"
> proc {foo = 10}.call
> eval "foo" # => 10
> }.call
そうなんですね. これってお互いに相反していいる部分があるので, 両方を成
立することはできないですね.
>で,1の方は
>
> evalがあった場合にはそれを優先する
>
>ことを求めています.つまり,静的のプログラム上には登場しなく
>ても,evalで評価されたならローカル変数として認めてくれと言う
>ことですね.これによるメリットは
>
> * evalによるローカル変数のずれがなくなる
> * irbの挙動と一致する
まあ, irbのことはさておき.
>です.デメリットは
>
> * 以下のコードが理解しにくくなる
>
> $str = "foo = 25"
>
> # 別の何処か
> eval $str
> foo # これは変数かメソッドか
>
> 現状なら局所的に見るだけでこれがメソッド呼び出しであるこ
> とを保証できます.
うーん. それはいえますね. 今の仕様が良いような気がしてきました.
# μ-lispじゃないけどわけわかな動作の元になりそう(^^;;;
# 懐かし過ぎる話題だ(^^;;;
> * 実行コストが若干上がる
> 実はもうテスト的に実装してみました.
# しかし相変わらず素早い(^^;;;
>デメリットのうち後者は些細なものなので,さしたる問題は無いの
>ですが,前者は若干不満です.もっともirbとの挙動が揃うという
>のはかなり重要なのですが.
irbというか逐次実行のイメージってことですよね.
``これは, ローカル変数の決定は静的に行なわれる.''という方針が明確にす
ればそれで良いと思います.
>さて,2番目の問題の方は
> evalがあっても場合プログラムの字面を優先する
>ポリシーを求めています.ということは1とは相反しますね.
>同時に達成することは出来そうにありません.(- -);
ですね.
>これによるメリットは
> * とりあえず関数版と同じ動作を実現できる
> * evalのあるなしがローカル変数のスコープに影響しない
>というものがあります.私は個人的にはevalに渡す文字列の内容を
>見なくても変数のスコープが決定できることが好みなので,こっち
>を採用したい気持ちはあります.
私もこっちをやった方が良いという気になっています. というか, 元々の方針
とずれていると思っていたんですけどね.
># もっともevalによる影響を無効化はできないので,程度問題では
># ありますが.
後どんな場合があるんですかね?
>こちらもテスト的に実装してみました.こちらは実行コストはかか
>りません.むしろ,若干処理が減ります.
>こちらのデメリットは,1と矛盾することから
> * irbとの挙動の違いを克服できない
>ということでしょうか.
irbのFAQに入れておきます(^^;;;
こういう時は, begin...endを明示的に入れて, バッチ実行してねって感じ.
# でも, 問題がありました最後のPS参照.
>いずれにしても今のrubyの挙動は通常ローカル変数はevalによって
>スコープの影響を受けず,ブロック内ローカル変数はevalによる影
>響を受けるという中途半端な仕様ですから,1か2か「どちらか」を
>採用する必要があるようです.
ですね. 現在は中途半端ですよね.
私も2に1票です.
>どちらも実装しちゃいましたので,どっちでも手間は同じなんです
>がね.
# うーん. 素晴らしい....
PS.
現在ですと, 以下の2つの動作が違っているので, それも一致するのを確認し
てからリリースしてね.
eval '
begin
eval "foo2 = 0"
(proc {foo2 = 10}).call
eval "p foo2"
end
'
p = proc{proc{}}.call
eval '
begin
eval "foo3 = 0"
(proc {foo3 = 10}).call
eval "p foo3"
end
', p
__
................................石塚 圭樹@日本ラショナルソフトェア...
----------------------------------->> e-mail: keiju@rational.com <<---