[#87773] timer thread [was Re: [ruby-alerts:7905] failure alert on trunk-asserts@silicon-docker (NG (r63844))] — Eric Wong <normalperson@...>
> test_all <main>: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken
3 messages
2018/07/04
[#87836] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been reported by ko1 (Koichi Sasada).
5 messages
2018/07/06
[#87838] Re: [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes
— Eric Wong <normalperson@...>
2018/07/06
[email protected] wrote:
[#87842] Re: [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes
— Koichi Sasada <ko1@...>
2018/07/07
On 2018/07/06 18:47, Eric Wong wrote:
[#87847] undefined symbol: mjit_init_p — Leam Hall <leamhall@...>
I pulled Ruby trunk on 3 Jul and am now getting errors similar to the
10 messages
2018/07/07
[#87849] Re: undefined symbol: mjit_init_p
— Takashi Kokubun <takashikkbn@...>
2018/07/07
QXMgSSB0b2xkIHlvdSwgYG1ha2UgaW5zdGFsbGAgaXMgbmVlZGVkIHRvIG1ha2UgUnVieSB3b3Jr
[#87852] Re: undefined symbol: mjit_init_p
— Benoit Daloze <eregontp@...>
2018/07/07
T25lIG1vcmUgcmVhc29uIGZvciBodHRwczovL2J1Z3MucnVieS1sYW5nLm9yZy9pc3N1ZXMvMTM2
[#87986] [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt — mame@...
Issue #14915 has been updated by mame (Yusuke Endoh).
5 messages
2018/07/18
[#87987] Re: [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt
— Eric Wong <normalperson@...>
2018/07/18
[email protected] wrote:
[#88000] Re: [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt
— "Urabe, Shyouhei" <shyouhei@...>
2018/07/19
normalperson (Eric Wong) wrote:
[#88088] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — normalperson@...
Issue #14937 has been reported by normalperson (Eric Wong).
9 messages
2018/07/24
[#88104] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been updated by ko1 (Koichi Sasada).
3 messages
2018/07/25
[#88173] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — Greg.mpls@...
Issue #14950 has been reported by MSP-Greg (Greg L).
3 messages
2018/07/29
[#88189] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — nobu@...
Issue #14950 has been updated by nobu (Nobuyoshi Nakada).
3 messages
2018/07/30
[#88199] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — takashikkbn@...
Issue #14937 has been updated by k0kubun (Takashi Kokubun).
7 messages
2018/07/30
[#88213] Re: [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention
— Eric Wong <normalperson@...>
2018/07/30
[email protected] wrote:
[#88219] Re: [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention
— Eric Wong <normalperson@...>
2018/07/30
> yet, sky3 had a failure at
[#88306] Re: [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention
— Eric Wong <normalperson@...>
2018/08/06
> http://ci.rvm.jp/results/trunk@P895/1173951
[#88308] Re: [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention
— Eric Wong <normalperson@...>
2018/08/06
> > http://ci.rvm.jp/results/trunk@P895/1173951
[ruby-core:87888] [Ruby trunk Feature#14904] Make it possible to run instance_eval with zero-arguments lambda
From:
prijutme4ty@...
Date:
2018-07-09 11:32:36 UTC
List:
ruby-core #87888
Issue #14904 has been reported by prijutme4ty (Ilya Vorontsov).
----------------------------------------
Feature #14904: Make it possible to run instance_eval with zero-arguments lambda
https://bugs.ruby-lang.org/issues/14904
* Author: prijutme4ty (Ilya Vorontsov)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
At a moment #instance_eval always yields an object to a given block. Though if we passed lambda as a block for instance_eval, its work depend on number of arguments. But I see no reason for such strictness when lambda gets zero arguments. In that case instance_eval can just skip yielding receiver to its block.
It will reduce surprise for a newcomers who don't know the difference between proc and lambda.
I got to this problem with code similar to this:
```
module ConfigParams
def add_config_parameter(param_name, **kwargs, &block)
# ...
define_method(param_name){ kwargs[:default].call(self) }
end
end
class KeyBindings
extend ConfigParams
add_config_parameter :undo
add_config_parameter :redo, default: ->{ "shift+#{undo}" }
end
kb = KeyBindings.new
kb.undo = 'ctrl+z'
puts kb.redo # => shift+ctrl+z
kb.redo = 'ctrl+y'
```
I want to allow user to express defaults with lambda which will be later evaluated in the context of an instance. It's a bit more readable than:
```
add_config_parameter :redo, default: proc{ "shift+#{undo}" }
```
And anyway, it'd be good if a user preferred to change proc into lambda didn't get strange exceptions.
I've already found different solution - to use instance_exec instead of instance_eval. But I'm still sure that life could be easier it instance_eval handled zero-argument lambdas properly.
Related: #10513
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>