On Mar 24, 2014, at 3:18 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> Hi Arjen: > > Thanks for responding to Moez' question on plplot-general concerning > interative Fortran possibilities. I think we are all agreed with the > two goals you stated of having interactive support for all our > language bindings and each of our interactive devices. And it is also > pretty clear we need to implement plmergeopts for all our bindings. So > I would like to start discussion here of all three of those topics. > > 1. Interactive support for all our language bindings. > > The fundamental issue here is the argument of plGetCursor is a pointer > to a PLGraphicsIn struct, and C structs like that are not supported by > most languages we support now. For example, although plGetCursor does > appear to have a binding for the Octave case, that function is > completely ignored for the rest (Python, Java, and Lua) of our > swig-generated bindings, and I assume it is also ignored for most/all > of our bindings that are not generated by swig. FWIW, Ada implements this. Jerry > > So I think the best way forward here is to define a (c_)plgcursor function > which wraps plGetCursor and whose arguments are a list of PLINT and > PLFLT pointers to all the kinds of information currently contained in > the PLGraphicsIn struct. If everybody is in agreement on that general > approach, then it should be straightforward to propagate the proposed > (c_)plgcursor function to all our language bindings. > > 2. Interactive support for the PLESC_GETC escape code for each of our > interactive devices. > > I did my own survey of our important interactive devices, and (in > agreement with what you said on plplot-general) I think the only important > interactive device missing this capability is the wingcc driver. > > @Argen: does the Windows API used for the wingcc device support the > possibility of returning cursor information? If so, getting this > device up to speed with the remaining interactive devices should be > straighforward. > > 3. Implementation of (c_)plmergeopts and propagating it to all bindings > > Topics 1 and 2 discuss the changes needed to support the locate mode > in example 1 for all bindings and for each of our interactive devices. > But that brings up a related issue which is that we should also have > complete language bindings for plMergeOpts (renamed to (c_)plmergeopts > as appropriate for a function in our public API). This would allow us > to use the -locate option for example 1 in any language. > > This should be straightforward except for one issue which is that both > the first and 3rd arguments to plMergeOpts are currently arrays of > _either_ pointers to strings _or_ NULL. Languages support NULL > arguments in a wide variety of ways (if they support them at all). So > I think a much better thing to do would be to drop that second > alternative and instead use the empty string (a concept supported by > all languages) for the same purpose as the current NULL. > > Question for those here who are familiar with use of plMergeOpts, and > all the argument parsing. Is there any reason not to use the empty > string this way? For example, would an empty string have a normal use > which would preclude using it as a substitute for the current NULL > which is used to mark holes in the options table as well as the final > array element. > > In any case, once we arrive at consensus on how to deal with this > issue, the implementation should be straightforward. > > 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); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); 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 > __________________________ > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
