[#90865] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been reported by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90877] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been updated by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90895] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
4 messages
2019/01/05
[#90896] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707))
— Takashi Kokubun <takashikkbn@...>
2019/01/05
VGhhbmtzIHRvIGV4cGxhaW4gdGhhdC4KCj4gSSBzdXNwZWN0IHRoZXJlIGlzIGFub3RoZXIgdGhy
[#91154] Testing MJIT on RHEL 7.5 — Phil Edelbrock <edelbrp@...>
4 messages
2019/01/18
[#91159] Re: Testing MJIT on RHEL 7.5
— Takashi Kokubun <takashikkbn@...>
2019/01/18
SGksCgo+IHRpbWUgL3Vzci9sb2NhbC9ydWJ5LWVkZ2UvYmluL3J1YnkgLS1kaXNhYmxlLWdlbXMg
[#91200] [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout — glass.saga@...
Issue #15553 has been reported by Glass_saga (Masaki Matsushita).
4 messages
2019/01/21
[#91289] Re: [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout
— Eric Wong <normalperson@...>
2019/01/26
glass.saga@gmail.com wrote:
[ruby-core:91114] [Ruby trunk Bug#15539] Proc.new with no block shouldn't always warn
From:
merch-redmine@...
Date:
2019-01-16 01:33:55 UTC
List:
ruby-core #91114
Issue #15539 has been updated by jeremyevans0 (Jeremy Evans).
ko1 (Koichi Sasada) wrote:
> I'll file the reason soon.
>
> Anyway, I recommend you to rewrite it with a block parameter:
>
> ```
> def foo bar = nil, &b
> (b || bar).call
> end
I also ran into this issue as `Proc.new` was used in a few places in Sequel. Removing implicit block support for `Proc.new` makes it no longer possible to have a default value for a positional argument that uses the block, since the block argument variable is not set until after default values for positional arguments (e.g. https://github.com/jeremyevans/sequel/commit/34faf32c6eddc02d1499748a431f3fdf46bfc5a4#diff-29540b6b617d51d3f5356b1cdfc534b0L61). I feel the loss of functionality is acceptable, since `Proc.new`'s implicit block support was fairly magical and not widely known/used.
----------------------------------------
Bug #15539: Proc.new with no block shouldn't always warn
https://bugs.ruby-lang.org/issues/15539#change-76348
* Author: tenderlovemaking (Aaron Patterson)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v:
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
Hi,
r66772 introduced a warning for the following code:
``` ruby
def foo bar = Proc.new
bar.call
end
foo { p "block" } # warn
foo ->() { p "block" } # no warn
```
I don't think this case of `Proc.new` should warn. To eliminate warnings, I have to rewrite as:
``` ruby
def foo bar = nil
if bar
bar.call
else
yield
end
end
```
Rails uses this "Proc.new" trick here:
* https://github.com/rails/rails/blob/a08827a90b5a9be79379019cf5b242bd7236d2e3/actionpack/lib/action_controller/metal.rb#L29
* https://github.com/rails/rails/blob/a08827a90b5a9be79379019cf5b242bd7236d2e3/actionpack/lib/action_dispatch/middleware/stack.rb#L100
* https://github.com/rails/rails/blob/a08827a90b5a9be79379019cf5b242bd7236d2e3/activerecord/lib/active_record/statement_cache.rb#L116
* https://github.com/rails/rails/blob/a08827a90b5a9be79379019cf5b242bd7236d2e3/activesupport/lib/active_support/notifications/fanout.rb#L21
I can change Rails, but I want to know why and I don't see any discussion of r66772 (the commit doesn't have a feature number).
Thanks!
--
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>