ruby_frame in 1.8 is what in 1.9?

[Jason Roelofs]

[Note: parts of this message were removed to make it a legal post.]

So I have some C++ extension code that nicely uses ruby_frame->orig_func and
ruby_frame->self to figure out the current status of the VM at a given
method call. Trying to port this to 1.9 is running into some issues, mainly
that I can't find a replacement for ruby_frame->self. I've found
rb_frame_callee() to replace ruby_frame->orig_func but cannot find out how
to get access to the current Ruby "self" object for the call.

Jason

 

[Roger Pack]

So I have some C++ extension code that nicely uses ruby_frame->orig_func
and
ruby_frame->self to figure out the current status of the VM at a given
method call. Trying to port this to 1.9 is running into some issues,

Maybe you could find some insight by examining how ruby-debug was ported
to 1.9
=r
http://github.com/mark-moseley/ruby-debug/tree/master

 

[Mark Moseley]

So I have some C++ extension code that nicely uses ruby_frame->orig_func
and
ruby_frame->self to figure out the current status of the VM at a given
method call. Trying to port this to 1.9 is running into some issues,
mainly
that I can't find a replacement for ruby_frame->self. I've found
rb_frame_callee() to replace ruby_frame->orig_func but cannot find out
how
to get access to the current Ruby "self" object for the call.

Jason

My best guess: try GET_THREAD()->cfp->self. That's probably not going to
work, because the variables inside the frame are all different. I'd have
to see what you need to do with the "self" object.

 

[Jason Roelofs]

[Note: parts of this message were removed to make it a legal post.]

My best guess: try GET_THREAD()->cfp->self. That's probably not going to
work, because the variables inside the frame are all different. I'd have
to see what you need to do with the "self" object.

I'll take a look at ruby_debug for sure, but for more information, here's
what I'm up against:

http://github.com/jameskilton/rice/blob/master/rice/Director.cpp

With tests to show example usage:

http://github.com/jameskilton/rice/blob/master/test/test_Director.cpp

If you're familiar with SWIG's %director, this is what I've got. This class
gets subclassed and helps define an intermediary between C++ and Ruby to
allow polymorphism and super calls to work seemlessly across the two
languages. What's there works great for 1.8, and it's best shown how it
works in the test:

int process(int num) {
if(callIsFromRuby("process")) {
raisePureVirtual();
} else {
return from_ruby<int>( getSelf().call("process", num) );
}
}

So for 1.9 I need to figure out the current self object of the frame,
along with the name of the function currently being called, aka, how
do I port this line of code to work with 1.9?

return (getSelf().value() == ruby_frame->self) && (
rb_id2name(ruby_frame->orig_func) != methodName );

Thanks.

Jason

 

[Mark Moseley]

Oh, it's just a test for equality. Try what I suggested; it might work.

 

[Jason Roelofs]

[Note: parts of this message were removed to make it a legal post.]

Oh, it's just a test for equality. Try what I suggested; it might work.

I will, once I can get this thing built. What is the deal with Ruby 1.9.1 /
1.9.2 no longer including certain header files in the install? Files like
node.h and vm_core.h, which I need for GET_THREAD, are unavailable in an
installed Ruby. The requirements for building ruby-debug for 1.9 require you
having the ruby source on your system somewhere:
http://wiki.github.com/mark-moseley/ruby-debug

yuck! What is up with this and can we get this decision reversed? Or is
there another way around this?

Jason

 

[Mark Moseley]

yuck! What is up with this and can we get this decision reversed? Or is
there another way around this?

Jason

Roger's opened up a ticket on it. Hopefully the core team will fix.
Until then, you'll need to download the entire release.

Mark

 

[Roger Pack]

I will, once I can get this thing built. What is the deal with Ruby

1.9.1 /
1.9.2 no longer including certain header files in the install?

yuck! What is up with this and can we get this decision reversed? Or is
there another way around this?

One option would be to create a "ruby sources" gem that includes the
*.h, *.inc files from "each known patch number" of ruby.
a la
require 'ruby_sources'
RubySources.source_directory_for_current_ruby # =>
'/lib/gems/ruby_sources/include/ruby-1.9.1-p129' or what not

Then the question becomes "should said gem include the full source or
just the headers"? [it probably wouldn't hurt much at all to include the
full sources--disk space is cheap, right?].
Thoughts?
=r

 

[Jason Roelofs]

[Note: parts of this message were removed to make it a legal post.]

I will, once I can get this thing built. What is the deal with Ruby
1.9.1 /
1.9.2 no longer including certain header files in the install?

yuck! What is up with this and can we get this decision reversed? Or is
there another way around this?

One option would be to create a "ruby sources" gem that includes the
*.h, *.inc files from "each known patch number" of ruby.
a la
require 'ruby_sources'
RubySources.source_directory_for_current_ruby # =>
'/lib/gems/ruby_sources/include/ruby-1.9.1-p129' or what not

Then the question becomes "should said gem include the full source or
just the headers"? [it probably wouldn't hurt much at all to include the
full sources--disk space is cheap, right?].
Thoughts?
=r

I like the idea for sure, though I doubt we need the entire source, just all
the headers would suffice. And going with other *nix tools, while having a
call in ruby would be nice, I'd also put together a command-line tool like:

/usr/bin/ruby_includes [--for=version_string] where version_string are
things like "1.9.1" "1.9.2" and probably need "1.9.2p[patch]" depending on
if headers change for a patch level.

I wonder how these kind of libraries are handled in other languages like
Python or Perl, if they also have to build work-arounds or if internals of
the language are readily available.

Jason

 

[Roger Pack]

/usr/bin/ruby_includes [--for=version_string] where version_string

are
things like "1.9.1" "1.9.2" and probably need "1.9.2p[patch]" depending
on
if headers change for a patch level.

An excellent idea. I'll probably work on a gem for it saturday [or if
another interested party wants to start working on it, I can fork
whatever exists at that point].
Just want to be able to do a painless "gem install ruby-debug" for 1.9


A further elaboration of the project [should anyone ever require it]
would be to auto-download headers for unknown patch numbers, like "oh
they are 1.9.2 patch 143 I'll see if I can download
ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p143.tar.gz and extract
it locally."

That would make for a somewhat long gem install, though. Maybe we
should stick with hard-coded patch numbers for now

=r

 

[Jason Roelofs]

[Note: parts of this message were removed to make it a legal post.]

/usr/bin/ruby_includes [--for=version_string] where version_string
are
things like "1.9.1" "1.9.2" and probably need "1.9.2p[patch]" depending
on
if headers change for a patch level.

An excellent idea. I'll probably work on a gem for it saturday [or if
another interested party wants to start working on it, I can fork
whatever exists at that point].
Just want to be able to do a painless "gem install ruby-debug" for 1.9


A further elaboration of the project [should anyone ever require it]
would be to auto-download headers for unknown patch numbers, like "oh
they are 1.9.2 patch 143 I'll see if I can download
ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p143.tar.gz and extract
it locally."

That would make for a somewhat long gem install, though. Maybe we
should stick with hard-coded patch numbers for now

=r

I'm think that to start it does hard coding and with a fallback so that
(e.g.) 1.9.2p143 falls back to 1.9.2p98 if p143 isn't in the gem yet.

Yeah, I like this idea. Should probably be called ruby_includes or
ruby_headers for clarity's sake. I'm jameskilton on github incase I get
around to making the repo before you do.

Jason