Ruby_frame in 1.8 is what in 1.9?

jruyle · June 5, 2009, 3:31pm

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

jruyle · June 6, 2009, 5:57pm

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

jruyle · August 1, 2009, 3:05pm

Jason R. wrote:

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

jruyle · August 1, 2009, 8:32pm

On Sat, Aug 1, 2009 at 10:19 AM, Mark M.
[email protected]wrote:

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.

Posted via http://www.ruby-forum.com/.

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

github.com

jameskilton/rice/blob/master/rice/Director.cpp

#include "Director.hpp"

namespace Rice {

  Director::Director(Object self) {
    self_ = self;
  }

  void Director::raisePureVirtual() const {
    rb_raise(rb_eNotImpError, "Cannot call super() into a pure-virtual C++ method");
  }

}

With tests to show example usage:

github.com

jameskilton/rice/blob/master/test/test_Director.cpp

#include "unittest.hpp"
#include "rice/Director.hpp"
#include "rice/Constructor.hpp"
#include "rice/Data_Type.hpp"

#include <vector>
#include <iostream>

using namespace std;
using namespace Rice;

TESTSUITE(Director);

namespace {
  /**
   * Abstract base class
   */
  class Worker {
    public:
      virtual ~Worker() {  }

This file has been truncated. show original

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( 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

jruyle · August 1, 2009, 4:18pm

Jason R. wrote:

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.

jruyle · August 1, 2009, 8:43pm

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

jruyle · August 1, 2009, 9:23pm

Jason R. wrote:

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

jruyle · August 1, 2009, 9:07pm

On Sat, Aug 1, 2009 at 2:43 PM, Mark M. [email protected]
wrote:

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

Posted via http://www.ruby-forum.com/.

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

jruyle · August 3, 2009, 2:53pm

On Mon, Aug 3, 2009 at 8:41 AM, Roger P. [email protected]
wrote:

a la
Posted via http://www.ruby-forum.com/.

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

jruyle · August 3, 2009, 2:40pm

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

jruyle · August 3, 2009, 7:56pm

On Mon, Aug 3, 2009 at 9:39 AM, Roger P. [email protected]
wrote:

=r

Posted via http://www.ruby-forum.com/.

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

jruyle · August 3, 2009, 3:39pm

/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

Ruby_frame in 1.8 is what in 1.9?

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.

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

=r

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.