update for current version

[nobu]

No description provided.

[luislavena]

Hello @mark-moseley, @nobu request correct ruby-debug behavior under Ruby 1.9.3.

This was reported as a Ruby bug:

http://redmine.ruby-lang.org/issues/5193

With the upcoming 1.9.3 release, can you take a look and let us know any possible issue?

Thank you.

/cc @cfis

[mark-moseley]

Luis, yes, I am planning to incorporate his changes once I get a moment to look at it.

As I understand it, it's specific to the Visual Studio compiler (or all non-gcc compilers?), which I'm not set up to use at the moment. Can you assist with testing?

[nobu]

No, it's for all compilers, gcc and VC at least.

[cfis]

Nobu is correct, this is for all compilers across all operating systems.

One thing I am confused about though is this branch being maintained anymore? All the recent activity has been on the JetBrains branch:

https://github.com/JetBrains/ruby-debug-base19

Are you guys working together or are these two separate efforts now? Where should this patch go?

Charlie

[mark-moseley]

I'm confused then, because I can compile 1.9.3-preview1 on Linux/gcc. What does this fix exactly?

[luislavena]

You should try ruby_1_9_3 branch instead than preview1 release

[mark-moseley]

My intention is to maintain this branch. JetBrains has some additional fixes. I haven't seen their test cases so I haven't incorporated them.

[cfis]

Got it, thanks for the info.

So the particular issue I have is that ruby-debug-base19 no longer compiles against the ruby_1_9_3 branch. The preview released did compile fine because the change in question was after that, see:

ruby/ruby@dea63e4#vm.c

The result of this change is using GetThreadPtr results in linker errors because ruby_threadptr_data_type became private, so its not exported from the ruby dll on windows (gcc or vc++). This apparently happens on debian too - see http://rubyforge.org/tracker/index.php?func=detail&aid=29222&group_id=8883&atid=34290.

Since ruby-debug uses GetThreadPtr, its cannot be compiled anymore, and thus no longer works.

[cfis]

FYI - I'm happy to test on windows and fedora...

[mark-moseley]

@nobu: using the current ruby trunk (1.9.4dev 33177), I've incorporated your changes. I also had to add your ruby_current_thread fix to linecache19. Now I'm getting the following error:

dyld: lazy symbol binding failed: Symbol not found: _rb_method_entry
Referenced from: /usr/local/ruby193/lib/ruby/gems/1.9.1/gems/ruby-debug-base19-0.11.26/lib/ruby_debug.bundle
Expected in: flat namespace

[stepheneb]

Mark,

I was going to test this with 1.9.3dev but I don't see where this is: 'ruby_current_thread fix to linecache19'

If you merge these changes into topic branches for ruby-debug and linecache19 I can easily reference them with bundler and then very easily test with applications on 1.9.3dev or 1.9.4dev

Thanks

[cfis]

Nobu/Mark, any progress on this? Happy to help if needed.

Thanks - Charlie

[mark-moseley]

@stepheneb: no need to test until I get a resolution to the rb_method_entry symbol not found issue (and whatever other unresolved externals that might come after that). I'm not going to check in changes until they are somewhat stable.

@cfis: I'm stuck until I get nobu's help on rb_method_entry issue

[cfis]

Hi Mark - Thanks for the update. I'll update the ticket on Ruby bug tracker.

[cfis]

Just being a pain and bringing this up again ... I updated the Ruby tracker ticket also.

[cfis]

Hi Mark - If you have a moment, there are some questions about why ruby-debug needs to use id2ref and ref2id on the ruby tracker ticket this issue started with. See:

http://redmine.ruby-lang.org/issues/5193

[kosaki]

Hi

We who ruby 1.9.3 release team plan to release 1.9.3-rc1 at this weekend and release 1.9.3p0 at next week. PLEASE join to ruby-core discussion and hopefully makes productive conclusion. This issue has a very little discussion time anymore.

http://redmine.ruby-lang.org/issues/5193

Thank you.

[mark-moseley]

I've merged in Nobu's changed. Updated gems (linecache19 0.5.13 and ruby-debug-base19 0.11.26) are at RubyForge, on the files section for ruby-debug19 (http://rubyforge.org/frs/?group_id=8883)

[agibralter]

Ah, very cool -- are you planning to push to rubygems.org?

[mark-moseley]

Once it's stable, yes. I'm seeing some segmentation faults in some of the regression tests.

[agibralter]

Ah.. Well I'm having great results on Ruby 1.9.3-rc1! Thank you!

[Dagnan]

Hi all.
Using linecache19, ruby-debug-base19 last versions from Github, I still get odd errors running tests from my Rails 3 app.

/path/to/home/.rvm/gems/ruby-1.9.3-rc1/bundler/gems/ruby-debug-017231853480/lib/ruby-debug-base.rb:38:in `handler': No interface loaded (RuntimeError)
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/bundler/gems/ruby-debug-017231853480/lib/ruby-debug-base.rb:46:in `at_catchpoint'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:239:in `block in require'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:225:in `block in load_dependency'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:596:in `new_constants_in'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:225:in `load_dependency'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:239:in `require'

Is it because these version are not the same as on Rubyforge?