[Gdal-dev] Ruby Bindings Update

Sat Jun 24 03:50:35 EDT 2006

[Sorry, meant to copy this to the list the first time]

Hey Shoaib,

  > Thanks for that Charlie
  >
  > I would be interested in porting some of my python scripts that use
  > gdal into ruby so i can start trying them in Rails.

That would be great.

  >
  > Just looking through the gdalautotest/ruby, it only has OGR stuff
  > there. I wouldn't mind helping out to create the ruby gdal tests.
  >

Interesting.  Under gdalautotest/ruby, you should see two directories -
ogr and osr.  If not, then make sure you're uptodate with CVS (although
I checked in the osr stuff in January, so that's probably not it).

  > So pointers on where to start, such as the dependencies & how to run
  > the gdal tests would be most welcome. I have got gdal-1.3.2 compiled
  > with the ruby bindings

Sure.  The way I would approach this (and what I did for ogr and osr):

1. Copy the gdalautotest\gcore directory and put the copy under
gdalautotest\ruby\gcore.

2.  Open up one of the python files.

3.  I then start at the top and work my way down, translating the Python
to Ruby (its not too hard, the languages are pretty close).  The reason
I port the Python code is because its a lot easier than coming up with
my own tests - and its a good baseline to make sure both languages are
doing the same thing.

4.  When porting, follow Ruby naming schemes.  So someObject.someMethod
becomes some_object.some_method (the swig bindings translate the names
under the covers).

5.  I use Ruby's unit test framework - that means you don't have to port
the bottom of each Python file which has some custom test running code.

6.  When ported, take the new Ruby file and name it tc_xxxx where tc is
"test case"

7.  Create a ts_xxx where ts is "test suite"  Add your new test case to
the test suite.  Obviously, you need just one ts file per directory.

9.  Run the test case, see what works and what doesn't work.

As you do the port, most stuff should work.  But you will undoubtedly
run into issues with the way SWIG exposes some of the API methods.

The things to look out for:

1.  Some API methods return new objects, and Ruby must be told this.
Hopefully you won't run into any of these since there was a lot of work
getting this right in the SWIG bindings shared by all languages.  You'll
know that you've got an issue if your test cases cause segmentation
faults (these become particularly obvious when running a full test suite
which gives everything time to blow up).

2.  There is also the inverse, you pass in an object as a parameter to
an API method and it takes over ownership.  Once again, hopefully you
won't run into this.  Once again, you'll know you have if you get
segmentation faults.

3.  This one you'll run into - sometimes an API method will return
something that SWIG doesn't know how to handle for Ruby.  For example, a
method might return a C++ standard library strstream.  Of course, Ruby
hasn't a clue what to do with that so a little wrapper code needs to
generated to convert it to a string.  These are called typemaps, and
there a bunch of them in the SWIG bindings.

So, if you can port the tests and show what works and what doesn't, I
can help out with tweaking the SWIG bindings if there are any problems.
   And as you write the tests, I can add them into the autotest project
for other to use as good examples in the future.

Hope this helps - feel free to ping me with any questions.

Charlie

Shoaib Burq wrote:
> 
> thanks
> shoaib
> -- 
> http://nomad-labs.com
> 
> On 6/24/06, Charlie Savage <cfis at savagexi.com> wrote:
>> Summary
>> -----------
>>
>> I've finally had a chance to look over the Ruby bindings again.  I
>> noticed a few build issues that I wanted to run by the list, see below
>> for more info.
>>
>> Overall, the Ruby bindings seem in good shape to me for OGR and OSR.
>> There is a full set of unit tests for these modules in the gdal autotest
>> project.
>>
>> However, they are not tested, and presumably do not work, for GDAL.
>> Most likely there are a couple api calls that need a little SWIG
>> tweaking.  Anyway, I don't have plans to do this since I only need the
>> OGR part of the bindings.  So if someone wants to make a final push on
>> GDAL let me know and I can point you in the right direction.
>>
>> Onto the build issues....
>>
>>
>> Linux - Fedora Core 5, Dell Dimension machine
>> --------------------------
>>
>> Compiling and installing the bindings works fine using the standard
>> build system (./configure, make, make install).
>>
>> Issue #1 - However, you can't use them due to selinux errors:
>>
>>      Cannot restore segment prot after reloc
>>
>> This has to do with text relocations.  The solution turns out to be
>> fairly simple, add -fpic or -fPIC when building shared libraries (like
>> the Ruby bindings).
>>
>> Should I
>>
>> a) add this parameter to CFLAGS in the RubyMakefile.mk
>>
>> - or -
>>
>> b) should this be added as a global build flag?  I'd imagine all the
>> other SWIG extensions, and the gdal shared library itself, should run
>> into the same issue.
>>
>>
>> Issue #2
>>
>> Ruby 1.8.4 moved its extension library from
>> /usr/lib/site-ruby/i386-linux to /usr/lib/ruby/site-ruby/i386-linux
>>
>> No big deal, since I ask Ruby where the directory is on installation.
>> However, it turns out that on a fresh ruby install the i386-linux
>> directory doesn't exist.  So the makefile now has a check for this.
>>
>>
>> Windows - VC 2005 NET
>> --------------------------
>> Another library issue.  With VC.NET 2005 all dlls must include an
>> embedded manifest at resource id #2.  Yeah, I know, why????  Anyway,
>> more information then you'd ever want to know about this is here:
>>
>> http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm
>>
>> Here's the issue.  If you build with Visual Studio, the manifest gets
>> embedded correctly.  If you use nmake, then it doesn't and you have to
>> add it manually use mt.exe (see link above).  Once again, this is
>> another global issue that would affect any SWIG built extension.  It
>> ought to also affect gdal.dll, but that seems to work for me, don't know
>>   why.
>>
>>
>> Windows - MingW
>> --------------------------
>> Works, no issues
>>
>>
>> Os X
>> -------
>> Ken-ichi has reported that the bindings don't build on the Mac.
>> Unfortunately, I can't test that since I don't have one.  Not sure what
>> to do about that.
>>
>>
>> SWIG Version
>> ------------
>>
>> Last - I vaguely remember that the SWIG generated wrappers for Ruby were
>>   after swig 1.3.28 but before 1.3.29.  I see Ari has updated Perl to
>> 1.3.29, the latest SWIG release, so I'll make sure the Ruby bindings are
>> at the same level.
>>
>> Charlie
>>
>>
>>
>> _______________________________________________
>> Gdal-dev mailing list
>> Gdal-dev at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/gdal-dev
>>
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20060624/56974de9/smime.bin