On Sat, Feb 27, 2010 at 10:55:32PM -0800, David MacMahon wrote: > > On Feb 27, 2010, at 14:47 , Alan W. Irwin wrote: > > > On 2010-02-26 14:09-0800 David MacMahon wrote: > > > > The above suggestion pertains regardless of whether you are going > > to donate > > your ruby bindings to PLplot or not. > > I certainly plan on donating them, but I'm not sure the best > channel. Ruby has an excellent package manager, RubyGems, that makes > downloading and installing extensions very easy (provided the > requisite libraries are already installed). I would like for people > to be able simply to run "gem install plplot" to install the Ruby > bindings to PLplot (again assuming they have the PLplot libraries > already installed). This would be building upon the binary distros > of PLplot (such as those that have been recently discussed on this > list). This just means that I need to "publish" a "gem file" on one > of the standard RubyGems distribution sites (formerly rubyforge.org, > but I think now gemcutter.org), but it doesn't say anything about > where the source code for the Ruby bindings will ultimately live. > Right now the source code lives in a git repo (separate from my git > svn clone of the PLplot Subversion repo) on my laptop, but clearly it > needs to be moved elsewhere once the bindings are released.
David, A couple of things you might like to consider: The only stable binding which is not part of the plplot source tree is the perl (PDL) bindings - again for the same reason that there is a well established perl packaging and distribution system. The perl examples are part of the plplot source though. This works ok, although there are sometimes issues with PDL lagging behind other languages when we update the bindings / examples. It adds another layer into the updaing process. In respect to the package distribution - Alan's analysis shows that most users install plplot from their distribution (at least under Linux) rather than downloaded and compiling themselves. In this case it is usually better to get other bindings from the same location and so it is perhaps less important. Even if you do get the ruby bindings via some ruby repository, the user still needs to get plplot from somewhere else and ensure the versioning is the same. This might well be more work than getting everything from one place. As a package maintainer (for Debian plplot packages) it is probably easier to have everything under one source package rather than having different packages from different locations being maintained by different people. Of course the source package generates a range of different binary packages, so if you wanted the ruby bindings you would only need the ruby bindings package, the core library package and any driver packages you required. You would not have to install all the bindings. Of course this does mean that the plplot packages are rather complicated in terms of number of packages, language specific installation conventions and build requirements, but that is the nature of supporting such a large number of language bindings. I realise that this is a very Linux centric view, but I think similar goes for the MacOS packaging repositories. Windows is a different case. If it was possible I think keeping the bindings in the plplot source, but also making them available via some ruby packaging system (if that is the Ruby thing to do) then that might work best, but its up to you. I'm not a ruby user so I'm sure you know better than me how ruby works. > > After all, we can disable the ruby bindings by default until they > > build and > > test without issues, and thus they won't interfere with normal use of > > PLplot. Furthermore, there will be plenty of opportunity for you > > to send > > patches in later to implement required bindings changes and add more > > standard example implementations. In fact, I would positively > > encourage > > such maintenance. :-) > > Thanks for this encouragement! I still want to polish things up a > little more before I release the Ruby bindings, but they are getting > quite close to a releasable state. That's great news. However it is distributed it will be a valuable contribution to plplot. Andrew ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
