How to breakpoint ruby code ?

[Zouplaz]

Hello, I would like to know how I can have my ruby code stopped and an
irb invoqued which would allow me to have full access to the current
context.

I've tried this :

require 'rubygems'
require_gem 'ruby-breakpoint'

h2 = Hash.new
breakpoint

Two things are wrong :
1) after breakpoint the context is lost, and typing h2 gives
undefined local variable or method `h2' for #<Object:0xb7f8d9fc
@__bp_file="./test.rb", @__bp_line=21>

2) require_gem puts a warning (use gem instead), and using gem
'ruby-breakpoint' makes breakpoint command to be unknown :
undefined local variable or method `breakpoint' for main:Object (NameError)



Seems I'm on the very wrong way as I presume that
debugging/breakpointing is certainly a very common task with Ruby.


Thanks



Note : In fact, I would like something similar to the Rails console for
use with non Rails ruby code.

 

[Rick DeNatale]

Hello, I would like to know how I can have my ruby code stopped and an
irb invoqued which would allow me to have full access to the current
context.

I've tried this :

require 'rubygems'
require_gem 'ruby-breakpoint'
...
Seems I'm on the very wrong way as I presume that
debugging/breakpointing is certainly a very common task with Ruby.

There's a much better replacement for breakpoint:

http://www.datanoise.com/ruby-debug/

 

[Tim Hunter]

2) require_gem puts a warning (use gem instead), and using gem
'ruby-breakpoint' makes breakpoint command to be unknown :
undefined local variable or method `breakpoint' for main:Object
(NameError)

require_gem is obsolete and didn't do what you think it did. It was not
a synonym for "require", it was a way to specify that you want a
specific version of a gem, which is what the "gem" method does now. In
the past "require_gem" could have the side-effect of actually requiring
the gem, but the "gem" method does not have that side-effect.

To require a gem, use "require". Nothing else.

 

[Zouplaz]

le 16/10/2007 15:41, Tim Hunter nous a dit:

require_gem is obsolete and didn't do what you think it did. It was not
a synonym for "require", it was a way to specify that you want a
specific version of a gem, which is what the "gem" method does now. In
the past "require_gem" could have the side-effect of actually requiring
the gem, but the "gem" method does not have that side-effect.

To require a gem, use "require". Nothing else.

Thanks, I will stick to "require" definitely ;-)

 

[Zouplaz]

le 16/10/2007 15:28, Rick DeNatale nous a dit:

There's a much better replacement for breakpoint:

http://www.datanoise.com/ruby-debug/

Seems a good tool but unfortunately didn't worked... The 'debugger'
statement producing no effect at all.

But, I re-installed ruby-breakpoint and thanks to this article
(http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/213319) I
have been able to breakpoint again in the code by adding
require 'breakpoint185'
after
require 'breakpoint'

Without that the first require I get a message "Breakpoints are not
currently working with Ruby 1.8.5"

So, it seems to work - And my last question is :
h1 = Hash.new
@h2 = Hash.new
breakpoint

under debugger, @h2 exist but h1 does not. Quite annoying to loose the
local vars - Is it a normal behaviour for a ruby debugger ? Should have
worked like that with ruby 1.8.4 ?

 

[Zouplaz]

Here I am, quite lost but successful !

I gave ruby-debugger a second try and now everything works like a
charm. May be because I upgrade to another minor version of Ruby 1.8.5

Don't know...

 

[eggman2001]

What's the difference between rdebug and the debugger that ruby comes
with?

 

[Zouplaz]

le 16/10/2007 23:01, eggman2001 nous a dit:

What's the difference between rdebug and the debugger that ruby comes
with?

I don't know, but launching rdebug foo.rb breakpoints on the first line
of code...

 

[Roger Pack]

What's the difference between rdebug and the debugger that ruby comes
with?

the rdebug one is faster as it 'plugs itself in' to certain handles
within the interpreter (and only a few, so no watchpoints), which is
fast. The built in one is slow as molasses for whatever reason. If I
had to guess how it worked it would seem like it worked by running each
line of code and examining the state or something. Very slow.
GL.
-Roger

 

[Jano Svitok]

the rdebug one is faster as it 'plugs itself in' to certain handles
within the interpreter (and only a few, so no watchpoints), which is
fast. The built in one is slow as molasses for whatever reason. If I
had to guess how it worked it would seem like it worked by running each
line of code and examining the state or something. Very slow.
GL.

I'll guess that they use the same mechanism, set_trace_func. While the
builtin one uses a callback written in ruby, the newer uses callbacks
from the C side.