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.
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.
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.
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 ?
···
le 16/10/2007 15:28, Rick DeNatale nous a dit:
On 10/16/07, Zouplaz <user@domain.invalid> wrote:
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.
What's the difference between rdebug and the debugger that ruby comes
with?
···
On Oct 16, 9:28 am, "Rick DeNatale" <rick.denat...@gmail.com> wrote:
On 10/16/07, Zouplaz <u...@domain.invalid> wrote:
> 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.
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
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.
···
On 10/18/07, Roger Pack <rogerpack2005@gmail.com> wrote:
eggman2001 wrote:
> 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.
