officially support ruby 2.X

[cldwalker]

I do not forsee spending anytime on this in the near future. Any pull requests to help make this happen would be greatly appreciated by the ruby community.
#68 gets 2.0.0 partially working but the test suite does not work. I will not consider 2.0.0 officially supported or close this ticket until tests are passing. Here is what I see when I run tests:

$ rake
** Invoke default (first_time)
** Invoke test (first_time)
** Execute test
/Users/me/Developer/.rbenv/versions/2.0.0-p0/bin/ruby -I"lib" -I"/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib" "/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/rake_test_loader.rb" "test/breakpoints_test.rb" "test/conditions_test.rb" "test/continue_test.rb" "test/display_test.rb" "test/edit_test.rb" "test/eval_test.rb" "test/finish_test.rb" "test/frame_test.rb" "test/help_test.rb" "test/info_test.rb" "test/irb_test.rb" "test/jump_test.rb" "test/kill_test.rb" "test/list_test.rb" "test/method_test.rb" "test/post_mortem_test.rb" "test/quit_test.rb" "test/reload_test.rb" "test/restart_test.rb" "test/save_test.rb" "test/set_test.rb" "test/show_test.rb" "test/source_test.rb" "test/stepping_test.rb" "test/thread_test.rb" "test/tmate_test.rb" "test/trace_test.rb" "test/variables_test.rb" 
/Users/me/code/gems/debugger/lib/ruby_debug.bundle: warning: already initialized constant Debugger::VERSION
/Users/me/code/gems/debugger/lib/debugger/version.rb:4: warning: previous definition of VERSION was here
Run options: --seed 21745

# Running tests:

................................................................S.....dyld: lazy symbol binding failed: Symbol not found: _rb_vm_get_sourceline
  Referenced from: /Users/me/code/gems/debugger/lib/ruby_debug.bundle
  Expected in: flat namespace

dyld: Symbol not found: _rb_vm_get_sourceline
  Referenced from: /Users/me/code/gems/debugger/lib/ruby_debug.bundle
  Expected in: flat namespace

rake aborted!
Command failed with status (): [/Users/me/Developer/.rbenv/versions/2.0.0-...]
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/file_utils.rb:53:in `block in create_shell_runner'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/file_utils.rb:45:in `call'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/file_utils.rb:45:in `sh'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:39:in `sh'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/file_utils.rb:82:in `ruby'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:39:in `ruby'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/testtask.rb:99:in `block (2 levels) in define'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:60:in `verbose'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/testtask.rb:98:in `block in define'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
/Users/me/Developer/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
/Users/me/code/gems/debugger/bundle/ruby/2.0.0/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'

Also, a bug ticket on debuggers and ruby 2.0, https://bugs.ruby-lang.org/issues/7214, from #44

[cldwalker]

An example of failing to install in #66

[denofevil]

You might want to look at https://github.com/denofevil/debase. It's pretty minimal implementation of ruby-debug-base for 2.0 that ruby-debug-ide (used by RubyMine) gem is using to debug 2.0.0. Only methods used by ruby-debug-ide are currently implemented, but it's open for pull requests.

[bcardarella]

This might be helpful: http://www.ruby-forum.com/topic/4407089

tl;dr: the new TracePoint functionality should be used: http://www.ruby-doc.org/core-2.0/TracePoint.html

I wonder if this would make it possible to write a debugger without having to compile anything. I'll investigate.

[denofevil]

@bcardarella it it possible to write a debugger without having to compile anything. The problem is that this debugger will be slow as hell. I've implemented debase in pure ruby for the beginning, then I ran test suite from depot project measuring execution time. Here are results from my experiments:

	none	ruby-debug-base	pure-ruby debase
1	3.67	5.857	47.521
2	3.664	5.923	47.88
3	3.713	6.014	48.071
4	3.697	5.868
5	3.738	5.963
6	3.653	5.906
7	3.78	5.896
8	3.753	5.918
9	3.746	5.905
10	3.767	5.898

Times are in seconds, none represents normal run of the tests without any debugger at all.
There were no breakpoints, no catchpoints, etc. Debuggers were just capturing context info (such as file, line, binding).
Execution overhead of pure-ruby implementation is simply not acceptable

[banister]

@denofevil, isn't the reason ruby-debug was written in C primarily to access the rb_event_hook API that was only exposed in C? The new TracePoint API is just a Ruby wrapper for rb_event_hook (as far as i can tell) and should be more or less as fast as a pure C calls -- the overhead to previous pure ruby implementations was the constant and unnecessary binding creation in set_trace_func

[denofevil]

@banister, part of ruby-debug is mostly true, but remember that this event hook is executed on every ruby event. This means that it's executed multiple times per one line. I've tried running pure ruby implementation with JRuby and got quite good results (very close to ruby-debug-base-java), but for MRI it was still slow. I've done benchmarking on 2.0.0-preview2, may be performance is better with final. BTW rb_tracearg_binding is creating new binding. We can try reverting to ruby-debug/debase@1b3f8a2 and replacing set_trace_func with TracePoint to check if it's fast enough

[raykin]

+1

[konung]

+1

[banister]

For the love of god, please stop with the endless +1 s it's the most retarded meme ever to infect github!

[konung]

banister sorry - it's nothing more than a bump and a subscription to the issues - I found that github's thread watch function is not the most reliable thing in the world - doesn't always shoot an email to me unless I'm subscribed to an issue, didn't mean to irritate anyone.

[windwiny]

I am change something to compatible ruby 2.0.0-p0. https://github.com/windwiny/debugger

[asia653]

^ What he means is that he may have fixed it so that debugger now works for Ruby 2.0.0-p0.

[astratto]

I can confirm that windwiny's patch seems to make it work on Ruby 2.0.0

[asia653]

Awesome, good job windwiny.Could we get this PR'd and pushed up to rubygems?

[astratto]

@windwiny I think you should create a real Pull Request

[bcardarella]

Can I also suggest a major version bump of the gem so it is clear this is
for 2.0 only

On Friday, March 1, 2013, Edwardzyc wrote:

Awesome, good job windwiny.Could we get this PR'd and pushed up to
rubygems?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-14295845
.

---

Brian Cardarella
Principal at DockYard
Visit us: http://dockyard.com
Call us: (855) DOCK-YRD
Follow me on Twitter: http://twitter.com/bcardarella
Follow us on Twitter: http://twitter.com/DockYard

[banister]

@bcardarella afaict he's using #ifdef so it should work fine for 1.9.3 and 2.0

[Crossverse]

same as Issue #67 problem

[Goltergaul]

+1

[yonkeltron]

+1 and thanks for all of your hard work in general. If writing a poem would help move things along, lemme know and I'll bust out a haiku.

[maletor]

Would love a poem :)

Though I'm not helping...

On Tue, Mar 5, 2013 at 1:06 PM, Jonathan E. Magen
notifications@github.comwrote:

+1 and thanks for all of your hard work in general. If writing a poem
would help move things along, lemme know and I'll bust out a haiku.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-14465167
.

[cldwalker]

I've released 1.4.0 which merges #68 to partially support 2.0.0. I will not consider 2.0.0 support official until tests can run. I've updated this card's description

[Crossverse]

How to install this version?

[thenoseman]

rubygems.org took some time to update but now gem install debugger works as expected

[23tux]

+1
I just tried debugger 1.4.0 along with ruby 2.0.0p0 and Rails 3.2.12. Installation is fine, no errors with the 1.4.0 version. When I'm hooking into a controller action, the debugger is started. I can step, next, continue etc. When I start irb I can act as usual. But when quiting irb with quit or exit I still get the

(rdb:1) irb
2.0.0-p0 :001 > quit
dyld: lazy symbol binding failed: Symbol not found: _rb_vm_get_sourceline
  Referenced from: /usr/local/rvm/gems/ruby-2.0.0-p0@apono/bundler/gems/debugger-e98dc5762a48/lib/ruby_debug.bundle
  Expected in: flat namespace

dyld: Symbol not found: _rb_vm_get_sourceline
  Referenced from: /usr/local/rvm/gems/ruby-2.0.0-p0@apono/bundler/gems/debugger-e98dc5762a48/lib/ruby_debug.bundle
  Expected in: flat namespace

Trace/BPT trap: 5

error, and Rails crashes and quits. I don't know why, maybe it's a Rails related issue. Any ideas?

[deivid-rodriguez]

Nono, it's a debugger issue. That's why @cldwalker talked about "partial support" when he released this version.

[ericpromislow]

The Komodo debugger has no problem distinguishing step from next, so it's more likely the client code than this library. I didn't test the new version of rdebug though.

[ssoroka]

I don't understand. What client library? 

On Wed, Apr 10, 2013 at 1:21 PM, ericpromislow notifications@github.com
wrote:

The Komodo debugger has no problem distinguishing step from next, so it's more likely the client code than this library. I didn't test the new version of rdebug though.

Reply to this email directly or view it on GitHub:
#47 (comment)

[ericpromislow]

By "client code", I meant the code that loads this library. It could be bin/rdebug right here, or any other debugger that uses this code to get at ruby_debug.so

[ericpromislow]

koichi's fork handles exception handlers correctly, but it returns an empty hash for context_frame_locals, and seg faults elsewhere (I haven't narrowed down where). The main difference is that koichi's code maintains a list of inspected frames, which seems to avoid the reason for the crash I see in exception handlers, where we loop through control frames that contain apparent garbage.

[deivid-rodriguez]

Could someone provide a test case or a simple program for the next/step issue you are having? I would like to try it against my fork because I'm not experiencing the issue and my tests are passing. Thanks.

[ericpromislow]

I'm back to using cldwalker's ruby_debug.so, and given that I can do some things in Ruby in 2.0 that I couldn't do in 1.x, like Thread#backtrace_locations, I no longer need to call context_frame_line, and therefore no longer have that dependency on rb_vm_get_sourceline.

[bitaxis]

@deivid-rodriguez I am running Ruby 2.0.0-p0 via RVM on latest Mac OS X Lion, and tried to reproduce this bug via a simple Ruby script, but was unable to do so. So @ericpromislow might have a point about it being the client library. For me, next behaves like step when I invoke the debugger when working on Rails 2.3.13 applications.

[ssoroka]

I can reproduce it with a vanilla app:

$ ruby -v
ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.1]

2.0.0-p0 ~#$ rails new tmp_debugger
2.0.0-p0 ~#$ cd tmp_debugger/
2.0.0-p0 tmp_debugger#$ bundle install
2.0.0-p0 tmp_debugger#$ rails g controller welcome index
2.0.0-p0 tmp_debugger#$ edit app/controllers/welcome_controller.rb 

change file to:

require 'debugger'
class WelcomeController < ApplicationController
  def index
    debugger
    next_over_me
    next_over_me
  end

  def next_over_me
    [1,2,3].inject {|s,a|
      s+a
    }
  end
end

then

2.0.0-p0 tmp_debugger#$ edit Gemfile

uncomment:

gem 'debugger'

then

2.0.0-p0 tmp_debugger#$ bundle install
2.0.0-p0 tmp_debugger#$ # start server then hit http://localhost:3001/welcome/index
2.0.0-p0 tmp_debugger#$ rails s -p3001
=> Booting WEBrick

[0, 9] in /Users/steven/tmp_debugger/app/controllers/welcome_controller.rb
   1  require 'debugger'
   2  class WelcomeController < ApplicationController
   3    def index
   4      debugger
=> 5      next_over_me
   6      next_over_me
   7    end
   8  
   9    def next_over_me
(rdb:1) n
/Users/steven/tmp_debugger/app/controllers/welcome_controller.rb:10
[1,2,3].inject {|s,a|

[5, 14] in /Users/steven/tmp_debugger/app/controllers/welcome_controller.rb
   5      next_over_me
   6      next_over_me
   7    end
   8  
   9    def next_over_me
=> 10      [1,2,3].inject {|s,a|             # <------------ wtf?!
   11        s+a
   12      }
   13    end
   14  end
(rdb:1) n
/Users/steven/tmp_debugger/app/controllers/welcome_controller.rb:11
s+a

[kwerle]

Let's cut out the rails stuff:

def foo
  debugger
  next_over_me
  next_over_me
end

def next_over_me
  puts "nexted"
end

foo

#/tmp rdebug debug_test.rb

/private/tmp/debug_test.rb:1
def foo

(rdb:1) c
/private/tmp/debug_test.rb:3
next_over_me

(rdb:1) list
[-2, 7] in /private/tmp/debug_test.rb
   1  def foo
   2    debugger
=> 3    next_over_me
   4    next_over_me
   5  end
   6  
   7  def next_over_me
(rdb:1) n
/private/tmp/debug_test.rb:8
puts "nexted"

(rdb:1) list
[3, 12] in /private/tmp/debug_test.rb
   3    next_over_me
   4    next_over_me
   5  end
   6  
   7  def next_over_me
=> 8    puts "nexted"
   9  end
   10  
   11  foo

[deivid-rodriguez]

Thanks! So I can confirm this works in byebug but it doesn't work in both debugger and debugger2. I will have a look at it once debugger2 gets merged into debugger.

[kwerle]

byebug looks like a win for me. Swapping debugger out until this is fixed. On the downside, it looks like Pry depends on/uses debugger, because it remains affected.

[deivid-rodriguez]

@kwerle I would like to help with that issue but this is getting a bit off-topic, so you can open an issue at byebug and we can discuss it there if you wish. Salute.

[artemave]

+1

[iwiznia]

Confirmed that next does not work with ruby 2. Using byebug, it's working like a charm. When the patch for debugger?

[ashrocket]

Confirmed as well for me: 'next' does not work with ruby 2, performs a 'step'. Using byebug, it's working like a charm. But wishing for the canonical debugger to return ?

[jmuheim]

+1

[ariabov]

+1

[cldwalker]

Closing since I'm scoping debugger to just 1.9.2 and 1.9.3. For more see #125 (comment)