Re: [geos-devel] GEOS Ruby bindings gem and extensions
This is fantastic news! Really looking forwards to the release, and it
lets me cross off a big to-do from my list :)
All the best,
Simon
On Tue, Nov 30, 2010 at 10:05 PM, J Smith wrote:
> Hello list!
>
> I work on a project that has been using the GEOS Ruby bindings for
> years and and we've been adding a bunch of extensions and
> modifications to it throughout that time. We've gotten to the point
> now where we'd like to release this code into the wild world of free
> software and open source and thought we'd drop a line to the
> geos-devel list to get some feedback and whatnot before releasing the
> code.
>
> We're specifically looking to release the following:
>
> - we've gemified the Ruby bindings portion of the GEOS library so it
> can be installed separately from the library itself. It still depends
> on the library, obviously, but can be built as a standalone gem. We've
> extracted the geos.i.in and ruby.i files from the GEOS tarball and
> wrote a gemspec and extconf.rb for it that extracts the relevant
> version information from geos_c.h and builds the SWIG output
> accordingly.
>
> - we've also extracted the Ruby test files and the gem has been tested
> on OSX and CentOS 5.5, although some of the tests appear to fail. (The
> tests themselves may be a bit stale, perhaps -- one test looks for a
> version string matching "3.0.0rc4-CAPI-1.3.3", for instance.)
>
> As for the extensions to the library, we've implemented the following
> in Ruby userland as wrappers and whatnot around the GEOS library:
>
> - a host of helper methods to make reading and writing to and from WKT
> and WKB easier. For instance, rather than
>
> Geos::WktReader.new.read('POINT(0 0')
>
> you can quickly use
>
> Geos.read('POINT(0 0)')
>
> The Geos.read method also works with WKB in both binary and hex,
> recognizes EWKB and EWKT and can read several of Google Maps
> JavaScript output formats that we use for our applications. There are
> also similar methods for outputting to WKT and WKB such as
> Geos::Geometry#to_wkt, #to_kml, #to_georss and a number of methods to
> output to Google Maps API v2-style JavaScript.
>
> - a bunch of helper methods to quickly grab some information from
> geometries like Geos::Point#lat and Geos::Point#lng.
>
> - in all, some 70+ helper methods have been added to Geos::Geometry types.
>
> - Geos::GeometryCollection has been made an Enumerable.
>
> We've also included some Rails integration for PostGIS, including:
>
> - automatic detection of geometry columns and just-in-time conversions
> for input and output to and from WKB when using PostGIS. This allows
> you to do stuff like this with your ActiveRecord models:
>
> m = MyModel.find(12345)
> m.the_geom # => spits out the untouched geometry value as a string in WKB
> m.the_geom_geos # => spits out the geometry wrapped in a Geos::Geometry object
> m.the_geom = 'POINT(0 0)' # => setters will automatically make
> conversions from any of the formats that the Geos.read can recognize,
> so Google Maps formats, WKT, WKB, etc. are all converted
> automatically.
> m.the_geom_wkt # => automatically converts to a WKT string
> m.the_geom_wkb_bin # => automatically converts to WKB in binary
>
> There's also some funky SRID handling code that will automatically
> look in the geometry_columns table to make conversions for you when
> necessary. Saving WKT as "SRID=default; POINT(0 0)" for instance will
> automatically set the SRID when saving the ActiveRecord, or the SRID
> can be specified manually.
>
> - multiple geometry columns are supported and detected for
> automatically. These column accessors are all generated dynamically at
> run time.
>
> - automatic generation of named scopes for ActiveRecord models. The
> usual suspects are supported:
>
> * st_contains
> * st_containsproperly
> * st_covers
> * st_coveredby
> * st_crosses
> * st_disjoint
> * st_equals
> * st_intersects
> * st_orderingequals
> * st_overlaps
> * st_touches
> * st_within
> * st_dwithin
>
> These let you chain together scopes to build geospatial queries:
>
> neighbourhood = Neighbourhood.find(12345)
> my_model = MyModel.active.
> recent.
> st_within(neighbourhood.the_geom_geos.envelope).
> st_dwithin(point, 0.1).
> all(
> :limit => 10
> )
>
> - we wrote this code for Rails 2.3 and are currently testing on Rails
> 3, but it appears that everything is working as expected and is
> working with Arel (hopefully!).
>
> Our plan at the moment would be to put the code up on to github along
> with the appropriate Rubygems releases. We'd like to license the
> extensions code under the MIT license as per the usual Ruby and Rails
> library terms. As for the gemified build of the GEOS bindings library
> itself, would the correct license in this case be the LGPL? We've
> included several files from the main GEOS library along with the Ruby
> test files, so would this extend that license to the rest of the gem,
> which includes only build files like a Rakefile, extconf.rb and a
> gemspec and
Re: [geos-devel] GEOS Ruby bindings gem and extensions
Hi J, We're specifically looking to release the following: - we've gemified the Ruby bindings portion of the GEOS library so it can be installed separately from the library itself. It still depends on the library, obviously, but can be built as a standalone gem. We've extracted the geos.i.in and ruby.i files from the GEOS tarball and wrote a gemspec and extconf.rb for it that extracts the relevant version information from geos_c.h and builds the SWIG output accordingly. 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? - we've also extracted the Ruby test files and the gem has been tested on OSX and CentOS 5.5, although some of the tests appear to fail. (The tests themselves may be a bit stale, perhaps -- one test looks for a version string matching "3.0.0rc4-CAPI-1.3.3", for instance.) As for the extensions to the library, we've implemented the following in Ruby userland as wrappers and whatnot around the GEOS library: - in all, some 70+ helper methods have been added to Geos::Geometry types. Ok, I've done something similar. Happy to move over to these. They are in Ruby code I assume? - Geos::GeometryCollection has been made an Enumerable. Cool. We've also included some Rails integration for PostGIS, including: Our plan at the moment would be to put the code up on to github along with the appropriate Rubygems releases. How about two gems. One for the geos bindings, and then a separate one for rails. That way people don't have to have the extra rails code if they don't want it. Charlie ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 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 build time. I see that the geos::geom::geosversion() method will return the GEOS version and in the CAPI GEOSversion() function will return the CAPI information. I think that would be enough for the version numbers to be extracted, yeah? I'll give it a shot at any rate. > Ok, I've done something similar. Happy to move over to these. They are in > Ruby code I assume? > All of the extensions are in plain ol' Ruby code. > How about two gems. One for the geos bindings, and then a separate one for > rails. That way people don't have to have the extra rails code if they > don't want it. > I think the plan at the moment is two gems -- one that strictly builds the GEOS binary and a separate one that contains all of the extension code plus the Rails integration. The Rails integration is pretty compact and only gets included when Rails tries to use the gem, so normal Ruby should never feel the effects. I'm going to mess around with the generated SWIG code and see what I can do about removing SWIG as dependency and get the version numbers working. Once we're ready, I think we'll be posting the project to github and open things up for patches before we roll releases, just to give everyone a chance to take a look at the code and make sure it's sane. Hopefully we'll be ready to do so within the week, so wish us luck. Cheers... J ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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? ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 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 > SWIG can presumably be removed from the build process. > > Thoughts? > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel > ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS Ruby bindings gem and extensions
On Tue, Nov 30, 2010 at 05:05:35PM -0500, J Smith wrote: > Our plan at the moment would be to put the code up on to github along > with the appropriate Rubygems releases. Good idea. > We'd like to license the > extensions code under the MIT license as per the usual Ruby and Rails > library terms. Why not LGPL ? As per "usual", freshmeat finds 276 projects written in Ruby, with their licenses: GPL: 90 MIT/X: 43 BSD Revised: 33 LGPL: 28 GPLv3: 18 . http://freshmeat.net/search?page=1&q=ruby&submit=Search&with=800&without= --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS Ruby bindings gem and extensions
On Wed, Dec 1, 2010 at 5:16 AM, strk wrote:
>
> Why not LGPL ?
>
> As per "usual", freshmeat finds 276 projects written in Ruby,
> with their licenses:
>
> GPL: 90
> MIT/X: 43
> BSD Revised: 33
> LGPL: 28
> GPLv3: 18
> .
>
> http://freshmeat.net/search?page=1&q=ruby&submit=Search&with=800&without=
>
The MIT license is sort of the trending license for Ruby projects
these days, if you will. I think Rails started the trend, as its major
components are all MIT licensed, as are many of the more popular
Ruby-based projects like Phusion Passenger, Bundler, rspec, gemcutter,
jeweler... on my system for instance, out of the 276 gems I have
installed (strange coincidence), approximately 207 gems appear to be
using the MIT license after some grepping around. ("Approximately", as
the license information seems to be omitted from the gemspecs way more
often than not, so my grepping was done using portions of the text of
the license itself and the phrase "MIT licen[sc]e".)
Anyways, when in Rome and all that...
Raw numbers aside, we also like the simple terms of the license and
its permissive nature.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS Ruby bindings gem and extensions
On Wed, Dec 1, 2010 at 12:21 AM, Paul Ramsey 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 gemified version available via github and rubygems. On the other hand, decoupling the Ruby bindings from the main library would allow for independent releases where Ruby-specific features can be written and released without having to do an entire GEOS release. At any rate, the big news here is that the Ruby extension can be made available via rubygems and thus available to a wider audience. At the moment, installing the Ruby bindings usually means either hoping your package management system has a geos-ruby-type package available or you're building by hand and manually enabling with --enable-ruby. Personally I'd say going the github way would be preferable from release management and visibility perspectives, but if we want to look at integration into the GEOS as an option we can hash it out. Cheers. ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel > ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS Ruby bindings gem and extensions
On Wed, Dec 1, 2010 at 11:38 AM, Paul Ramsey 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! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 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 SWIG can presumably be removed from the build process. Thoughts? ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel -- Charlie Savage http://cfis.savagexi.com ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel -- Charlie Savage http://cfis.savagexi.com ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 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@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/geos-devel > > -- > Charlie Savage > http://cfis.savagexi.com ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS Ruby bindings gem and extensions
On Wed, Dec 1, 2010 at 11:55 AM, strk 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 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 wrote: > On Wed, Dec 1, 2010 at 11:55 AM, strk 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 > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 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 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
