3

ruby デバッガーblock_givenでのテストについて falseを返しますが、まだ実行されます。誰かがどのように実行されたかを説明できますか?.コンテキストに関連するものです(デバッガーはコンテキストを変更していますか? はいの場合、現在のコンテキストを見つける方法。

pryを使用した場合のruby​​-debug の代わりに 、block_given? trueを返します。

def test
  debugger
  if block_given?
    yield(4)
  else
    puts "ss"
  end
end
test {|el| puts "#{el}" }
4

1 に答える 1

3

これはruby-debugのバグのように見えます。具体的には、デバッガーで使用されているKernel＃binding_nです。

バグを確認するために、デバッガーの読み取り/評価/印刷ループに入る必要はありません。これは、 debugger（）呼び出しをbinding_n（0）に置き換える非対話型の例です。

require 'rubygems'; require 'ruby-debug'
Debugger.start
def test
  puts eval("block_given?", binding_n(0))
  if block_given?
    yield(4)
  else
    puts "ss"
 end
end
test {|el| puts "#{el}" }

Pryには、おそらくbinding_n（ ）ではなくRubyのbinding（）を使用しているため、この問題はありません。もちろん、それが最も信頼できます。

上記の場合、 binding（）がまさに必要なものであるため、これは明らかにここでの勝利です。しかし、Pryと同じように、現在の（または最新の）スタックフレーム以外のスタックフレームコンテキストで式を評価することはできません。

Pryとruby-debugなどのデバッガーの違いについては、 http：//banisterfiend.wordpress.com/2011/01/27/turning-irb-on-its-head-with-pry/#comment-274も参照してください。

最後に、パッチを適用したMRI1.9.2トレパニングデバッガーとRubinius1.2 -ishのrbx-trepanningの両方でこれを試したことに注意してください。

どちらも期待どおりに機能します。どちらの場合も、 binding_nと同等の処理は、Rubyランタイムの助けを借りて異なる方法で行われます。これにより、 binding_nも使用するため、バグのあるrb8-trepanningが残ります。

于 2011-12-14T06:01:31.607 に答える