Re: [Plplot-devel] Ruby bindings
On Sun, Feb 28, 2010 at 11:51:28PM -0800, David MacMahon wrote: Hi, Andrew, Thanks for your comments. Ideally I'd like somehow to support both a Ruby-centric installation (i.e the .gem file) as well as non-Ruby- centric installations (e.g. apt/yum/port/whatever). Alan's analysis (showing that most people install plplot binaries via a package manager) got me wondering about how most people install Ruby extensions. I've always done it via the gem command, but I know MacPorts has a bunch of rb-xyzzy ports that can be installed, so maybe people install Ruby extensions that way more often than I imagine. To tell the truth, I wouldn't be able to install a non-gem Ruby extension manually without looking up how to do it! :-) One nice thing about the gem based install is that it is very easy for non-admin users to install gems under their home directories so they need not bother the admins with installing gems in system directories (but they can if they want to, of course). I imagine most package managers let non-admin users do that too, but I'd be surprised if it were so easy as a non-admin gem based installation. How does Debian package up Ruby extensions? For example, is there a rails package? The (draft) ruby policy is at http://pkg-ruby.alioth.debian.org/ It looks like debian does package quite a few ruby modules for administrator convenience. There is a package rails for example. Certainly debian's package manager doesn't allow installation in non standard locations (except by unpacking the files by hand). It kind of defeats the object of packaging things up neatly for the distribution. I know nothing about ruby, so the above is just what I've gathered from looking at the debian archives and a quick google search! I'm not sure in this case that installing the ruby bindings into a home directory helps. You still need to install the plplot libraries. If you don't have administrator priviledges then this means compiling it yourself, so you might as well get the ruby bindings as part of the compilation. Andrew -- Download Intel#174; 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
Re: [Plplot-devel] Ruby bindings
Hi, Andrew, Thanks for your comments. Ideally I'd like somehow to support both a Ruby-centric installation (i.e the .gem file) as well as non-Ruby- centric installations (e.g. apt/yum/port/whatever). Alan's analysis (showing that most people install plplot binaries via a package manager) got me wondering about how most people install Ruby extensions. I've always done it via the gem command, but I know MacPorts has a bunch of rb-xyzzy ports that can be installed, so maybe people install Ruby extensions that way more often than I imagine. To tell the truth, I wouldn't be able to install a non-gem Ruby extension manually without looking up how to do it! :-) One nice thing about the gem based install is that it is very easy for non-admin users to install gems under their home directories so they need not bother the admins with installing gems in system directories (but they can if they want to, of course). I imagine most package managers let non-admin users do that too, but I'd be surprised if it were so easy as a non-admin gem based installation. How does Debian package up Ruby extensions? For example, is there a rails package? Thanks again, Dave -- Download Intel#174; 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
[Plplot-devel] Ruby bindings
Hi David: I changed the subject line for obvious reasons. On 2010-02-26 14:09-0800 David MacMahon wrote: As you all know by now, I'm working on Ruby bindings to PLplot. I am (still) almost ready for a first release. There's always a few more things! :-) You may have done this already, but I highly recommend that you implement the standard set of 31 examples in ruby. The test_diff_psc target (which is a subset of the test_noninteractive target) has been implemented to compare Postscript results from all our official bindings with Postscript results from the standard C examples. This has proved to be a powerful tool to diagnose even subtle bugs in the bindings, but complete coverage of the API does require implementing the complete standard set of examples in each set of bindings. The above suggestion pertains regardless of whether you are going to donate your ruby bindings to PLplot or not. However, if you do intend such a donation (under the LGPL), then you don't have to wait for perfection. For example, a donation would be fine if you just had at least the first standard example working since that would give me an opportunity to do the required initial build system changes to accomodate your initial list of implemented standard examples (if you haven't already done those build system changes in your initial donation). 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. :-) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Download Intel#174; 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
Re: [Plplot-devel] Ruby bindings
On Feb 27, 2010, at 14:47 , Alan W. Irwin wrote: On 2010-02-26 14:09-0800 David MacMahon wrote: As you all know by now, I'm working on Ruby bindings to PLplot. I am (still) almost ready for a first release. There's always a few more things! :-) You may have done this already, but I highly recommend that you implement the standard set of 31 examples in ruby. Yes, I am fairly far along with porting the examples to Ruby. There are a few rough edges, but I basically have examples 1-16, 18, 21-25 already working under Ruby. Example 17 is the strip chart one and I just haven't gotten to those functions yet. This is also the case for example 19 (the map functions). I am nearing completion of example 20 (plimage and plimagefr). I haven't started porting the rest, but I think examples 26,27,28 should be straightforward. I haven't done the time functions yet (haven't figured out how they relate to TAI, UTC, JD, etc.) so example 29 is still a TODO. I think examples 30 and 31 should be very easy once I get to them. The test_diff_psc target (which is a subset of the test_noninteractive target) has been implemented to compare Postscript results from all our official bindings with Postscript results from the standard C examples. This has proved to be a powerful tool to diagnose even subtle bugs in the bindings, but complete coverage of the API does require implementing the complete standard set of examples in each set of bindings. Sounds very useful! Thanks for bringing this to my attention. 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. 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. Dave -- Download Intel#174; 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
[Plplot-devel] Ruby bindings
On Tue, Jan 05, 2010 at 02:45:11PM -0800, David MacMahon wrote: I'm working on creating Ruby bindings to PLplot, much like the Ruby bindings to PGPLOT (http://pgplot.rubyforge.org/). I've gotten a fair amount of the API done and the first seven or so examples ported. I'll be happy to share my work once it gets a little more complete. David, We'd of course welcome any contributions for a ruby binding to plplot. How are you generating it? I'd strongly recommend looking at swig (http://www.swig.org) for automatically generating them. We use this for several existing bindings. It would greatly decrease the maintenance overhead to use this again. We've also found it very useful, and once the initial setup is done, relatively easy to use. Regards Andrew -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Ruby bindings
Hi, Andrew, On Jan 6, 2010, at 0:01 , Andrew Ross wrote: We'd of course welcome any contributions for a ruby binding to plplot. I'll be happy to contribute it. It's coming along. How are you generating it? I'd strongly recommend looking at swig (http://www.swig.org) for automatically generating them. We use this for several existing bindings. It would greatly decrease the maintenance overhead to use this again. We've also found it very useful, and once the initial setup is done, relatively easy to use. I have used swig to generate bindings to other libraries in the past. It is impressive how many languages it supports, but IMHO it suffers somewhat from the jack-of-all-trades-master-of-none syndrome. Sure, it can generate bindings to a library for loads of languages from not much more than a header file, but I find that the easy-to-generate bindings are often not very natural feeling in the target language. To get the bindings to be more natural feeling in the target language involves language specific (and often function and/or argument specific) typemaps. Once one starts down the path of target language specific customizations, the value of swig rapidly diminishes (IMHO) to the point of being seriously questionable as to whether it is a net gain at all over hand crafted bindings. Again, this is all IMHO, YMMV. I am following the coding model used in Ruby's PGPLOT bindings, which has its own semi-custom but relatively simple (ruby-only) code generation script for many of the API calls. The code generator supports any function that: 1. has only non-pointer input arguments (other that const char *), and 2. has all output arguments (if any) after the input arguments (if any) 3. has no arguments that one might want to make optional For the remaining functions, the bindings for most follow a very similar design pattern which makes the coding go relatively fast. Learning PLplot along the way slows thing down slightly but it's really a nice benefit for me! Another (admittedly somewhat selfish) reason for this approach over the swig approach is the desire to mimic the Ruby PGPLOT interface as closely as possible/practical so I can more easily convert my existing Ruby scripts that use PGPLOT over to using PLplot. :-) I'll keep you posted on my progress, Dave -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
