[#80974] [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit — ko1@...
Issue #13517 has been updated by ko1 (Koichi Sasada).
4 messages
2017/05/02
[#81024] Re: [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit
— SASADA Koichi <ko1@...>
2017/05/07
sorry for late response.
[#80996] [Ruby trunk Feature#13544] Allow loading an ISeqs sequence directly from a C extension without requiring buffer is in an RVALUE — sam.saffron@...
Issue #13544 has been reported by sam.saffron (Sam Saffron).
3 messages
2017/05/04
[#81016] [Ruby trunk Bug#13526] Segmentation fault at 0x0055c2e58e8920 ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux] — s.wanabe@...
Issue #13526 has been updated by wanabe (_ wanabe).
3 messages
2017/05/07
[#81048] Re: [ruby-cvs:65788] normal:r58614 (trunk): rb_execution_context_t: move stack, stack_size and cfp from rb_thread_t — SASADA Koichi <ko1@...>
It causes compile error on raspi 3.
3 messages
2017/05/09
[#81201] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle — "U.NAKAMURA" <usa@...>
Hi, Eric
4 messages
2017/05/16
[#81202] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle
— Eric Wong <normalperson@...>
2017/05/16
"U.NAKAMURA" <usa@garbagecollect.jp> wrote:
[#81427] Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534) — SASADA Koichi <ko1@...>
Hi,
6 messages
2017/05/28
[#81428] Re: Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534)
— Eric Wong <normalperson@...>
2017/05/28
SASADA Koichi <ko1@atdot.net> wrote:
[ruby-core:81437] [Ruby trunk Feature#13606] Enumerator equality and comparison
From:
glex.spb@...
Date:
2017-05-28 16:50:31 UTC
List:
ruby-core #81437
Issue #13606 has been updated by glebm (Gleb Mazovetskiy). shevegen (Robert A. Heiler) wrote: > [...] but they are not entirely the same are they? Different > object id for most objects for example. But it also may be that I did not fully > understand the proposal yet. Most objects in Ruby are compared semantically even if the object IDs are different, including `Array` and `Hash`. > What would the speed penalty be if one exists? If the `Enumerator`s have different `object_id`s, previous the equality check was `O(1)` but is `O(n)` with this proposal (just like for `Array`). > I guess the latter one could be > handled by some "behavioural switch" for people who need the behaviour > desscribed in the proposal, so a use-case example would be helpful. I am not proposing a behavioural switch. This should be a backwards-incompatible change. Use cases are the same as for arrays, except when the "arrays" are "lazy". Example: ~~~ ruby [1, 2, 3].reverse == [3, 2, 1] #=> true [1, 2, 3].reverse_each == [3, 2, 1] #=> false [1, 2, 3].reverse_each == [1, 2, 3].reverse_each #=> false ~~~ With this proposal, the last two are also `true`. ---------------------------------------- Feature #13606: Enumerator equality and comparison https://bugs.ruby-lang.org/issues/13606#change-65141 * Author: glebm (Gleb Mazovetskiy) * Status: Feedback * Priority: Normal * Assignee: * Target version: ---------------------------------------- In Ruby, most objects are compared by value. What do you think about `Enumerator`s following the same pattern? I think this would greatly increase the expressiveness of Ruby. Proposal: Two `Enumerator`s should be considered equal (`==`) if they yield the same number of elements and these elements are equal (`==`). If both of the `Enumerator`s are infinite, the equality operator never terminates. `<=>` should be handled similarly. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>