[#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:81143] [Ruby trunk Feature#13559] Change implementation of Feature #6721
From:
eregontp@...
Date:
2017-05-13 14:49:40 UTC
List:
ruby-core #81143
Issue #13559 has been updated by Eregon (Benoit Daloze).
I agree #yield_self is less than ideal.
To start, it is quite long (10 letters including a underscore) for a very simple method.
In an ideal world, I think #itself with a block doing what #tap does today and #tap doing what #yield_self does would make sense.
But that cannot work with compatibility.
This blog post also made me realize it can be confusing as a method name:
https://bogdanvlviv.github.io/posts/ruby/new-method-kernel-yield_self-since-ruby-2_5_0.html
> "#tap yields self to the block and then returns self."
That sounds exactly to what "yield_self" would do.
> "#yield_self yields self to the block and then returns the result of the block execution."
#tap already "yields self" and the difference that the block value is returned is absent from the name yield_self.
I am unfortunately not sure what a good name would be.
Maybe #pipe ? (#| conflicts with Array#| so that's not good)
number.pipe { |x| x ** 2 }.next.pipe { |x| x ** 2 }
Fundamentally it works like #map on a single element, but that's already taken by Enumerable#map
and we need something that does not imply collections.
#as and #let seem the most descriptive but do not read well in a chain of method calls.
#itself seems a good compromise.
The current usage like `ary.count(&:itself)` to make a block that returns the element
and then expanding it to `number.itself { |n| n*n }` makes sense to me.
Instead of having `&:itself` be a simple block just returning the argument we can customize it by given #itself a block and return what we want
(which is what most blocks do, use the return value of the block instead of ignoring it).
----------------------------------------
Feature #13559: Change implementation of Feature #6721
https://bugs.ruby-lang.org/issues/13559#change-64794
* Author: dunrix (Damon Unrix)
* Status: Feedback
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
Hi,
please reconsider implementation of feature request #6721 planned for Ruby 2.5.0 .
Instead of introducing new method `Object#yield_self`, just reuse existing `Object#itself` by taking an optional block argument.
Find it much clearer and more logical solution, not superfluous polluting of API space.
`Object#itself` just returns target object, optional block would return alternative value with target object passed as block argument.
Prototyped sol. in Ruby:
~~~ruby
class Object
def itself
block_given? ? yield(self) : self
end
end
~~~
Not aware of any case, where it would break backward compatibility.
--
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>