[#47033] [ruby-trunk - Bug #8749][Open] Readline.readline stops STDOUT? — "no6v (Nobuhiro IMAI)" <nov@...>
9 messages
2013/08/07
[#47036] Re: [ruby-trunk - Bug #8749][Open] Readline.readline stops STDOUT?
— Tanaka Akira <akr@...>
2013/08/07
2013/8/7 no6v (Nobuhiro IMAI) <nov@yo.rim.or.jp>:
[#47564] [ruby-trunk - Bug #8719][Open] r42096 make bm_app_factorial.rb slow — "authorNari (Narihiro Nakamura)" <authorNari@...>
4 messages
2013/08/02
[#47565] [ruby-trunk - Bug #8719] r42096 make bm_app_factorial.rb slow
— "authorNari (Narihiro Nakamura)" <authorNari@...>
2013/08/02
[#47569] [ruby-trunk - Feature #8726][Open] Class#source_location — "takiuchi (Genki Takiuchi)" <genki@...21g.com>
14 messages
2013/08/03
[#47574] Re: [ruby-trunk - Feature #8726][Open] Class#source_location
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/08/03
> Classオブジェクトが生成された場所を返す Class#source_location メソッドの実装を希望いたします。
[#47575] Re: [ruby-trunk - Feature #8726][Open] Class#source_location
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/08/03
> なるせさん、わたし、あのバックトレースの整形処理がイマイチ理解できんのだが、
[#47609] Re: [ruby-cvs:49669] naruse:r42527 (trunk): refix r42525 set stdio_file only if stdio — Tanaka Akira <akr@...>
2013/8/12 <naruse@ruby-lang.org>:
7 messages
2013/08/12
[#47610] Re: [ruby-cvs:49669] naruse:r42527 (trunk): refix r42525 set stdio_file only if stdio
— "NARUSE, Yui" <naruse@...>
2013/08/12
あぁ、[ruby-dev:47608]見てませんでした。
[#47611] Re: [ruby-cvs:49669] naruse:r42527 (trunk): refix r42525 set stdio_file only if stdio
— Tanaka Akira <akr@...>
2013/08/12
2013年8月12日 11:38 NARUSE, Yui <naruse@airemix.jp>:
[#47614] Re: [ruby-cvs:49669] naruse:r42527 (trunk): refix r42525 set stdio_file only if stdio
— "NARUSE, Yui" <naruse@...>
2013/08/12
editline の問題は、editlineにはrl_getcがなく、かつreadline.cで、
[#47620] Ruby 2.1 開発者会議 2013-08-31 のお知らせ — "NARUSE, Yui" <naruse@...>
かなり暑いですが、こんにちは。
5 messages
2013/08/14
[#47649] Re: [ruby-changes:30564] akr:r42643 (trunk): * process.c (rb_proc_times): Use RB_GC_GUARD to guard objects from GC. — SASADA Koichi <ko1@...>
akr さん
4 messages
2013/08/21
[#47650] Re: [ruby-changes:30564] akr:r42643 (trunk): * process.c (rb_proc_times): Use RB_GC_GUARD to guard objects from GC.
— Tanaka Akira <akr@...>
2013/08/21
2013/8/21 SASADA Koichi <ko1@atdot.net>:
[#47663] Re: [ruby-core:56878] [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy — "Akinori MUSHA" <knu@...>
At Fri, 30 Aug 2013 21:49:34 +0900,
6 messages
2013/08/30
[#47664] Re: [ruby-core:56878] [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/08/30
2013/8/30 Akinori MUSHA <knu@idaemons.org>:
[ruby-dev:47662] [ruby-trunk - Feature #8838][Open] Enhancing Numeric#step
From:
"knu (Akinori MUSHA)" <knu@...>
Date:
2013-08-30 15:47:33 UTC
List:
ruby-dev #47662
Issue #8838 has been reported by knu (Akinori MUSHA).
----------------------------------------
Feature #8838: Enhancing Numeric#step
https://bugs.ruby-lang.org/issues/8838
Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: misc
Target version: current: 2.1.0
DevelopersMeeting20130831Japan用に起票します。
ちょうど3年ほど前、 [ruby-dev:42194] で私が提案したのが以下の内容です。
> Numeric#step の仕様の拡張を提案します。
>
> 現在、 Numeric#step は limit を必須引数としているため、手軽に
> 無限数列を生成することができません。Float::INFINITY ないし 1/0.0
> のような値を渡せば可能ではありますが、「1から上限なしでカウント
> アップする」のようなよくある要件を満たす方法としては冗長です。
>
> そこで、上限(下限)なしでループするように limit も省略可能とし、
> なおかつ増分のみの指定もできるように疑似キーワード引数を導入して
> みました。
>
> 1.step {|i| ... } # i = 1, 2, 3, ...
> -1.step(by:-1) {|i| ... } # i = -1, -2, -3, ...
> 1.0.step(by: 0.1, to: 2.0).to_a # [1.0, 1.1, ..., 2.0] (余談:誤差に注意)
> 2.step(by:2).take(100) # [2, 4, 6, ..., 200]
>
>
> キーワードを by: と to: にしたので、従来のように順序で意味を
> 表すより読みやすいと思います。いかがでしょうか。
これについては、[ruby-dev:42204]にて「一晩考えた」まつもとさんにOKをい
ただきました。ただ、ここからC APIを設けようという方向に話が進みました。
> 一晩考えて、stepメソッドへの拡張そのものには賛成しようと思い
> ました。ただ、今後キーワード引数を取るメソッドが増加すること
> が容易に想像できますので、C APIでもキーワード引数に対応した
> いと思います。
それを私の方でうまくまとめきれず、尻切れとんぼになってしまいました。
それから3年経ち、Ruby 2.0では「本物の」キーワード引数文法が導入されまし
たが、Cレベルでキーワード引数をdestructureするようなAPIはまだありません。
Enumeratorの進化(Enumerator::Lazyの導入等)で無限数列を手軽に生成した
いシーンは増えていると思いますが、 Enumerator#with_index(n=0) が使える
ケースを除けば、上記提案にもある通り、 1.upto(Float::INFINITY) などと書
くしかなく、スマートとは言いがたい現状です。
そこで、APIは別途議論するとして、機能としては2.1で入れてしまいませんか
というのが今回の提案です。
--
http://bugs.ruby-lang.org/