Assistance wanted for integrating existing C-API into Ruby

[Feurio]

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

 

[M. Edward (Ed) Borasky]

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.

 

[ara.t.howard]

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)

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{
#
# 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

 

[Max Lapshin]

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.

 

[M. Edward (Ed) Borasky]

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.

 

[ara.t.howard]

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

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

 

[Max Lapshin]

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.

 

[Feurio]

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

I found the post of (e-mail address removed) 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

 

[snacktime]

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

 

[ÐœÐ°ÐºÑ Ð›Ð°Ð¿ÑˆÐ¸Ð½]

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?

 

[David Balmain]

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

 

[M. Edward (Ed) Borasky]

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

I found the post of (e-mail address removed) 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

 

[Feurio]

Have you got my mail?

Hello МакÑ,

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

Thanks.

Feurio