[#55222] [ruby-trunk - Feature #8468][Feedback] Remove $SAFE — "shugo (Shugo Maeda)" <redmine@...>
20 messages
2013/06/01
[#55230] [ruby-trunk - Feature #8468] Remove $SAFE
— "spatulasnout (B Kelly)" <billk@...>
2013/06/02
[#55252] [ruby-trunk - Feature #8468] Remove $SAFE
— "spatulasnout (B Kelly)" <billk@...>
2013/06/02
[#55276] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation — Tanaka Akira <akr@...>
2013/5/31 zzak <ko1@atdot.net>:
9 messages
2013/06/03
[#55278] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/03
[#55285] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Zachary Scott <zachary@...>
2013/06/04
The original wording was:
[#55288] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/04
[#55289] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Zachary Scott <zachary@...>
2013/06/04
I fail to see the difference, please provide a patch to make it more clear.
[#55290] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/04
[#55291] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Tanaka Akira <akr@...>
2013/06/04
2013/6/4 David MacMahon <davidm@astro.berkeley.edu>:
[#55297] [ruby-trunk - Bug #8486][Open] Random segmentation fault — "manudwarf (Emmanuel Bourgerie)" <manu.dwarf@...>
4 messages
2013/06/04
[#55305] [ruby-trunk - Bug #8489][Open] Tracepoint API: B_RETURN_EVENT not triggered when "next" used — deivid (David Rodríguez) <deivid.rodriguez@...>
7 messages
2013/06/04
[#55312] [ruby-trunk - Bug #8495][Open] include/ruby/win32.h assumes that __STRICT_ANSI__ isn’t set — "now (Nikolai Weibull)" <now@...>
4 messages
2013/06/05
[#55330] [ruby-trunk - Feature #8499][Assigned] Importing Hash#slice, Hash#slice!, Hash#except, and Hash#except! from ActiveSupport — "mrkn (Kenta Murata)" <muraken@...>
30 messages
2013/06/06
[#55416] CI failures: Test IO and cleanup failures — Luis Lavena <luislavena@...>
Hello,
3 messages
2013/06/10
[#55528] [ruby-trunk - Bug #8538][Open] c method not pushed into the callstack when called, but popped when returned — deivid (David Rodríguez) <deivid.rodriguez@...>
9 messages
2013/06/17
[#55530] [ruby-trunk - Feature #8539][Open] Unbundle ext/tk — "naruse (Yui NARUSE)" <naruse@...>
10 messages
2013/06/17
[#55557] [ruby-trunk - misc #8543][Open] rb_iseq_load — "alvoskov (Alexey Voskov)" <alvoskov@...>
47 messages
2013/06/19
[#65574] [ruby-trunk - Feature #8543] rb_iseq_load
— billk@...
2014/10/09
Issue #8543 has been updated by B Kelly.
[#55578] [ruby-trunk - Feature #8553][Open] Bignum#size (and Fixnum#size) — "akr (Akira Tanaka)" <akr@...>
6 messages
2013/06/21
[#55580] [CommonRuby - Feature #8556][Open] MutexedDelegator as a trivial way to make an object thread-safe — "headius (Charles Nutter)" <headius@...>
19 messages
2013/06/21
[#55590] [ruby-trunk - Bug #8560][Open] CSV, skip_lines option causes error when passing a string — "kstevens715 (Kyle Stevens)" <kstevens715@...>
5 messages
2013/06/22
[#55638] [CommonRuby - Feature #8568][Open] Introduce RbConfig value for native word size, to avoid Fixnum#size use — "headius (Charles Nutter)" <headius@...>
18 messages
2013/06/24
[#55678] [ruby-trunk - Feature #8572][Open] Fiber should be a Enumerable — "mattn (Yasuhiro Matsumoto)" <mattn.jp@...>
13 messages
2013/06/28
[#55690] [ANN] Developer Meeting - 12-07-2013 at 23:00 UTC — Aaron Patterson <tenderlove@...>
Hi everyone!
7 messages
2013/06/28
[#55699] [ruby-trunk - Feature #8579][Open] Frozen string syntax — "charliesome (Charlie Somerville)" <charliesome@...>
20 messages
2013/06/29
[ruby-core:55520] [ruby-trunk - Bug #8341][Assigned] block_given? (and the actual block) persist between calls to a proc created from a method (using method().to_proc()).
From:
"nobu (Nobuyoshi Nakada)" <nobu@...>
Date:
2013-06-17 01:24:09 UTC
List:
ruby-core #55520
Issue #8341 has been updated by nobu (Nobuyoshi Nakada).
Status changed from Closed to Assigned
% Done changed from 100 to 0
Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN to 1.9.3: REQUIRED, 2.0.0: REQUIRED
----------------------------------------
Bug #8341: block_given? (and the actual block) persist between calls to a proc created from a method (using method().to_proc()).
https://bugs.ruby-lang.org/issues/8341#change-39982
Author: pythonesque (Joshua Yanovski)
Status: Assigned
Priority: Normal
Assignee: ktsj (Kazuki Tsujimoto)
Category: core
Target version:
ruby -v: 2.0.0-p0
Backport: 1.9.3: REQUIRED, 2.0.0: REQUIRED
Confirmed on both 2.0.0 and 1.9.2-p290. A testcase (utilizing RSpec) is attached, but the behavior is easy to demonstrate without a testcase or RSpec.
First, we define a method that can optionally accept a block.
def foo
if block_given?
yield
else
puts "No block given."
end
end
Then, we convert the method to a proc and store it in a variable.
method_to_proc = method(:foo).to_proc
Now, we try calling method_to_proc without a block, getting the expected result:
method_to_proc.call
# => No block given.
We call it again, this time with a block, and again get the expected result:
method_to_proc.call { puts "Block given." }
# => Block given.
But when we call it a third time, again with no block...
method_to_proc.call
# => Block given.
...it remembers the previous proc that was passed in.
If we then call it with a new proc, it overwrites the old proc as expected (this is not tested in the testcase, which only tests block_given?):
method_to_proc.call { puts "New block given." }
# => New block given.
The testcase verifies this behavior, and also that the behavior does not occur when calling a method in the usual way, or when using method() but not to_proc(), or when using method().to_proc() but not storing the result in the same variable (the last of which isn't that surprising but is included for completeness).
I cannot see any reason that this should be expected behavior. Either block_given? should work the same way in method.to_proc()s as it does in method()s, or it should always return false, and it certainly shouldn't "remember" the last block used.
--
http://bugs.ruby-lang.org/