From: "Paul E.C. Melis" <paul@...>
Date: 2002-07-27T05:12:17+09:00
Subject: Re: Opinion on Ruby maturity, the missing things

"Paul Brannan" <pbrannan@atdesk.com> wrote in message
news:20020726153631.A14534@atdesk.com...
> On Fri, Jul 26, 2002 at 07:31:20PM +0900, Paul E.C. Melis wrote:
> > 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.

This is _exactly_ what I was trying to accomplish some months ago. I gave up
then because of lack of docs and problems I suspected where
threading-related (not my favorite stuff to investigate). I resorted to
using plane windows .ini files  :/

>   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.

Cool stuff! Nice to see someone more persistent than me getting it done...

> > > 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.

Yup, had the same experience, not a good sign huh?

> > >   c) What do other languages (perl, python, scheme, etc.) do that make
> > >      embedding them into applications easier?
> >
> >  Snip, [Lua's state handling]
>
> This is definitely a problem with Matz's implementation of Ruby.
> Hopefully Rite (Ruby 2.0) will fix this problem.

I can't imagine it won't :-)

> > 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.

Right, kind of a higher-level lib for easy embedding. Not a bad idea...

> > >   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?
>
> Often, it's useful for Ruby to be able to call into C/C++ code, and not
> just vice-versa.

Okay, I can see how that would alleviate some of the handwork of adding the
c++-side thingies into Ruby. Hadn't considered it actually, mostly because I
haven't used SWIG.

Paul