Assistance wanted for integrating existing C-API into Ruby

ruby-talk
1

Hello,

I am seeking assistance for writing a ruby wrapper for the c-api of an
existing enterprise system. This job is a paid job.

In my vision the access from ruby/rails to this existing system should
be like working with active record.
Basically I think there should be a ruby layer to make the c-api
accessible and another that integrates it with Active Record. I think
this makes sense because my main focus is to access the data of the
enterprise system.

For the first layer I can imagine to use SWIG (this seems to be a good
way to integrate a c-api from ruby; but if you know a better way just
tell me) and for the second part one has to write an active record
adapter.

So I am searching someone who has the experience and knowledge to get
such a job done (at least the part to create the ruby wrapper around
the c-api). The first step would be to create a working prototype
within the next two months.

Feurio

2

Feurio wrote:

Hello,

I am seeking assistance for writing a ruby wrapper for the c-api of an
existing enterprise system. This job is a paid job.

In my vision the access from ruby/rails to this existing system should
be like working with active record.
Basically I think there should be a ruby layer to make the c-api
accessible and another that integrates it with Active Record. I think
this makes sense because my main focus is to access the data of the
enterprise system.

For the first layer I can imagine to use SWIG (this seems to be a good
way to integrate a c-api from ruby; but if you know a better way just
tell me) and for the second part one has to write an active record
adapter.

So I am searching someone who has the experience and knowledge to get
such a job done (at least the part to create the ruby wrapper around
the c-api). The first step would be to create a working prototype
within the next two months.

Feurio

I'm not looking for a paid job, but I've had a little experience with Ruby and SWIG. For pure C code, it's pretty much a matter of downloading and installing the latest SWIG (development status, but very high quality, excellent docs and a very friendly developer team), and then writing a "module" file for each C function you want to wrap.

C++ is much different -- you need to know a lot more about what the code you want to wrap is doing. But the SWIG manual has a very well written section on the details of the Ruby/C++ interface.

One other note: SWIG tries very hard to generate portable wrappers. That is, if you have a "module" descriptor, you can interface your C functions to Perl, Python, PHP, Lua and Tcl in addition to Ruby. If at all possible, don't do anything that locks you into Ruby or locks you out of other scripting languages. You never know when someone is going to come along and "ask" you to support their "favorite" scripting language.

3

if the api is simple, or even moderately simple, you may be able to wrap it
this afternoon using ruby/dl - which allows one to call c functions
__directly__ from ruby without any glue (swig) code.

here's an example which calls atoi(3):

     harp:~ > cat a.rb
     require "dl/import"
     require "dl/struct"

     module LIBC
       extend DL::Importable
       begin
         dlload "libc.so.6"
       rescue
         dlload "libc.so.5"
       end
       extern "int atoi(char*)"
     end

     p LIBC.atoi("42")

     harp:~ > ruby a.rb
     42

if you take this approach you'd probably be best off doing something like

   one_to_one_mapping_of_c_to_ruby = Module.new{

···

On Thu, 21 Sep 2006, Feurio wrote:

Hello,

I am seeking assistance for writing a ruby wrapper for the c-api of an
existing enterprise system. This job is a paid job.

In my vision the access from ruby/rails to this existing system should be
like working with active record. Basically I think there should be a ruby
layer to make the c-api accessible and another that integrates it with
Active Record. I think this makes sense because my main focus is to access
the data of the enterprise system.

For the first layer I can imagine to use SWIG (this seems to be a good way
to integrate a c-api from ruby; but if you know a better way just tell me)

     #
     # as the example above
     #
   }.unit_test!

then

   high_level_interface = Module.new{
     #
     # use one_to_one_mapping_of_c_to_ruby to provide high level functions
     #
   }.unit_test!

swig is a fine peice of software but, sometimes, there's no need to actually
write/generate an extension.

kind regards.

-a
--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei

4

So I am searching someone who has the experience and knowledge to get
such a job done (at least the part to create the ruby wrapper around
the c-api). The first step would be to create a working prototype
within the next two months.

Have you got my mail?

5

I am seeking assistance for writing a ruby wrapper for the c-api of an
existing enterprise system. This job is a paid job.

For the first layer I can imagine to use SWIG (this seems to be a good
way to integrate a c-api from ruby; but if you know a better way just
tell me)

I don't advice to use SWIG because You high level ruby logic will be
linked with low level C logic. Best choice is to describe methods
yourself.

6

Макс Лапшин wrote:

>
>
> So I am searching someone who has the experience and knowledge to get
> such a job done (at least the part to create the ruby wrapper around
> the c-api). The first step would be to create a working prototype
> within the next two months.

Have you got my mail?

Hello Макс,

I have received your email and will respond to it soon...

Thanks.

Feurio

7

Max Lapshin wrote:

I am seeking assistance for writing a ruby wrapper for the c-api of an
existing enterprise system. This job is a paid job.

For the first layer I can imagine to use SWIG (this seems to be a good
way to integrate a c-api from ruby; but if you know a better way just
tell me)

I don't advice to use SWIG because You high level ruby logic will be
linked with low level C logic. Best choice is to describe methods
yourself.

Well ... first of all, the original poster said he was open to approaches other than SWIG, so take what I say as personal preferences. In my application domain, scientific and statistical computing, there are at least three popular scripting languages -- Perl, Python and Ruby -- and PHP is branching out from it's "home base" of dynamic web sites. SWIG for the most part allows the user to interface with all of them at the "cost" of some extra lines in makefiles!

When I wander about the web, I see vast projects, like Sage, for example, that focus on one scripting language, in this case Python. And I also see *dozens* of high-quality math packages in either C or C++. What SWIG gives the developers of these packages is the ability to expand their market to Perl, Python, Ruby, PHP, Lua, Pike, Tcl, Scheme, and a few others.

And it gives the users of the scripting languages the ability to stick with their favorite scripting language. Again, to use the example of Sage, it's a very useful and wonderful environment, but I already know Perl, I'm learning Scheme and Ruby and I don't want to learn Python just to use Sage!

So I'm personally a big fan of SWIG, because I think it's a big win for a lot of people, and because it's a very high quality effort. I think of it as the "automatic transmission" of scientific and statistical computing.

8

I don't advice to use SWIG because You high level ruby logic will be
linked with low level C logic. Best choice is to describe methods
yourself.

<snip>

So I'm personally a big fan of SWIG, because I think it's a big win for a
lot of people, and because it's a very high quality effort. I think of it as
the "automatic transmission" of scientific and statistical computing.

indeed. it's worth pointing out, too, that any method of wrapping c, whether
manual or automatic, should really be considered just that: wrapping. so
whether one has

   class CMethods
     include ManualMethods
   end

   class CMethods
     include SwigMethods
   end

it's assumed that one will follow with

   class RubyMethods
     include CMethods

···

On Fri, 22 Sep 2006, M. Edward (Ed) Borasky wrote:

     #
     # build up high-level api
     #
   end

so that the idea that the glue should affect the logic is really only
applicable if one stops at the glue.

cheers.

-a
--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei

9

When I wander about the web, I see vast projects, like Sage, for example, that focus on one scripting language, in this case Python. And I also see *dozens* of high-quality math packages in either C or C++. What SWIG gives the developers of these packages is the ability to expand their market to Perl, Python, Ruby, PHP, Lua, Pike, Tcl, Scheme, and a few others.

Hm.. It is very interesting. I haven't thought about this pro of SWIG. I don't like SWIG because of some problems, but You have pointed at a very important advantage.

10

<snip>

When I wander about the web, I see vast projects, like Sage, for
example, that focus on one scripting language, in this case Python. And
I also see *dozens* of high-quality math packages in either C or C++.
What SWIG gives the developers of these packages is the ability to
expand their market to Perl, Python, Ruby, PHP, Lua, Pike, Tcl, Scheme,
and a few others.

And it gives the users of the scripting languages the ability to stick
with their favorite scripting language. Again, to use the example of
Sage, it's a very useful and wonderful environment, but I already know
Perl, I'm learning Scheme and Ruby and I don't want to learn Python just
to use Sage!

So I'm personally a big fan of SWIG, because I think it's a big win for
a lot of people, and because it's a very high quality effort. I think of
it as the "automatic transmission" of scientific and statistical computing.

I'm guilty of doing this myself with Ferret. There is approximately
50,000 lines of very fast search library code there and it's only
available in Ruby. I certainly considered using SWIG but there were
several reasons I chose not to.

Firstly, writing the bindings in C gave me greater control over the
ruby API. I guess I could have wrapped the SWIG generated API in
another layer of Ruby to get it just right. I'm not sure how much work
that would have saved me.

Secondly and more importantly, SWIG is great for wrapping C structs in
Ruby classes and making the functionality available in Ruby. But going
the other way, ie. wrapping Ruby objects for use in the C code is a
little more complex. You end up writing a tonne of language specific
code in your SWIG bindings anyway so there is still a lot of work for
someone to come along and port your code to Python or Perl. Case in
point, PyLucene, although implemented with a very well written SWIG
wrapper has yet to be ported to another language so it doesn't always
work that way.

Having said all this, I couldn't agree more with Ed's comments. If you
can implement your bindings in SWIG without too many language specific
details then you should, even if you can't foresee the code ever being
used in another language.

Feurio, judging from the fact that you want to wrap your bindings in
ActiveRecord, I can't imagine they'd be too complex so SWIG would
probably be a very good fit.

Cheers,
Dave

···

On 9/22/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

11

Thanks a lot for the different answer to my original posting.

I found the post of ara.t.how...@noaa.gov quite interesting, because it
shows a very straight forward way of interfacing with c-functionality.

On the the side being able to support multiple scripting language at
once is a compelling outlook, too.

Can someone elaborate on the portability (linux, win32, etc.) of a SWIG
solution and possible performance issue, that might be connect with
SWIG?

And still, I am searching someone who can help me in getting a
prototype starting... maybe it would just be sufficient to wrap two or
three c-api calls so that I get a feeling for how to do it myself.

Feurio

12

And still, I am searching someone who can help me in getting a
prototype starting... maybe it would just be sufficient to wrap two or
three c-api calls so that I get a feeling for how to do it myself.

Being pretty much a C newbie, I found it much easier to just write an
extension from scratch rather then use SWIG. If you already know the
library you are working with, how to call it,and what header files it
needs, it's actually fairly simple to wrap a few C function calls.
Most of my time was spent figuring out the C functions I was working
with, not figuring out how to wrap them for ruby.

If you don't have the pickaxe book the following url should help.

http://www.rubycentral.com/book/ext_ruby.html

Chris

13

Feurio wrote:

Thanks a lot for the different answer to my original posting.

I found the post of ara.t.how...@noaa.gov quite interesting, because it
shows a very straight forward way of interfacing with c-functionality.

On the the side being able to support multiple scripting language at
once is a compelling outlook, too.

Can someone elaborate on the portability (linux, win32, etc.) of a SWIG
solution and possible performance issue, that might be connect with
SWIG?

And still, I am searching someone who can help me in getting a
prototype starting... maybe it would just be sufficient to wrap two or
three c-api calls so that I get a feeling for how to do it myself.

Feurio

SWIG definitely runs on Linux and Windows. It will undoubtedly run on any UNIX platform as long as the "configure" functionality can configure it, although you might need more pieces of the GNU toolchain, such as GNU make.

On Macs, here's what the SWIG web site has to say:

A highly experimental version of SWIG has been compiled using Metrowerks Code Warrior 10. Given the limited availability and experience with the Macintosh, this version of SWIG should only be used by exceptionally brave users. SWIG has not been fully tested with Python or Perl on the Macintosh although some users have reported success.

Note:SWIG-1.3.12 does support OS-X/Darwin. Simply download the Unix sources, configure, and build from the command terminal.

http://www.swig.org/compat.html