[#85349] [Ruby trunk Bug#14334] Segmentation fault after running rspec (ruby/2.5.0/erb.rb:885 / simplecov/source_file.rb:85) — pragtob@...
Issue #14334 has been updated by PragTob (Tobias Pfeiffer).
3 messages
2018/02/02
[#85358] Re: [ruby-cvs:69220] nobu:r62039 (trunk): compile.c: unnecessary freezing — Eric Wong <normalperson@...>
nobu@ruby-lang.org wrote:
5 messages
2018/02/03
[#85612] Why require autoconf 2.67+ — leam hall <leamhall@...>
Please pardon the intrusion; I am new to Ruby and like to pull the
6 messages
2018/02/17
[#85634] [Ruby trunk Bug#14494] [PATCH] tool/m4/ruby_replace_type.m4 use AC_CHECK_TYPES for HAVE_* macros — normalperson@...
Issue #14494 has been reported by normalperson (Eric Wong).
3 messages
2018/02/19
[#85674] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — matz@...
Issue #13618 has been updated by matz (Yukihiro Matsumoto).
5 messages
2018/02/20
[#85686] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/02/20
matz@ruby-lang.org wrote:
[#85704] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Koichi Sasada <ko1@...>
2018/02/21
On 2018/02/20 18:06, Eric Wong wrote:
[ruby-core:85514] [Ruby trunk Feature#14468] Add Proc#dig
From:
shevegen@...
Date:
2018-02-13 00:24:05 UTC
List:
ruby-core #85514
Issue #14468 has been updated by shevegen (Robert A. Heiler).
I am not one of the devs so this is just my own opinion.
I sort of agree with the proposal; not so much because I would
need it (my style is very awkward and I do not use procs that
often; I used them for callbacks in the past in ruby-gtk applications
but other than that, I myself rarely use procs and lambdas).
In the worst case perhaps the proposal here can be discussed (and
thus added) it can be added to the upcoming ruby developer meeting,
to get what matz thinks. In the end you only have to convince matz,
primarily. :)
The reason why I think it makes sense is because .dig was used to "dig
into the data structure", and Procs are objects too, so why not.
Hash#dig:
http://ruby-doc.org/core-2.3.0_preview1/Hash.html#method-i-dig
I think for symmetry it would make sense, which is why I agree.
(On a side note, it seems as if everyone is busy with mjit; I
noticed that in the last some days where mjit seems to be the
main focus here too. Wonder if I am the only one with that
impression; can't wait to have mjit merged in completely. :) )
Ruby developer meeting may be at:
https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20180220Japan
Perhaps if you think it should be added, someone can add it.
(I don't want to suggest it because it is your issue, not
mine, and I can not decide for you - I only wanted to
mention it, since it may be easier to get it to discuss than
perhaps wait for a bit longer afterwards, depending on how
busy the ruby core team is, e. g. see the mjit work right
now.)
----------------------------------------
Feature #14468: Add Proc#dig
https://bugs.ruby-lang.org/issues/14468#change-70304
* Author: bradleybuda (Bradley Buda)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
Since Proc already responds to [], it would be cool if Procs could participate in a recursive dig. Like this:
Current Behavior:
~~~
obj = [
0,
{
a: ->(x) { x * 2 },
b: "c"
},
]
obj[1][:a][4] == 8 # true
obj.dig(1, :a, 4) == 8 # TypeError (Proc does not have #dig method)
~~~
Desired behavior:
~~~
obj.dig(1, :a, 4) == 8 # true
~~~
I am willing to implement this but I wanted to see if the devs think it is a good idea first. If there are no objections, I'll put together a patch.
--
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>