Wrapping Ruby around OLD code

gw wrote:

Here is my question: Embedding our OLD code into Ruby is how big a chore? A

lot of this code dates

from the late 1980's and is in NO WAY object oriented. Python seems like it

might let me get away

with embedding old code without make major complaints. Have any of you

attempted to incorporate

procedural code (tied together with global variables) into Ruby? I would

understand if

knowledgeable programmers plead with me to not sully Ruby's name by

attempting this Frankenstein.

However, I want the power of new life for our "specialty verbs" that a

modern, supported

"scripting" language would provide.

I think that's well possible, but can not say for sure -- could you post
some sample code? Oh, and are you planning to port the old code manually
to Ruby? It might be possible to automate that step.

I really would rather not get into details until someone who has attempted to
embed some "old" code responds. Our "special" verbs could even exist as separate
OS executable which write a file with relevant results which Ruby could then
read to maintain an datatype. These "special" verbs always do quite a bit of
work and the results are not typically voluminous. They often modify a separate
"picture" file. One could think of it as sculpting and transforming a
multi-image greyscale image and what is needed via Ruby is a way to keep track
of a list of variables that describe the state of that multi-image file. There
are like.... 500? such variables, some of which are arrays of basic types like
integers and reals.

I fully expect to automate the process of gluing these special verbs into ruby.
Before I do ANYTHING though (like write something in Ruby other than puts "hello
world") I am looking to see if there is a trap into which I will fall "for sure"
attempting to do this.

In the past the guys I worked with figured we could crudely wrap our old stuff
with expect. Worked pretty good. Only had to come up with maybe 5 new pieces of
code to get a passable thing. Later, at our leisure we could (if ever) integrate
the script into compiled code so it would run 10x faster. Ruby has the promise
of making that step easily done.

This weekend I guess I'll look for an example of making a hw.c whose only method
is "talk" and when activated will print "hello world" and see how hard that is
to push into Ruby (at least naively that is how this search will start).

George

gw wrote:

This weekend I guess I'll look for an example of making a hw.c whose only method is "talk" and when activated will print "hello world" and see how hard that is to push into Ruby (at least naively that is how this search will start).

Hm, via a shared object file or via a native executable? Both would be possible with Ruby, the first via Ruby/DL and the other via system().

gw wrote:

>gw wrote:
>
>> Here is my question: Embedding our OLD code into Ruby is how big a

chore? A

lot of this code dates
>> from the late 1980's and is in NO WAY object oriented. Python

seems like it

might let me get away
>> with embedding old code without make major complaints. Have any of

you

attempted to incorporate
>> procedural code (tied together with global variables) into Ruby? I

would

understand if
>> knowledgeable programmers plead with me to not sully Ruby's name

by

attempting this Frankenstein.
>> However, I want the power of new life for our "specialty verbs"

that a

modern, supported
>> "scripting" language would provide.

I assume your code base is mostly in C...??
In my experiance two issues that usually come up are
- how deepely do you want to integrate your code base with Ruby (or
what parts of your code will understand Ruby, understand only C, and
understand both).
- working with the garbage collector (especially if the existing code
is not OO).

>
>I think that's well possible, but can not say for sure -- could you

post

>some sample code? Oh, and are you planning to port the old code

manually

>to Ruby? It might be possible to automate that step.
>
I really would rather not get into details until someone who has

attempted to

embed some "old" code responds. Our "special" verbs could even exist

as separate

OS executable which write a file with relevant results which Ruby

could then

read to maintain an datatype. These "special" verbs always do quite a

bit of

work and the results are not typically voluminous. They often modify

a separate

"picture" file. One could think of it as sculpting and transforming a

multi-image greyscale image and what is needed via Ruby is a way to

keep track

of a list of variables that describe the state of that multi-image

file. There

are like.... 500? such variables, some of which are arrays of basic

types like

integers and reals.

Would you replace these arrays with Ruby arrays?
Converting between Ruby's types and those used in your existing code
can be a big deal. For example say you have a structure like the
following:

struct something {
char *text;
double *ary;
long ary_len;
/* other fields ... */
};
and you wanted wrap it. Are you going to convert 'text' into a Ruby
string when it is accessed in Ruby land or replace the field with
'VALUE text'? Similar questions will come up for 'ary'.
As you make these changes it can cause a chain reaction requiring more
and more of code base to "know ruby", especially if things aren't very
modular or your accessing struct fields directly.

When working with the GC you have to be careful that you keep a
reference the Ruby wrapper, struct RData, while you working with the
data structure being wrapped...
if you had:
struct Field {
char *name;
type_t type;
int maxlen;
/*...*/
};
and a collection of Fields representing a database table which you
wanted to make accessable from Ruby. You would have to change your
collection to be a Ruby collection, making the elements VALUE's (Field
wrappers).
Any code that stores a struct Field directly would have to be changed
(ie. struct record, struct db, etc). Code that manipulates struct
Field's would be OK (unless you change the definition of struct Field).

(...)
This weekend I guess I'll look for an example of making a hw.c whose

only method

is "talk" and when activated will print "hello world" and see how

hard that is

to push into Ruby (at least naively that is how this search will

start).

I hope you find Ruby suites your needs. I am sure it will create many
new and exciting possiblities with your project.

-Charlie

static VALUE
hello_world(int argc, VALUE *argv, VALUE k)
{
int i;
for (i=0; i<argc; i++)
rb_p(argv[i]);
return Qnil;
}
void Init_test()
{ rb_define_module_function(rb_mKernel, "hello_world", hello_world,
-1); }

If they are separate OS executables, you can glue them together easily
with ruby either via system() or %x. It doesn't sound like much of a
chore at all.

-David

Love Ruby and all that, but I.T. is all about choosing the correct
tool from the Virtual toolbox.

In this case, unless you really need what Ruby gives ( HLOOL,
supporting libs etc ) something like LUA would be a better fit. Its
very lightweight, pure ANSI C, and is designed for embeddeding and
hence has a very clean easily grokked API.

Have a look at www.lua.org

ยทยทยท

--
Into RFID? www.rfidnewsupdate.com Simple, fast, news.