[#88240] [Ruby trunk Feature#14759] [PATCH] set M_ARENA_MAX for glibc malloc — sam.saffron@...
Issue #14759 has been updated by sam.saffron (Sam Saffron).
3 messages
2018/08/01
[#88251] Re: [ruby-alerts:8236] failure alert on trunk@P895 (NG (r64134)) — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/08/01
[#88305] [Ruby trunk Bug#14968] [PATCH] io.c: make all pipes nonblocking by default — normalperson@...
Issue #14968 has been reported by normalperson (Eric Wong).
4 messages
2018/08/06
[#88331] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — samuel@...
Issue #13618 has been updated by ioquatix (Samuel Williams).
3 messages
2018/08/08
[#88342] [Ruby trunk Feature#14955] [PATCH] gc.c: use MADV_FREE to release most of the heap page body — ko1@...
Issue #14955 has been updated by ko1 (Koichi Sasada).
3 messages
2018/08/08
[#88433] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — ko1@...
Issue #13618 has been updated by ko1 (Koichi Sasada).
4 messages
2018/08/10
[#88467] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/08/14
[email protected] wrote:
[#88475] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — ko1@...
Issue #14937 has been updated by ko1 (Koichi Sasada).
3 messages
2018/08/14
[#88491] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test — Eric Wong <normalperson@...>
[email protected] wrote:
5 messages
2018/08/15
[#88495] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test
— Takashi Kokubun <takashikkbn@...>
2018/08/15
I see. Please remove the test if the test is unnecessary.
[#88496] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test
— Eric Wong <normalperson@...>
2018/08/15
Takashi Kokubun <[email protected]> wrote:
[#88523] [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed — eregontp@...
Issue #14999 has been updated by Eregon (Benoit Daloze).
4 messages
2018/08/17
[#88524] Re: [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed
— Eric Wong <normalperson@...>
2018/08/18
[email protected] wrote:
[#88549] [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed — eregontp@...
Issue #14999 has been updated by Eregon (Benoit Daloze).
3 messages
2018/08/19
[#88676] [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations — ko1@...
Issue #15014 has been updated by ko1 (Koichi Sasada).
5 messages
2018/08/27
[#88677] Re: [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations
— Eric Wong <normalperson@...>
2018/08/27
[email protected] wrote:
[#88678] Re: [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations
— Koichi Sasada <ko1@...>
2018/08/27
On 2018/08/27 16:16, Eric Wong wrote:
[#88716] Re: [ruby-dev:43715] [Ruby 1.9 - Bug #595] Fiber ignores ensure clause — Eric Wong <normalperson@...>
Koichi Sasada wrote:
4 messages
2018/08/29
[#88723] [Ruby trunk Bug#15041] [PATCH] cont.c: set th->root_fiber to current fiber at fork — ko1@...
Issue #15041 has been updated by ko1 (Koichi Sasada).
3 messages
2018/08/29
[#88767] [Ruby trunk Bug#15050] GC after forking with fibers crashes — ko1@...
Issue #15050 has been updated by ko1 (Koichi Sasada).
7 messages
2018/08/31
[#88769] Re: [Ruby trunk Bug#15050] GC after forking with fibers crashes
— Eric Wong <normalperson@...>
2018/08/31
Koichi Sasada <[email protected]> wrote:
[#88770] Re: [Ruby trunk Bug#15050] GC after forking with fibers crashes
— Koichi Sasada <ko1@...>
2018/08/31
[#88773] Re: [Ruby trunk Bug#15050] GC after forking with fibers crashes
— Eric Wong <normalperson@...>
2018/08/31
Koichi Sasada <[email protected]> wrote:
[#88774] Re: [ruby-alerts:8955] failure alert on trunk@P895 (NG (r64594)) — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/08/31
[ruby-core:88546] [Ruby trunk Feature#14609] `Kernel#p` without args shows the receiver
From:
shevegen@...
Date:
2018-08-18 17:59:21 UTC
List:
ruby-core #88546
Issue #14609 has been updated by shevegen (Robert A. Heiler).
I don't mind, personally. To me, the biggest improvement was
that we could omit doing:
require 'pp'
;)
Since I did that a lot in my code. (I love pp; I think I use it
more than just p)
I personally have not been using (or needing) yield_self or tap so
far, so the change would probably not be of immediate benefit to
me; but probably also not require of me to change anything either.
To the name "tapp" - that name is a bit weird. To me it reads as
if we combine "tap" and then add a "p" to it. Reminds me of a
joke proposal to condense "end" into "enddd" and such. :D
To be fair, I consider the name yield_self to be also weird :D -
but matz added an alias called "then" to it if I understand it
correctly (though the semantic confuses me a bit as well ... but
I don't really want to distract here since I don't really feel
too strongly either way; picking good names is not always easy).
On a side note, perhaps in the long run we could have something
to "experiment" with - like new or changed features in ruby that
have not been 100% approved in the sense of a name AND the associated
functionality, so we can try them out for some time, which may help
build a stronger opinion either way. (I mean this in general, not
just in regards to #p here).
It may still be best to ask matz again though. Syntax shortcuts
(syntactic sugar) has always been an area in ruby where code changes
has happened (e. g. yield_self to then, or omitting the end value
for infinite ranges and so forth).
----------------------------------------
Feature #14609: `Kernel#p` without args shows the receiver
https://bugs.ruby-lang.org/issues/14609#change-73607
* Author: ko1 (Koichi Sasada)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 2.6
----------------------------------------
# Abstract
`Kernel#p(obj)` prints obj as `inspect`ed.
How about to show the receiver if an argument is not given?
# Background
We recently introduce `yield_self` which encourages block chain.
https://zverok.github.io/blog/2018-01-24-yield_self.html
Quoted from this article, we can write method chain with blocks:
```
construct_url
.yield_self { |url| Faraday.get(url) }.body
.yield_self { |response| JSON.parse(response) }
.dig('object', 'id')
.yield_self { |id| id || '<undefined>' }
.yield_self { |id| "server:#{id}" }
```
There is a small problem at debugging.
If we want to see the middle values in method/block chain, we need to insert `tap{|e| p e}`.
With above example,
```
construct_url
.yield_self { |url| Faraday.get(url) }.body
.yield_self { |response| JSON.parse(response) }.tap{|e| p e} # debug print
.dig('object', 'id')
.yield_self { |id| id || '<undefined>' }.tap{|e| p e} # debug print
.yield_self { |id| "server:#{id}" }
```
# Proposal
`obj.p` shows same as `p(obj)`.
We can replace
`block{...}.tap{|e| p e}`
to
`block{...}.p`
For above example, we can simply add `.p` at the end of line:
```
construct_url
.yield_self { |url| Faraday.get(url) }.body
.yield_self { |response| JSON.parse(response) }.p # debug print
.dig('object', 'id')
.yield_self { |id| id || '<undefined>' }.p # debug print
.yield_self { |id| "server:#{id}" }
```
# Compatibility issue
(1) Shorthand for `nil`
This spec change can introduce compatibility issue because `p` returns `nil` and do not output anything.
That is to say, `p` is shorthand of `nil`. Some code-golfers use it.
Maybe we can ignore them :p
(2) make public method
`Kernel#p` is private method, so if we typo `obj.x` to `obj.p` (not sure how it is feasible), it will be `NoMethodError` because of visibility.
We need to change this behavior.
# Note
## Past proposal and discussion
Endoh-san proposed same idea 10+ years ago [ruby-dev:29736] in Japanese.
I think we should revisit this idea because of `yield_self` introduction.
At this thread, Matz said "simple `p` shows `p(self)`, it is not clear".
[ruby-dev:30903]
```
p
はどう動くのかとか(p selfと同じ、は変な気が)
self.p(obj)
はどうなのかとか。その辺が解決(納得)できたら、ということで。
```
English translation:
```
What the behavior of (I feel strange that it is similar to `p(self)`):
p
What happen on
self.p(obj)
```
## pp
If this proposal is accepted, we also need to change `pp` behavior.
## gems
`tapp` method is provided by gem.
https://github.com/esminc/tapp
I'd thought to propose this method into core. But I found that `p` is more shorter than `tapp`.
Disadvantage is `p` is too short and difficult to grep.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>