[#30872] segv when reentering into Fiber with callcc — sheepman <sheepman@...>
こんばんは、sheepman です。
ささだです。
遠藤と申します。
ささだです。
遠藤です。
ささだです。
まつもと ゆきひろです
In article <E1Hw9be-0002Rs-Qg@x31>,
まつもと ゆきひろです
[#30920] Integer#prime_division と Prime — TOYOFUKU Chikanobu <nobu_toyofuku@...>
豊福です。
[#30929] secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...>
-----BEGIN PGP SIGNED MESSAGE-----
In article <4669066C.2080307@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <46694461.4060706@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <46697C0B.8060402@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <4669DAB0.4050705@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <466AA73C.9030407@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
なかだです。
-----BEGIN PGP SIGNED MESSAGE-----
In article <466D5B1D.8030205@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <469253E9.9010203@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
-----BEGIN PGP SIGNED MESSAGE-----
In article <4694338C.7090303@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
In article <4694E6A6.2060303@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
なかだです。
-----BEGIN PGP SIGNED MESSAGE-----
なかだです。
-----BEGIN PGP SIGNED MESSAGE-----
[#30971] Linux/ia64で'ucontext_t' undeclared — akira yamada / やまだあきら <akira@...>
最近のRuby 1.9をLinux/ia64上でmakeしようとすると
まつもと ゆきひろです
Yukihiro Matsumoto さんは書きました:
まつもと ゆきひろです
Yukihiro Matsumoto さんは書きました:
まつもと ゆきひろです
In article <E1HygwQ-0001OA-4f@x31>,
ささだです。
[#30996] new block parameter rule — SASADA Koichi <ko1@...>
ささだです。
[#31002] ("a".."f").step(2) {|x| p x} — Tanaka Akira <akr@...>
string の range の step で引数が効かないように思います。
まつもと ゆきひろです
ささだです。
まつもと ゆきひろです
[#31028] rb_get_interned — Nobuyoshi Nakada <nobu@...>
なかだです。
[#31034] Re: [ruby-cvs:19815] Ruby:r12579 (trunk): * parse.y (rb_intern2): name may not be NUL-terminated. — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
[#31046] Conditional jump or move depends on uninitialised value(s) in TOPLEVEL_BINDING — Tanaka Akira <akr@...>
valgrind をかけたところとりあえず最初のが
ささだです。
[#31063] make error at bcc32 — "Nebata" <tnebata@...>
ねばたです。
[#31066] consts for gdb support — Nobuyoshi Nakada <nobu@...>
なかだです。
[#31068] $&;[] dumps core — "Yusuke ENDOH" <mame@...>
遠藤と申します。
ささだです。
遠藤です。
ささだです。
遠藤です。
[#31072] {*0} dumps core — "Yusuke ENDOH" <mame@...>
遠藤と申します。
ささだです。
[ruby-dev:30884] Re: block wrapper
In article <E1Hv4fY-0005eN-9L@x31>,
Yukihiro Matsumoto <matz@ruby-lang.org> writes:
> lambdaによって生成したProcの厳密化は行います。あきらめたのは、
> lambdaによって生成したとしてもyieldで呼び出したら厳密なチェッ
> クは行わないようにすることです。
なるほど。
lambda と call で扱う範囲で通常のメソッド的引数渡しのセマン
ティクスが保たれるのは、いままでまともでなかったのがまともに
なるということで、長年の問題が改善されるので嬉しいです。
その代償として、[[1,2],[3,4]].each(&lambda {|a,b| p [a,b]})
がエラーになるわけですが、Proc.new や proc は残るんでしたっ
け?
> * lambdaでは厳密なチェック
> * yieldはcallの別名
>
> です。今週ささだくんと直接会うのでその時いろいろ相談します。
同じなら別名はいらないんじゃないの、と私の minimalist 的側面
がささやきます。もちろん Ruby が minimalistic なデザインでは
なく、それが強い理由にならないことはわかっていますが、疑問の
きっかけにはなります。
そして、[ruby-dev:30856] にあげられている理由のうち、後者は
call でも nil.call を作ればいいので、残る理由は前者のニュア
ンスだけになります。
ニュアンスというが効果がないとはいいませんし、そういうところ
にこだわった結果が Ruby であるともいえるので反対する程ではな
いのですが、Proc#yield ってそんなにいるんですかね?
また、Proc#yield と Proc#call では call のほうが 1文字短いの
で call 側への誘導がある程度働きます。Proc#yield のニュアン
スの力がそれと拮抗していると両方から引っ張られてあまり気分が
よくならないかもしれません。
> |例えば [ruby-talk:162561] で提案し反応がなかった案をブロック
> |引数に適用すれば、(ラッパーに * じゃなくて ** を使うことにな
> |りますが) ラッパーを値の並び以外の情報をそれほど不自然でない
> |形で載せられるので呼び出し側の細工とラッパーを両立できます。
>
> あれ、私このメール見落としてました。ふーむ。
そういえば、キーワード引数の扱いは今どうなっているんですか?
--
[田中 哲][たなか あきら][Tanaka Akira]