Ruby 2.0: Free from MRI internal source code

[ko1]

I forked https://github.com/ko1/debugger2.
debugger2 is free from MRI internal source code, from Ruby 2.0 and later. It uses only C-API.

• lacks some features
  • post-motem
  • threading
• not all test passed

I want to make pull request, but it is too big. So I rename it.
I don't know correct merging way. Now, I want to collect feedback.

Thanks,
Koichi

[ko1]

I replace ruby-debug.c using C-APIs.
However, I feel that most of pieces can be replaced using Ruby.

[cldwalker]

Koichi, thanks for your hard work on this! I'm fine with it lacking features. I will modify extconf.rb to still support ruby 1.9.x. debugger 2.0.0 will not depend on debugger-ruby_core_source, so 1.9 users will have to install that separately.

Hopefully, I'll get a chance in the next week (between work and a conference) to pull this in. Pull requests welcome in the meantime :)

[ko1]

Or separate ruby-debug (core) and UI?
Command line interface should be shared with cores (MRI 1.8, 1.9, 2.0.., JRuby, .. etc).

Users need to prepare their own core, and connect to UI modules.

[ko1]

I meant separate different gems.

[cldwalker]

Do you want to split up debugger into core and UI component gems? That requires a lot of work which I don't see in debugger2. I'm open to pulls for it. Perhaps you're looking for #59 which once merged, will add an interface layer for debugger

[ko1]

Do you want to split up debugger into core and UI component gems?

Yes.

That requires a lot of work which I don't see in debugger2. I'm open to pulls for it. Perhaps you're looking for #59 which once merged, will add an interface layer for debugger

Sorry I'm a newbe of github. what means "open to pulls"?

I see most of components, and my suggestion is to separate ruby-debug (.rb and .so) and commands.

[zzak]

I helped update the gemspec and documentation so it's easier to install and try out, see install and usage.

[cldwalker]

@ko1 Sorry for the slang ;) By "open to pulls" I mean I can accept pull requests. I'm not sure I understand why you want to split up debugger but perhaps I'll understand once I see the code.

[ko1]

Thank you for your explanation. I got it (and zzak told me the meaning before).

As I mentioned above:

However, I feel that most of pieces can be replaced using Ruby.

I want to make another version of core part in Ruby.
At that time, it is easy to switch if UI is separated.

This is one idea. And of course, keeping debugger gem in single gem is also practical option.
It depends on our development result.

[cldwalker]

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