Using rb-trepanning in MacRuby

[Isaac]

Hello fellow debugging enthusiasts,

I have recently started getting involved in MacRuby, and we currently
have a naive debugger, but we're looking to implement something more
robust for the 1.0 release.

I talked to Rocky briefly on IRC and decided to investigate how much
work it would be to get rb-trepanning to run on MacRuby. These are
the potential issues/concerns I have come across so far:

1) MacRuby doesn't support Kernel#require_relative - this doesn't seem
like a big deal.

2) MacRuby doesn't support Kernel#set_trace_func - this could be more
problematic.

3) rb-trepanning seems quite tightly coupled to the rb-threadframe
ruby 1.9.2 patches ( https://github.com/rocky/rb-threadframe ). I
wonder if there could be a minimal version of rb-trepanning than ran
on an un-patched ruby 1.9.2. The parts of rb-trepanning that depend
on the patches could then be enabled via respond_to? or similar. I
don't know how realistic this is, or how complicated it would make the
code base, but it would seem to make it much easier to get it running
on implementations like MacRuby. A similar approach could be taken to
extensions that only work in rubinius too, which would mean everything
could live within one gem. I think it would be great if we could use
one common pure ruby debugging gem across all implementations, but rb-
trepanning in its current form seems to make this more difficult than
it needs to be.

If any one has any advice or thoughts about any of these points I
would be happy to hear it.

Cheers,
Isaac

[Rocky Bernstein]

Sorry for the delayed reply. I wanted to see if others had thoughts. Here are mine (inline)...

On Sat, Dec 11, 2010 at 4:13 PM, Isaac <isaac...@gmail.com> wrote:

Hello fellow debugging enthusiasts,

I have recently started getting involved in MacRuby, and we currently
have a naive debugger, but we're looking to implement something more
robust for the 1.0 release.

I talked to Rocky briefly on IRC and decided to investigate how much
work it would be to get rb-trepanning to run on MacRuby.  These are
the potential issues/concerns I have come across so far:

1) MacRuby doesn't support Kernel#require_relative - this doesn't seem
like a big deal.

Right. But it's easy to implement it via caller see for example require_all https://rubygems.org/gems/require_all

2) MacRuby doesn't support Kernel#set_trace_func - this could be more
problematic.

Rubinius also doesn't have set_trace_func yet a lot of the trepanning code is similar between rb-trepanning and rbx-trepanning.

 

3) rb-trepanning seems quite tightly coupled to the rb-threadframe
ruby 1.9.2 patches ( https://github.com/rocky/rb-threadframe ).  I
wonder if there could be a minimal version of rb-trepanning than ran
on an un-patched ruby 1.9.2.  The parts of rb-trepanning that depend
on the patches could then be enabled via respond_to? or similar.

A little history. The first ruby debugger debug.rb was written in Ruby and required very minimal support from the runtime.

As a result, it is slow, doesn't have a lot of features and often doesn't work in the kinds of real-life settings where one has to debug in. 

For example you have to debug from the outset rather than to be able to pull in the debugger close to where you have an error.

So, yes, it is possible to make something that doesn't use rb-threadframe which is adds the run-time support that I would have hoped would have been in Ruby 1.9.2 but isn't. 

But is such a version without the additional run-time support interesting? I don't think so, but perhaps others do. 

You might get are a more flexible command set, or 15 ways indicate how to list source code. Is that interesting? Well if you are the eclipse or RubyMine, folks who already have their own front-end, then probably not.

What's probably more interesting to these folks, for example, is the ability to see or set return values of a method before the method returns. Or to be able to run the program without inordinate slowdowns. Things like this you can't do without trepanning. 

It's possible the run-time for MacRuby already provides some of the things that trepanning adds to the Ruby runtime. 

 I
don't know how realistic this is, or how complicated it would make the
code base, but it would seem to make it much easier to get it running
on implementations like MacRuby.   

A similar approach could be taken to
extensions that only work in rubinius too, which would mean everything
could live within one gem.  

The reason everything is not put in one gem is because a lot of the code that is used by a debugger is not exclusive to a debugger.  The debuggers I work on I'd like to think as a framework built up from a tool kit rather than one monolithic piece of code. (And I'm sure folks think trepanning is already too monolithic.) 

So live introspection of code which is what rb-threadframe does is useful whether you are writing a debugger or some sort of live code profiling tool. Another gem used by trepanning is called line-cache. It's goal is to be able to cache source-code lines, and be able to handle macro-processed source code that gets expanded into Ruby, like erb, or merb. So I could say that foo.rb line 5 is really foo.erb line 40. And again this might be useful in another tool such as a code-coverage program. 

 

I think it would be great if we could use
one common pure ruby debugging gem across all implementations,

 Yes, it would be great. But I've never seen this happen for any interesting case. The closest I've ever heard of such a thing is that the majority (but not all) Smalltalk implementations use the same debugger because the Smalltalk  bytecode is the same. 

but rb-
trepanning in its current form seems to make this more difficult than
it needs to be.

Feel free to make suggestions as to how to fix this!