[#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:81435] [Ruby trunk Feature#13606] Enumerator equality and comparison
From:
shevegen@...
Date:
2017-05-28 14:01:21 UTC
List:
ruby-core #81435
Issue #13606 has been updated by shevegen (Robert A. Heiler). I am not even sure that I understand the proposal. If I understood it correctly then two enumerable objects (did I get this part right) should return true if they behave/return the same? I think I can see it being related to duck typing... 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. What would the speed penalty be if one exists? 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. ---------------------------------------- Feature #13606: Enumerator equality and comparison https://bugs.ruby-lang.org/issues/13606#change-65140 * 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>