From: David M. <da...@as...> - 2010-02-26 22:10:04
|
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"! :-) I am currently working on plimagefr support, including pltr support. I have noticed that the documentation for plimagrfr's pltr parameter says that it is... > Pointer to function that defines transformation between indices in > array idata and the world coordinates (C only). ...but in practice it seems to call pltr with (x,y) values from (0,0) to (nx,ny) rather than the documented implied range of (0,0) to (nx-1,ny-1). I looked at the implementation of plimageslow() in src/ plimage.c and convinced myself that the code is OK, but the docs are misleading. If others agree, how about clarifying the above sentence as... Pointer to function that defines transformation between indices (ix,iy) and world coordinates (x,y), where 0<=ix<=nx and 0<=iy<=ny (C only). Dave |
From: Alan W. I. <ir...@be...> - 2010-02-27 22:47:40
|
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 __________________________ |
From: David M. <da...@as...> - 2010-02-28 06:55:45
|
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 |
From: Andrew R. <and...@us...> - 2010-02-28 11:20:39
|
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 |
From: David M. <da...@as...> - 2010-03-01 07:51:39
|
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 |
From: Andrew R. <and...@us...> - 2010-03-03 20:04:26
|
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 |
From: Hezekiah M. C. <hez...@us...> - 2010-03-06 19:19:48
|
On Fri, Feb 26, 2010 at 5:09 PM, David MacMahon <da...@as...> 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"! :-) > > I am currently working on plimagefr support, including pltr support. > I have noticed that the documentation for plimagrfr's pltr parameter > says that it is... > >> Pointer to function that defines transformation between indices in >> array idata and the world coordinates (C only). > > ...but in practice it seems to call pltr with (x,y) values from (0,0) > to (nx,ny) rather than the documented implied range of (0,0) to > (nx-1,ny-1). I looked at the implementation of plimageslow() in src/ > plimage.c and convinced myself that the code is OK, but the docs are > misleading. > > If others agree, how about clarifying the above sentence as... > > Pointer to function that defines transformation between indices > (ix,iy) and world coordinates (x,y), where 0<=ix<=nx and 0<=iy<=ny (C > only). > Dave, Thank you for catching this. The coordinates in pltr_data correspond with the corners of the data being plotted so the documentation should be fixed. How does this sound? Pointer to function that defines a transformation between the data in the array <literal><parameter>idata</parameter></literal> and world coordinates. An input coordinate of <literal>(0, 0)</literal> corresponds to the "top-left" corner of <literal><parameter>idata</parameter></literal> while <literal>(nx, ny)</literal> corresponds to the "bottom-right" corner of <literal><parameter>idata</parameter></literal>. Some transformation functions are provided in the PLplot library: &pltr0; for identity mapping, and &pltr1; and &pltr2; for arbitrary mappings respectively defined by one- and two-dimensional arrays. In addition, user-supplied routines for the transformation can be used as well. Examples of all of these approaches are given in <xref linkend="contour-plots-c"/>. The transformation function should have the form given by any of &pltr0;, &pltr1;, or &pltr2;. The docbook code validates, so I have checked this in as revision 10857. Hez |
From: David M. <da...@as...> - 2010-03-06 22:18:03
|
Hi, Hez, On Mar 6, 2010, at 11:12 , Hezekiah M. Carty wrote: > How does this sound? Much better, thanks! The key thing, IMHO, is to make clear the distinction between integer "input coordinates" and integer "idata indices" (with the former exceeding the latter by one in both dimensions). Dave |