From: Paul Brannan <pbrannan@...>
Date: 2002-07-27T04:36:46+09:00
Subject: Re: Opinion on Ruby maturity, the missing things

On Fri, Jul 26, 2002 at 07:31:20PM +0900, Paul E.C. Melis wrote:
> "Paul Brannan" <pbrannan@atdesk.com> wrote in message
> news:20020725194932.O22783@atdesk.com...
> > I'm curious about this.  I've embedded Ruby in more than a few
> > applications, and while it's not simple (I have to worry about
> > exception-safety, for example, which isn't an easy problem to begin
> > with), it's certainly not "very difficult," imo.
> 
> Can you describe what the tasks for Ruby where in these applications?

Some of these tasks were:
  1) A scriptable configuration file; Ruby can make calls into C++ code
     to set various configuration values, or the C++ code can pull these
     values from a hash.  In one case, this configuration file contains
     Ruby code that gets called at various points during the C++
     program's execution.
  2) A "guru mode" for a server; the user connects to a socket, and
     types ruby code like in irb; the code is evaluated, and may make
     calls into C++ functions.
  3) A driver for a C++ program where an extension would not work.  I
     originally tried making an extension, and the program segfaulted
     (possibly due to a global C++ object not getting properly
     initialized).  As a compromise, I added a few lines to a .cpp file,
     where the last line was ruby_run().  I now have a C++ program that
     acts like a full Ruby interpreter, but has extra "built-in"
     functions available.

> > Some questions:
> >   a) What problems come up when embedding Ruby make it "very difficult"?
> 
> As given below, lack of documentation, a not very cleanly interpreter state
> and problems with thread-safety. But I would go with lack of docs and
> examples as the main reason.

I also had problems in this area when I first started.  The pickaxe book
pointed me in the right direction, but I had to read the source to
really know what was going on.

> >   c) What do other languages (perl, python, scheme, etc.) do that make
> >      embedding them into applications easier?
> 
> Well, the language that I love most when it comes to easy embedding is Lua.
> The main reason is that the interpreter state is fully encapsulated in a
> Lua-managed block of mem. Although you need to pass the pointer to this
> state for _every_ API call you do, there are no globals anywere and it makes
> it a breeze to create another Lua-interpreter in memory. The two states
> won't bite each other because you always explicitly pass the interpreter
> state you're working with.

This is definitely a problem with Matz's implementation of Ruby.
Hopefully Rite (Ruby 2.0) will fix this problem.

> And I'm also not sure Ruby is ready for a threaded environment yet.
> 
> >   d) What else could Ruby do to make this task easier?  Would a library
> >      help?
> 
> Can you be a bit more specific on what kind of library and what it would do?

A library that is:
  a) Well-documented
  b) Has useful functions for writing applications with Ruby embedded
     that make the job easier (maybe a one-liner that starts an
     interpreter, for example).
  c) Properly initializes Ruby for the user, so that the user cannot
     make the mistake of leaving out calls to key functions, such as
     rb_init_loadpath().

I'm just brainstorming here; I don't really have a clear idea of what
this library would look like or how it would be used.

> >   e) Has the author of this comment tried using SWIG?  Did it make his
> >      job easier or harder?
> 
> Use SWIG to do what? Generate interface definitions of my own programs?
> That's not very useful is it, I want to embed Ruby in _my_ stuff, there is
> no need for it to know anything the particular application I'm writing. The
> Ruby API in the headers should be all that is necessary to do embedding.

Often, it's useful for Ruby to be able to call into C/C++ code, and not
just vice-versa.  Imagine using Ruby to script a Gimp plug-in; having
access to the Gimp's entire set of image manipulation functions would be
very useful.

Paul