headers
J Smith | 1 Dec 2010 01:57
Favicon

Re: GEOS Ruby bindings gem and extensions

Hey Charlie.

Just to start off with, as I believe you were the original author of
the SWIG bindings: thanks for the Ruby library! When we first
discovered it we were ecstatic, 'cause the Ruby-based solutions we
were looking at at the time were prohibitively slow. Nothing beats
native libraries (usually, at least), especially when you're dealing
with geometries that have potentially tens of thousands of vertices.

On Tue, Nov 30, 2010 at 7:08 PM, Charlie Savage <cfis <at> savagexi.com> wrote:
>
> Great - I think it would be a good idea to package this code as a gem so its
> more easily available to the Ruby community.  Will the gem also include the
> generated swig file (I'd say it probably should to eliminate the extra
> dependency on swig) or have you ported the code to just a straight ruby
> extensions?
>

At the moment I just took the SWIG files and am generating the
geos_wrap.cxx file as per the original build, but thinking on it a bit
more, it doesn't really seem necessary. One of the potential problems
with the SWIG files is that some Ruby constants are filled in at build
time rather than run time, and that could become problematic -- if you
built the gem against GEOS 3.2.0, for instance, but later upgraded the
library itself to GEOS 3.2.2, your Ruby gem would still be reporting
the 3.2.0 version numbers as it was built.

What I think I'll do is just generate the geos_wrap.cxx file from the
SWIG files and use that along with some additions to handle extracting
the version numbers from the GEOS library at run time rather than at
(Continue reading)

Permalink | Reply |
headers
J Smith | 1 Dec 2010 03:49
Favicon

Re: GEOS Ruby bindings gem and extensions

Alright, all, that wasn't too bad...

Using the output from geos.i, I removed the version number constants
that get sorted out when geos.i is generated and which in turn is used
to generate geos_wrap.cxx. Instead of hard coding the constants at
build time, we can just use rb_eval_string during the extension
initialization to extract the version numbers from the Geos.version
method. For the GEOS_JTS_PORT constant, I noticed that the
GEOSjtsport() function isn't exported for the CAPI in geos_c.h, but I
extern'd it in the Ruby extension anyways to extract the version
information. Is GEOSjtsport() unsafe to use for such purposes? It
seems to be similar enough to GEOSversion() that it could probably be
available in the CAPI, no? If GEOSjtsport is unsafe to use I'll remove
it, though; I just wanted to retain complete compatibility with
existing constants is all. Is GEOS_JTS_PORT a particularly useful
constant? I've never had to use it, but then again I don't use JTS
myself directly. (As an aside, I also added a I've also ssws a
Geos.jts_port method similar to the Geos.version method.)

At any rate, the version constants can now be created at extension
initialization so they won't be dependant the geos.i file any more and
SWIG can presumably be removed from the build process.

Thoughts?
Permalink | Reply |
headers
Paul Ramsey | 1 Dec 2010 06:21
Favicon
Gravatar

Re: GEOS Ruby bindings gem and extensions

My only thought is, "my, I know nothing about Ruby!". So, do tell me
what needs to be in the main GEOS repo and who is going to need access
to commit it. :)

Best,

P.

On Tue, Nov 30, 2010 at 6:49 PM, J Smith <jay <at> zoocasa.com> wrote:
> Alright, all, that wasn't too bad...
>
> Using the output from geos.i, I removed the version number constants
> that get sorted out when geos.i is generated and which in turn is used
> to generate geos_wrap.cxx. Instead of hard coding the constants at
> build time, we can just use rb_eval_string during the extension
> initialization to extract the version numbers from the Geos.version
> method. For the GEOS_JTS_PORT constant, I noticed that the
> GEOSjtsport() function isn't exported for the CAPI in geos_c.h, but I
> extern'd it in the Ruby extension anyways to extract the version
> information. Is GEOSjtsport() unsafe to use for such purposes? It
> seems to be similar enough to GEOSversion() that it could probably be
> available in the CAPI, no? If GEOSjtsport is unsafe to use I'll remove
> it, though; I just wanted to retain complete compatibility with
> existing constants is all. Is GEOS_JTS_PORT a particularly useful
> constant? I've never had to use it, but then again I don't use JTS
> myself directly. (As an aside, I also added a I've also ssws a
> Geos.jts_port method similar to the Geos.version method.)
>
> At any rate, the version constants can now be created at extension
> initialization so they won't be dependant the geos.i file any more and
(Continue reading)

Permalink | Reply |
headers
J Smith | 1 Dec 2010 17:26
Favicon

Re: GEOS Ruby bindings gem and extensions

On Wed, Dec 1, 2010 at 12:21 AM, Paul Ramsey <pramsey <at> opengeo.org> wrote:
> My only thought is, "my, I know nothing about Ruby!". So, do tell me
> what needs to be in the main GEOS repo and who is going to need access
> to commit it. :)
>
> Best,
>
> P.
>

Hi Paul.

At the moment the number of files is minimal:

- a Rakefile for various build tasks and such, via a Ruby package
called jeweler which automates builds and releases to the rubygems
infrastructure

- an extconf.rb file, which creates Makefiles for Ruby extensions.

- a modified source file based on the output created by the SWIG Ruby
output produced during the normal GEOS build process.

The big question is: do we want to have this code directly in the main
GEOS repository? We were planning on using github to facilitate the
whole social coding scene thing and 'cause we like the dead-simple
release management that jeweler provides.

Of course, the downside to this is that there would be a divergence
between the main-line SWIG bindings in the GEOS repository versus the
(Continue reading)

Permalink | Reply |
headers
strk | 1 Dec 2010 17:31
Gravatar

Re: GEOS Ruby bindings gem and extensions

On Wed, Dec 01, 2010 at 11:26:16AM -0500, J Smith wrote:

> The big question is: do we want to have this code directly in the main
> GEOS repository? We were planning on using github to facilitate the
> whole social coding scene thing and 'cause we like the dead-simple
> release management that jeweler provides.

I second using a separate repository.
That way you can keep binding release cycles completely separated
from the core GEOS library.

I've been too lazy to do that for the PHP bindings...

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
Permalink | Reply |
headers
Paul Ramsey | 1 Dec 2010 17:38
Favicon
Gravatar

Re: GEOS Ruby bindings gem and extensions

If there's no integration *required* to make the Ruby stuff work well,
then (a) you should keep them  and (b) we should strip out the old
ones and replace them with a readme.txt pointing to the location of
the maintained ones.

P.

On Wed, Dec 1, 2010 at 8:31 AM, strk <strk <at> keybit.net> wrote:
> On Wed, Dec 01, 2010 at 11:26:16AM -0500, J Smith wrote:
>
>> The big question is: do we want to have this code directly in the main
>> GEOS repository? We were planning on using github to facilitate the
>> whole social coding scene thing and 'cause we like the dead-simple
>> release management that jeweler provides.
>
> I second using a separate repository.
> That way you can keep binding release cycles completely separated
> from the core GEOS library.
>
> I've been too lazy to do that for the PHP bindings...
>
> --strk;
>
>  ()   Free GIS & Flash consultant/developer
>  /\   http://strk.keybit.net/services.html
> _______________________________________________
> geos-devel mailing list
> geos-devel <at> lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
(Continue reading)

Permalink | Reply |
headers
J Smith | 1 Dec 2010 17:53
Favicon

Re: GEOS Ruby bindings gem and extensions

On Wed, Dec 1, 2010 at 11:38 AM, Paul Ramsey <pramsey <at> opengeo.org> wrote:
> If there's no integration *required* to make the Ruby stuff work well,
> then (a) you should keep them  and (b) we should strip out the old
> ones and replace them with a readme.txt pointing to the location of
> the maintained ones.
>
> P.
>

That would be cool. A further option to that -- if there's an official
GEOS or OpenGeo github account, our gem could be forked and that could
sort of become the official "GEOS-blessed" gem and we, as Zoocasa,
could have our own separate fork in a more unofficial way. That way we
can add stuff as we need to to our gem but it won't affect the
upstream blessed-gem unless you guys decide to merge any changes in.
(This whole social coding thing is pretty cool, yeah?)

I don't really know how much maintenance would be required going
forward as the Ruby bindings seem are quite stable. Perhaps this sort
of release will foster some interest in new features in the bindings
themselves. For our part, we've never had to patch away at the
bindings directly and have been putting all of our extensions into the
separate gem we'll be releasing, so that's kind of a separate thing.

Cheers!
Permalink | Reply |
headers
strk | 1 Dec 2010 18:04
Gravatar

Re: GEOS Ruby bindings gem and extensions

On Wed, Dec 01, 2010 at 11:53:08AM -0500, J Smith wrote:

> That would be cool. A further option to that -- if there's an official
> GEOS or OpenGeo github account, our gem could be forked and that could
> sort of become the official "GEOS-blessed" gem and we, as Zoocasa,
> could have our own separate fork in a more unofficial way. That way we
> can add stuff as we need to to our gem but it won't affect the
> upstream blessed-gem unless you guys decide to merge any changes in.
> (This whole social coding thing is pretty cool, yeah?)

I'm loving distributed VCS too, but in this case we're talking
about keeping the binding separated so don't see a reason for
a fork.

I've an unofficial copy of geos svn on github.com/strk
Would love to see osgeo provide a git infrastructure.
Unfortunately github uses proprietary software for that.
But code used by gitorious.org is free-as-in-freedom.

All in all it's not important _where_ you put the code, if it's
in a git repo you can still share the efforts. Don't need the
web buttons for doing forks and pull requests. 

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
Permalink | Reply |
headers
Charlie Savage | 1 Dec 2010 19:48
Favicon

Re: GEOS Ruby bindings gem and extensions

> I don't really know how much maintenance would be required going
> forward as the Ruby bindings seem are quite stable. Perhaps this sort
> of release will foster some interest in new features in the bindings
> themselves. For our part, we've never had to patch away at the
> bindings directly and have been putting all of our extensions into the
> separate gem we'll be releasing, so that's kind of a separate thing.

In a perfect world, I would probably rewrite the Ruby bindings to not 
use SWIG because that makes it really hard for others to contribute due 
to SWIG's learning code and the awful C code it generates.

However, its not that big of a win as long as the current bindings 
expose whats needed from the geos c api and then any 
extensions/additions/language specific stuff is done in regular ruby code.

But if you have a week to kill J, I think it would be a nice change :)

Charlie
> _______________________________________________
> geos-devel mailing list
> geos-devel <at> lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel

--

-- 
Charlie Savage
http://cfis.savagexi.com
Permalink | Reply |
headers
J Smith | 1 Dec 2010 20:13
Favicon

Re: GEOS Ruby bindings gem and extensions

That's a possibility, perhaps using ruby's ffi bindings, assuming it doesn't hurt performance and keeps
the existing API. It sure could make things nicer for adding functionality and could open the code up
potentially to a new audience who aren't familiar with hacking at ruby at the C level. I have previously
done an ffi library, having converted the old ruby gd2 bindings library from using dlopen and friends to
using ffi (see the gd2-ffij gem), so I'm familiar with the process. Something to think about for sure...
Dammit, I think my weekend might have just been ruined, thanks for the idea. :)

Sent from my mobile

On 2010-12-01, at 1:48 PM, Charlie Savage <cfis <at> savagexi.com> wrote:

>> I don't really know how much maintenance would be required going
>> forward as the Ruby bindings seem are quite stable. Perhaps this sort
>> of release will foster some interest in new features in the bindings
>> themselves. For our part, we've never had to patch away at the
>> bindings directly and have been putting all of our extensions into the
>> separate gem we'll be releasing, so that's kind of a separate thing.
> 
> In a perfect world, I would probably rewrite the Ruby bindings to not use SWIG because that makes it really
hard for others to contribute due to SWIG's learning code and the awful C code it generates.
> 
> However, its not that big of a win as long as the current bindings expose whats needed from the geos c api and
then any extensions/additions/language specific stuff is done in regular ruby code.
> 
> But if you have a week to kill J, I think it would be a nice change :)
> 
> Charlie
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel <at> lists.osgeo.org
(Continue reading)

Permalink | Reply |
headers
Charlie Savage | 1 Dec 2010 19:44
Favicon

Re: GEOS Ruby bindings gem and extensions

> My only thought is, "my, I know nothing about Ruby!". So, do tell me
> what needs to be in the main GEOS repo and who is going to need access
> to commit it. :)
In theory nothing - the idea would be move the ruby bindings outside of 
the geos source tree and have them live on their own and packaged as gem.

The advantage is that it becomes much more accessible to ruby developers 
because they could just do something like this:

yum install geos
gem install geos

And equivalent on Linuxes and OSX.  Windows of course would still remain 
more difficult.

That is actually how most ruby bindings to native libraries work - they 
aren't included as part of the native library itself.

The downside is that the different language bindings (ie python and 
ruby) go their separate ways. But that is already the case anyway...

Charlie
>
> Best,
>
> P.
>
> On Tue, Nov 30, 2010 at 6:49 PM, J Smith<jay <at> zoocasa.com>  wrote:
>> Alright, all, that wasn't too bad...
>>
(Continue reading)

Permalink | Reply |
headers
strk | 1 Dec 2010 19:55
Gravatar

Re: GEOS Ruby bindings gem and extensions

On Wed, Dec 01, 2010 at 11:44:05AM -0700, Charlie Savage wrote:

> The downside is that the different language bindings (ie python and 
> ruby) go their separate ways. But that is already the case anyway...

Yeah, also for PHP I didn't use swig...

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
Permalink | Reply |
headers
Sean Gillies | 1 Dec 2010 20:15
Picon
Gravatar

Re: GEOS Ruby bindings gem and extensions

On Wed, Dec 1, 2010 at 11:55 AM, strk <strk <at> keybit.net> wrote:
> On Wed, Dec 01, 2010 at 11:44:05AM -0700, Charlie Savage wrote:
>
>> The downside is that the different language bindings (ie python and
>> ruby) go their separate ways. But that is already the case anyway...
>
> Yeah, also for PHP I didn't use swig...
>

I've nothing other than anecdotal evidence, but I'm convinced Shapely
(https://github.com/sgillies/shapely) has picked up more patches than
it would have if it were maintained within GEOS. I've also been able
to push out 22 releases in the time that GEOS has had 11 (11 is not a
bad number at all).

Isn't Ruby-FFI (https://github.com/ffi/ffi/wiki/why-use-ffi)
production ready? I'm having nothing but success with Python's ctypes
(and libffi) on Linux, OS X, and Windows.

--
Sean Gillies
Programmer
Institute for the Study of the Ancient World
New York University
Permalink | Reply |
headers
Simon Tokumine | 1 Dec 2010 21:16
Gravatar

Re: GEOS Ruby bindings gem and extensions

Ruby ffi went 1.0 yesterday, so perhaps good timing? I'd be very happy to help with a porting to FFI if it happened.

All the best,

Simon

On 1 Dec 2010, at 19:15, Sean Gillies <sean.gillies <at> gmail.com> wrote:

> On Wed, Dec 1, 2010 at 11:55 AM, strk <strk <at> keybit.net> wrote:
>> On Wed, Dec 01, 2010 at 11:44:05AM -0700, Charlie Savage wrote:
>> 
>>> The downside is that the different language bindings (ie python and
>>> ruby) go their separate ways. But that is already the case anyway...
>> 
>> Yeah, also for PHP I didn't use swig...
>> 
> 
> I've nothing other than anecdotal evidence, but I'm convinced Shapely
> (https://github.com/sgillies/shapely) has picked up more patches than
> it would have if it were maintained within GEOS. I've also been able
> to push out 22 releases in the time that GEOS has had 11 (11 is not a
> bad number at all).
> 
> Isn't Ruby-FFI (https://github.com/ffi/ffi/wiki/why-use-ffi)
> production ready? I'm having nothing but success with Python's ctypes
> (and libffi) on Linux, OS X, and Windows.
> 
> --
> Sean Gillies
> Programmer
(Continue reading)

Permalink | Reply |
headers
Charlie Savage | 1 Dec 2010 21:57
Favicon

Re: GEOS Ruby bindings gem and extensions

> I've nothing other than anecdotal evidence, but I'm convinced Shapely
> (https://github.com/sgillies/shapely) has picked up more patches than
> it would have if it were maintained within GEOS. I've also been able
> to push out 22 releases in the time that GEOS has had 11 (11 is not a
> bad number at all).
>
> Isn't Ruby-FFI (https://github.com/ffi/ffi/wiki/why-use-ffi)
> production ready? I'm having nothing but success with Python's ctypes
> (and libffi) on Linux, OS X, and Windows.

Ah, good point.  Yes it is, and is a default part of Ruby 1.9.2 I 
believe.  So that's another option that didn't really exist back when 
the bindings were first done.  Using them, you could do all ruby code.

Charlie

--

-- 
Charlie Savage
http://cfis.savagexi.com
Permalink | Reply |

Gmane