4 posts tagged “dev”

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.

celtic@vm:~/rubyex$ echo hi > m0
Connection to vm closed.
celtic@chikai:~/Code/linux$

I've been doing a bit of dev on the Nintendo DS recently, courtesy of the M4 I purchased ages ago, on a bit of a whim. I'm glad to say I've actually gotten into it now, though.

The graphics hardware is slightly confusing, since you have to draw to two different screens, either one of which may programmatically be considered the `main' and the other the `sub' screen. You also set up different video modes for either, with tile/2D/3D/framebuffer options, though the 3D engine only operates on one screen at a time (but you can do a hackish thing to render to both). The 3D is actually very cool, since the interface mimics OpenGL's interface very closely.

It has two CPUs, an ARM7 and an ARM9. This makes coding interesting, as the ARM7 is the one which can access the majority of the hardware, and the ARM9 is the one you end up using for most of your logic [more powerful/faster/etc. maybe. it's what I was taught to do.]. Thus, IPC (interprocess communication) ends up being fairly important as you try to talk between the two CPUs and keep things synchronised. I'm using libnds as my C/C++ wrapper/library/thing to code for the DS, and it seems to make much of the IPC and setting up things like IRQs fairly straight forward, but we'll see what happens when I get down to writing wifi code or similar.

I'm starting fairly basic, with a 'reflex timer' game where circles appear and you have to hit them quickly. Top screen displays statistics for now. I'll take a screenshot when it's a bit more developed. I'm moving along fairly quickly, so hopefully things should be awesome.

I was pleasantly surprised to note that using things like the STL is fine, since it's all statically linked anyway.