next erroneously behaves like step [MRI 2.0]

[FND]

for a few weeks now - quite possibly since switching to Ruby 2.0 - next has been behaving like step, which is obviously rather annoying

minimal test case:

$ cat Gemfile
source :rubygems

gem 'pry'
gem 'pry-debugger'

$ cat foo.rb
def foo
  require 'pry'; binding.pry
  puts "FOO"
  bar
  baz
end

def bar
  puts "BAR"
end

def baz
  puts "BAZ"
end

foo

$ bundle exec ruby foo.rb

using next there steps into both bar and baz - I'd expect it to step over those and remain inside foo though

(tested with pry v0.9.12.1 and pry-debugger v0.2.2 on Ruby v2.0.0p0)

[nixme]

Yes, it's a debugger issue with MRI 2.0.0p0: cldwalker/debugger#47

Once fixed upstream, pry-debugger should work as expected.

[deivid-rodriguez]

In the meantime, you can use byebug & pry-byebug, which I created specifically to overcome debugger's problems with ruby 2.0 (like this one).

[wdiechmann]

My rbenv version says 2.0.0-p247 and my Gemfile has jazz_hands which is why I opted for adding your pry-byebug (missing the correct action of the next and step) – but even though the debugger stops at my binding.pry's, it does not do what I would like it to (or the step and next concepts are different in the debugger and what I'm used to)

So - if for instance I start bundle exec guard with my Rails project and touch wage_event.rb, the wage_test.rb is performed and with added binding.pry's here is what happens

example:

    152: def add_wage_items
    153:   wi=[]
    154:   d=wage_period.from_at.dup
    155:   while d<= wage_period.to_at do
    156:     wi[d.day]={}
    157:     work_schedules[d.day].each do |event|
    158:       # next if Entrance::WORK_HOUR_CATEGORIES.flatten.include? event.category_id
    159:       binding.pry
=>  160:       add_wage_item_depending_on_event_category d.day, wi, event
    161:     end
    162:     d+=1.day
    163:   end
    164:   self.wage_items=wi
    165: end

[1] pry(#<Wage>)> n

From: /RailsProjects/wage.4.0/app/models/wage.rb @ line 168 Wage#add_wage_item_depending_on_event_category:

    167: def add_wage_item_depending_on_event_category day, day_values, event
 => 168:   day_values[day][event.category_id] ||= 0

In the example I would have expected the debugger to stop at 162 (if the array was exhausted) or 159 otherwise

If on the other hand I start rails console and call Wage.first.calculate here is what happens

From: /RailsProjects/wage.4.0/app/models/wage.rb @ line 159 Wage#add_wage_items:

    152: def add_wage_items
    153:   wi=[]
    154:   d=wage_period.from_at.dup
    155:   while d<= wage_period.to_at do
    156:     wi[d.day]={}
    157:     work_schedules[d.day].each do |event|
    158:       # next if Entrance::WORK_HOUR_CATEGORIES.flatten.include? event.category_id
 => 159:       binding.pry
    160:       add_wage_item_depending_on_event_category d.day, wi, event
    161:     end
    162:     d+=1.day
    163:   end
    164:   self.wage_items=wi
    165: end

[1] oxen40(#<Wage>) »  n

From: /Users/walther/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/pry-byebug-1.2.0/lib/pry-byebug/processor.rb @ line 20 PryByebug::Processor#run:

    15:     def run(initial = true, &block)
    16:       return_value = nil
    17: 
    18:       command = catch(:breakout_nav) do  # Throws from PryByebug::Commands
    19:         return_value = yield
 => 20:         {}    # Nothing thrown == no navigational command
    21:       end
    22: 
    23:       times = (command[:times] || 1).to_i   # Command argument
    24:       times = 1 if times <= 0
    25: 

[2] oxen40(#<PryByebug::Processor>) »  

• which is even further away from what I would have expected :(

If I can be of any help please let me know - the pry eco-system is a wonderful addition to Ruby, and thank you so much for sharing!!

[palexvs]

+1 I have the same issue on Ruby 2.0.0-p247 & Rails4

[jmuheim]

+1

[ariabov]

+1 on 2.0.0-p353

[jmuheim]

No progress on this? I can't remember this ever been working, and I'm using pry for more than a year now.

[banister]

@jmuheim use pry-byebug instead, it's a 2.0 version of pry-debugger. Basically there was large API changes from 1.9.3 -> 2.0, and pry-byebug supports the new APIs.

[jmuheim]

Thanks, I will consider this.