22 posts tagged “ruby”

So, recently I was looking around the blogosphere and I noticed Rice hit 1.0. This is quite good news, and it really looks like it makes the creation of Ruby bindings/extensions with C++ dead simple. As I paged through the documentation, I noticed the section on `embedding', and so the idea immediately struck me - how about creating new interpreters, or `toplevels' (in an OCamlish sense)?

Here's some sample code:

#include "rice/Data_Type.hpp"
#include "rice/Constructor.hpp"
#include "rice/VM.hpp"

#include <string>

using namespace Rice;

class MyBuiltin
{
  public:
    MyBuiltin(const std::string &_message = "Hello, world!"): message(_message)
    { }

    const std::string &greet() const
    {
      return message;
    }

  protected:
    std::string message;
};

int main(int argc, char **argv)
{
  Rice::VM vm(argc, argv);

  Data_Type<MyBuiltin> rb_cMyBuiltin =
      define_class<MyBuiltin>("MyBuiltin")
      .define_constructor(Constructor<MyBuiltin>())
      .define_method("greet", &MyBuiltin::greet);

  vm.run();
}

It looks mostly like two of the examples from the Rice page (http://rice.rubyforge.org/), and with good reason - I've never used Rice before. Compiling this with the recommended extconf Makefile gives a library to be `require'd by Ruby, which is no good for us: if we repeat the last step of compiling and drop `-shared' and change the output to be a binary instead, we get a normal linked executable:

celtic@sohma:~/code/rtl$ make
g++ -I. -I. -I/usr/lib/ruby/1.8/i486-linux -I. -I/var/lib/gems/1.8/gems/rice-1.0.1/ruby/lib/include -fPIC -fno-strict-aliasing -g -g -O2  -fPIC   -Wall -g -c test.cpp
g++ -shared -o test.so test.o -L"." -L"/usr/lib" -L.  -rdynamic -Wl,-export-dynamic  -L/var/lib/gems/1.8/gems/rice-1.0.1/ruby/lib/lib    -lrice -lruby1.8 -lpthread -ldl -lcrypt -lm   -lc
celtic@sohma:~/code/rtl$ g++ -o test test.o -L"." -L"/usr/lib" -L. -L/var/lib/gems/1.8/gems/rice-1.0.1/ruby/lib/lib    -lrice -lruby1.8 -lpthread -ldl -lcrypt -lm   -lc
celtic@sohma:~/code/rtl$

We also can drop -rdynamic, -Wl,-export-dynamic, as they're specific to our creating a shared object. Now, we run the resulting binary!

celtic@sohma:~/code/rtl$ ./test

Nothing. That's because it's just like the `ruby' interpreter. Perfect. :) How about we try something more constructive?

celtic@sohma:~/code/rtl$ ./test `which irb`
>> MyBuiltin
=> MyBuiltin
>> x = MyBuiltin.new
=> #<MyBuiltin:0xb7909914>
>> x.greet
=> "Hello, world!"
>>

And it works just like that.

Read instruction: CALL p (1 arg/s)
argument: STACK: pop() -- new stack size: 2
type=3
Read instruction: END
Read instruction: PUSH INTEGER_LITERALSTACK: push() -- new stack size: 3

Read instruction: TARGET_CALL_BLOCK upto (1 arg/s)
STACK: pop() -- new stack size: 2
STACK: pop() -- new stack size: 1
argument: STACK: pop() -- new stack size: 0
type=3
Read instruction: END
Read instruction: PUSH INTEGER_LITERALSTACK: push() -- new stack size: 1

Read instruction: TARGET_CALL_BLOCK upto (1 arg/s)
STACK: pop() -- new stack size: 0
STACK: pop() -- new stack size: ffffffff
argument: STACK: pop() -- new stack size: fffffffe
type=3

This is what happens when you write a VM. You get a stack with length 0xfffffffe.

RubyExは今バイトコードをアウトプットします！
Now RubyEx outputs byte-code!

celtic@sohma:~/code/linux/rubyex/translator$ cat test.rb
puts "Hi there."
a = who_knows("Joe", 42 - (9 * sin(12)))
a.each do
  el { joe {}; q {} }
end

celtic@sohma:~/code/linux/rubyex/translator$ ./parser -b < test.rb
       puts
  Hi there.
a       who_knowsJoe
*-
   
       *
      sin

                                                       
aeach

        el
    joe
    q

簡単にデバッグのために、今サンプルパーサのアウトプットはコードです！たとえば：
For easier debugging, the sample parser's output is now code! For example:

a(b(c{t}){d}).q{e{h{|a|b}}}
Program: 1 expression(s).
a(b(c {t}) {d}).q {e {h {|a| b}}}

a(b).c
Program: 1 expression(s).
  FuncCallExpr: Expr.c
    FuncCallExpr: a(arguments)
      IdentifierExpr: b

簡単！
Simple!

a(b, c).d
a(b).c
Program: 2 expression(s).
  FuncCallExpr: Expr.d
    FuncCallExpr: a(arguments)
      IdentifierExpr: b
      IdentifierExpr: c
  FuncCallExpr: a(arguments)
    FuncCallExpr: Expr.c
      IdentifierExpr: b

"a(b, c).d"は正しくパースして、"a(b).c"が間違えるの！？パーサトレースするときだ！！
"a(b, c).d" is correctly parsed, and "a(b).c" is not?! Parser trace time!!

"a(b)"でもパースのは：
Even when parsing "a(b)", we get:

Shifting token ')' ()
Entering state 53
Reducing stack by rule 9 (line 60):
   $1 = token '(' ()
   $2 = nterm expr ()
   $3 = token ')' ()
-> $$ = nterm expr ()

直すときだ。。。。
Time to fix...

Here's the problem I'm having right now:

• "a b.c" correctly parses as "a(b.c)"
• "a(b).c" also - incorrectly - parses as "a(b.c)"

Since I'm relatively a novice at building parsers (this is my first), I'll try to step through my muddled fixing of the situation. I'm looking at the output of the various parser states that bison's given me, and here, I think, is the s/r conflict that needs to be fixed: (correct me if I'm wrong)

s/r conflict

We're starting to become more useful, with the addition of block arguments. Here's a sample bit of code that parses nicely:

fictional do |exp, evaller|
  exp.split(" ").map {|p| evaller.call(p)}
end
Program: 1 expression(s).
  FuncCallExpr: fictional(arguments) { BlockExpr }
    BlockExpr: |DefListExpr| 1 expression(s).
      DefListExpr: 2 identifier(s).
        IdentifierExpr: exp
        IdentifierExpr: evaller
      FuncCallExpr: Expr.split(arguments)
        IdentifierExpr: exp
        FuncCallExpr: Expr.map(arguments) { BlockExpr }
          LiteralTypedExpr<Ss>: 
          BlockExpr: |DefListExpr| 1 expression(s).
            DefListExpr: 1 identifier(s).
              IdentifierExpr: p
            FuncCallExpr: Expr.call(arguments)
              IdentifierExpr: evaller
              IdentifierExpr: p

• We have one FuncCallExpr, calling "fictional" (no arguments are specified in the tree, if you look carefully) with a block. I should probably make it not show '(arguments)' if there are none. :)
• Follows the BlockExpr, with a DefListExpr of block arguments, and an expression.
• The DefListExpr has two identifiers: exp, evaller. These are the block arguments, hello!
• Following the DefListExpr in the output of the BlockExpr is that 1 expression(s), a FuncCallExpr.
• This FuncCallExpr is a call to the `split' method of some Expr.
• That Expr is an identifier, exp.
• Under construction.
  

celtic@sohma:~/code/linux/rubyex/translator$ ./parser
puts -3
puts - 3
Program: 2 expression(s).
  FuncCallExpr: puts(arguments)
    LiteralTypedExpr<i>: -3
  FuncCallExpr: Expr.-(arguments)
    IdentifierExpr: puts
    LiteralTypedExpr<i>: 3
celtic@sohma:~/code/linux/rubyex/translator$

正しい結果です。もっと一つの問題な場合だけあります：
It's the correct result. We've just got one more problem case remaining:

puts-3
Program: 1 expression(s).
  FuncCallExpr: puts(arguments)
    LiteralTypedExpr<i>: -3

RubyExのlexerは今"-3"が読んだらLiteralTypedExpr<int>(-3)をemitします。以前は"3.-@"、でもこうはもっと柔軟だと思う。
RubyEx's lexer is now reading "-3" and emitting LiteralTypedExpr<int>(-3). Earlier it was emitting "3.-@", but this way is probably more flexible.

celtic@sohma:~/code/linux/rubyex/translator$ make
g++ -enable-rtti -I. -c -o out/tests.o tests.cpp
g++  -o ruby out/ruby.tab.o out/lex.yy.o out/expr.o out/global.o out/main.o out/pretty.o out/tests.o
8 test(s) run, 8 test(s) succeeded.
234 assertion(s), 234 assertion(s) succeeded.
celtic@sohma:~/code/linux/rubyex/translator$

There's almost full test coverage for what's parseable so far. Blocks are also included.