On Wed, Dec 1, 2010 at 5:16 AM, strk s...@keybit.net 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
.
On Wed, Dec 1, 2010 at 12:21 AM, Paul Ramsey pram...@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
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
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 s...@keybit.net wrote:
On
On Wed, Dec 1, 2010 at 11:38 AM, Paul Ramsey pram...@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
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
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
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
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
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 j...@zoocasa.com wrote:
Hello list!
I work on a project that has been using the GEOS Ruby bindings for
years
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
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
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
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 j...@zoocasa.com wrote:
Alright, all, that wasn't too bad...
Using the output from
14 matches
Mail list logo
