Forum: Ruby ruby_frame in 1.8 is what in 1.9?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2009-06-05 15:31
(Received via mailing list)
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
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2009-06-06 17:57
(Received via mailing list)
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
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-08-01 15:05
Jason Roelofs 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
http://github.com/mark-moseley/ruby-debug/tree/master
5ac2e22e18cae6289af4f84512439eb7?d=identicon&s=25 Mark Moseley (mark-moseley)
on 2009-08-01 16:18
Jason Roelofs 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.
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2009-08-01 20:32
(Received via mailing list)
On Sat, Aug 1, 2009 at 10:19 AM, Mark Moseley
<mark@fast-software.com>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:

http://github.com/jameskilton/rice/blob/master/ric...

With tests to show example usage:

http://github.com/jameskilton/rice/blob/master/tes...

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
5ac2e22e18cae6289af4f84512439eb7?d=identicon&s=25 Mark Moseley (mark-moseley)
on 2009-08-01 20:43
Oh, it's just a test for equality. Try what I suggested; it might work.
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2009-08-01 21:07
(Received via mailing list)
On Sat, Aug 1, 2009 at 2:43 PM, Mark Moseley <mark@fast-software.com>
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
5ac2e22e18cae6289af4f84512439eb7?d=identicon&s=25 Mark Moseley (mark-moseley)
on 2009-08-01 21:23
Jason Roelofs 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
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-08-03 14:40
> 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
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2009-08-03 14:53
(Received via mailing list)
On Mon, Aug 3, 2009 at 8:41 AM, Roger Pack <rogerpack2005@gmail.com>
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
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-08-03 15:39
> /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
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2009-08-03 19:56
(Received via mailing list)
On Mon, Aug 3, 2009 at 9:39 AM, Roger Pack <rogerpack2005@gmail.com>
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
This topic is locked and can not be replied to.