wrapping Ruby around OLD code

Discussion in 'Ruby' started by gw, Dec 31, 2004.

  1. gw

    gw Guest

    5 years ago one of our smart guys suggested we throw away our home grown "Basic" which glues our
    many software actions into a seeming whole. We had over the years created many verbs that are
    activated by special names. The "Basic" glue became more and more important and it was pointed out
    that our specialties should be the verbs NOT the "Basic". At that time Python was suggested as a
    replacement for our proprietary "Basic".

    Here it is 5 years later and our programming staff is very small and the ancientness of our "Basic"
    MUST be dealt with. I am giving some consideration to Ruby, though I *know* that Python would do
    OK. I have programmed in many languages and I now include Python as one I know well enough.

    I am initially attracted to Ruby because it promises more fewer special cases in syntax and its
    more purely object orientation. Not the least is it has not exploded (yet) to the point of being
    nearly impossible for a programmer to walk all the way round language.

    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.

    Watching eagerly for enlightenment,
    George Wyche
    CITA Systems, Inc.
    gw, Dec 31, 2004
    1. Advertisements

  2. I think the problem is not that the code you are trying to integrate is
    procedural but that it uses global variables. You might have problems with
    memory allocation and deallocation, but I guess that's the case for Python
    as well as Ruby or others.

    Although I haven't done something like this I'd say that if it's possible in
    Python it should be possible in Ruby, too. You might end up with one or
    several modules containing module methods (roughly one for each function of
    your C code, is it C?) but that sounds certainly possible.

    Another question is how easy is it to map your legacy code's data types to
    values in the host language. I cannot judge how difficult that is, partly
    because I haven't done that yet and partly because I don't know your code
    you want to integrate.

    Just my 0.02 EUR...

    Good luck!

    Robert Klemme, Dec 31, 2004
    1. Advertisements

  3. 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.
    Florian Gross, Dec 31, 2004
  4. gw

    Tim Hunter Guest

    It's hard to say how much of a chore it would be without knowing more about
    your code. In general it is easier to write Ruby extensions than it is to
    write Python extensions.

    I assume your "old" code is written in C. (If it isn't C or C++ I think
    you're out-of-luck.) I have some experience with C code from the mid-80's
    (wrote a great deal of it, inherited a great deal more). I wrote the
    RMagick extension, a Ruby binding for ImageMagick. ImageMagick is written
    in C and (although the ImageMagick code can in no way be described as
    "old") it is definitely not object-oriented. It was not particularly
    difficult to create a Ruby extension from it. The methods are generally
    very thin layers over the ImageMagick functions, just enough to convert the
    arguments from Ruby objects to C data, call the function, and convert the
    result as necessary back to a Ruby object. Ruby has a rich set of macros
    and functions to convert between Ruby objects and C data. For example, the
    NUM2DBL macro takes a Ruby Float object and produces a double. The
    rb_float_new() function does the reverse.

    Offhand I don't think the global variables will cause you problems except
    for threading issues, which you can bypass by simply not running
    multi-threaded programs.

    Read the "Extending Ruby" chapter in _Programming Ruby_. It's available
    online here: http://www.rubycentral.com/book/ext_ruby.html.

    You can also get some tips by reading the Ruby library source code files,
    like array.c or hash.c. There's also scads of other C extensions you can
    look at for guidance. Poke around on RubyForge. Also this newsgroup is full
    of infinitely-patient and scarily-smart folks always eager to answer
    questions. I know from experience.
    Tim Hunter, Jan 1, 2005
  5. I think that it could be a minor burden, but usually it should not be
    too much of a big problem. If the old code is written in Pascal or
    Delphi there is the Apollo bridge (though I'm not sure how active that
    project is nowadays, see http://www.moriq.com/apollo/index-en.html) and
    even if that fails to meet the requirements it should not be too hard to
    bridge your code to C and to Ruby from there. .NET might be a help there
    as it bridges lots of different languages (Ada, Fortran, Basic etc.) in
    case you are on Windows -- I'm not sure about how many languages Mono
    already supports.

    I'm not an expert at this area, but tasks like these seem to be possible
    in the general case.
    Florian Gross, Jan 1, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.