1

When I call IRB from a byebug breakpoint I seem not to be in the expected context. Is this a bug or am I doing something incredibly stupid?

$ ruby -v
ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-darwin14]
$ ruby test.rb 
test

[3, 12] in test.rb
    3: 
    4:  def initialize
    5:      @a = "test"
    6:      puts @a
    7:      byebug
=>  8:      puts @a
    9:  end
   10: end
   11: 
   12: Test.new
(byebug) irb
2.2.0 :001 > @a
 => nil 

I'd expect @a to be "test", but it's undefined/nil.

Matthias Winkelmann
  • 15,870
  • 7
  • 64
  • 76

2 Answers2

2

It is a bug, you should open an issue in Byebug's issue tracker if you want it fixed or at least studied.

deivid
  • 4,808
  • 2
  • 33
  • 38
0

Don't call irb, you can use the byebug prompt in the same way as you'd use IRB.

Lesleh
  • 1,665
  • 15
  • 24
  • It's not completely equivalent (it can't deal with multiple lines of code) but it does solve 80% of situations. – Matthias Winkelmann Mar 08 '15 at 15:12
  • @MattW. I agree, the multiple lines of code is such an important feature that byebug seems to be missing. I feel stuck when I can't paste new methods or multi-line condition statements. Did you ever figure out a workaround? – ndbroadbent Oct 12 '17 at 12:56
  • @ndbroadbent: Try pry: ```require 'pry'; binding.pry; / then run it and use $ to show the source. – Matthias Winkelmann Oct 12 '17 at 12:59
  • @MattW. Thanks, yeah I just switched to using `binding.pry`, and that's much better. Especially with the `c`, `n`, `s`, `f` shortcuts in my `~/.pryrc`. – ndbroadbent Oct 12 '17 at 13:29