[#61171] Re: [ruby-changes:33145] normal:r45224 (trunk): gc.c: fix build for testing w/o RGenGC — SASADA Koichi <ko1@...>
(2014/03/01 16:15), normal wrote:
[#61243] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — normalperson@...
Issue #9425 has been updated by Eric Wong.
[#61359] [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs — normalperson@...
Issue #9609 has been reported by Eric Wong.
(2014/03/07 19:09), normalperson@yhbt.net wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>
I'm unsure about this. I _hate_ the extra branches this adds;
Hi Eric,
SASADA Koichi <ko1@atdot.net> wrote:
(2014/03/14 2:12), Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#61452] [ruby-trunk - Feature #9632] [Open] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been reported by Eric Wong.
[#61496] [ruby-trunk - Feature #9638] [Open] [PATCH] limit IDs to 32-bits on 64-bit systems — normalperson@...
Issue #9638 has been reported by Eric Wong.
[#61568] hash function for global method cache — Eric Wong <normalperson@...>
I came upon this because I noticed existing st numtable worked poorly
(2014/03/18 8:03), Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
what's the profit from using binary tree in place of hash?
Юрий Соколов <funny.falcon@gmail.com> wrote:
[#61687] [ruby-trunk - Bug #9606] Ocassional SIGSEGV inTestException#test_machine_stackoverflow on OpenBSD — normalperson@...
Issue #9606 has been updated by Eric Wong.
[#61760] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been updated by Eric Wong.
[ruby-core:61581] [ruby-trunk - Bug #9605] Chaining "each_with_index.detect &lambda" raises ArgumentError
Issue #9605 has been updated by Alex Rothenberg.
@nobu I meant to tell you how honored I am that you and matz are taking so much time talking about this issue and even considering changing this small corner of ruby itself. The idea of changing the language because of something I noticed does feel a little intimidating to me though :)
Thank you for all your hard work building this language I love and let me know if there's anything more I can do to help with this issue.
----------------------------------------
Bug #9605: Chaining "each_with_index.detect &lambda" raises ArgumentError
https://bugs.ruby-lang.org/issues/9605#change-45863
* Author: Alex Rothenberg
* Status: Rejected
* Priority: Normal
* Assignee:
* Category:
* Target version:
* ruby -v: 2.1.1
* Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
I found an odd edge case where "detect" and "select" behave differently from other methods of Enumerable.
Normally these methods yield a single argument to a block but when you chain them after "each_with_index" they yield two arguments "item" and "index". The problem is when you try passing a lambda instead of a block then they raise an ArgumentError
$ irb
2.1.1 :001 > lambda = ->(word, index) { word.length == 3 }
=> #<Proc:0x007ff8848630d8@(irb):1 (lambda)>
2.1.1 :002 > %w(Hi there how are you).each_with_index.detect &lambda
ArgumentError: wrong number of arguments (1 for 2)
from (irb):1:in `block in irb_binding'
from (irb):2:in `each'
from (irb):2:in `each_with_index'
from (irb):2:in `each'
from (irb):2:in `detect'
from (irb):2
from /Users/alex/.rvm/rubies/ruby-2.1.1/bin/irb:11:in `<main>'
2.1.1 :003 > %w(Hi there how are you).each_with_index.select &lambda
ArgumentError: wrong number of arguments (1 for 2)
from (irb):1:in `block in irb_binding'
from (irb):3:in `each'
from (irb):3:in `each_with_index'
from (irb):3:in `each'
from (irb):3:in `select'
from (irb):3
from /Users/alex/.rvm/rubies/ruby-2.1.1/bin/irb:11:in `<main>'
Interestingly it works just find when calling other methods like "map"
2.1.1 :004 > %w(Hi there how are you).each_with_index.map &lambda
=> [false, false, true, true, true]
It also works when you use a proc
2.1.1 :001 > proc = Proc.new {|word, index| word.length == 3 }
=> #<Proc:0x007fc375a3a558@(irb):1>
2.1.1 :002 > %w(Hi there how are you).each_with_index.detect &proc
=> ["how", 2]
2.1.1 :003 > %w(Hi there how are you).each_with_index.map &proc
=> [false, false, true, true, true]
or a block
2.1.1 :001 > %w(Hi there how are you).each_with_index.detect {|word, index| word.length == 3 }
=> ["how", 2]
2.1.1 :002 > %w(Hi there how are you).each_with_index.map {|word, index| word.length == 3 }
=> [false, false, true, true, true]
When testing against JRuby or Rubinius none of these scenarios raise an ArgumentError. I'm guessing this is a bug and not intended behavior. If it is intended then both those implementations have a bug in not raising ArgumentError.
--
https://bugs.ruby-lang.org/