Crowley Code! 
 (Take 12)

Hacking the Ruby interpreter 2008/10/26

I like Ruby.  Ruby the language anyway.  I have started to have violent reactions to PHP's lack of closures.  However, Ruby has one deficiency that makes me almost as mad as PHP's lack of closures.  Assume for this example that the file foo.rb looks like this:

@foo = "I'm getting ready to abuse the instance variable syntax."

As is, Ruby lets me do the following, which is functionally desirable but makes the good programmer part of me twitch:

class Foo
    def initialize(path)
        self.instance_eval(File.read(path))
    end
end
f = Foo.new('load_me.rb')
f.instance_variables # => ['@foo']

Replacing the bold line with the following is what I'm after:

        load_in_scope path

In my dream, load_in_scope is a function defined in the C code that compiles a file using the Bison parser to read through the file. This saves a whole round trip to and from memory, making the program more efficient and me less twitchy.

I'm having major trouble getting the Ruby interpreter to do this. Starting with a trunk checkout and working backwards from the Kernel#load method, I've been able to segfault at least two-dozen different ways.  I think there are only two changes that are necessary.  First, after rb_load_file returns a NODE *, rb_iseq_new must turn that into an instruction sequence with a type other than ISEQ_TYPE_TOP (perhaps ISEQ_TYPE_CLASS or ISEQ_TYPE_EVAL?).  Second, the instruction sequence can't be passed to rb_iseq_eval because that calls vm_set_top_stack, so load_in_scope must call vm_set_eval_stack and vm_exec itself.

Am I insane?

Comments (0)

Richard Crowley?  Kentuckian engineer who cooks and eats in between bicycling and beering.

I blog mostly about programming and databases.  Browse by month or tag.

To blame for...


© 2009 Richard Crowley.  Managed by Bashpress.