Hi Hez: A further IMPORTANT question: I have just been taking a look at the plcolorbar implementation in the swig-related languages and I have a question about the new arguments you introduced in revision 12235, which are currently typed const char *labels[] and const char *axis_opts[]. I would like to keep the proliferation of types to be as narrow as possible for the PLplot API. For similar purposes (passing an array of pointers to strings) and after considerable discussion on list, we decided to use the type const char * const * for the appropriate pllegend arguments. So would you be willing to go along with that type in this case as well, i.e.,
const char * const *labels and const char * const *axis_opts? If so it makes _all_ language bindings of plcolorbar and associated use of plcolorbar trivial to implement since developers can just copy how they interfaced the array of pointers to strings arguments from pllegend to plcolorbar. Of course, this proposed API change also implies C and (presumably) OCaml changes, but I will handle the C changes if you will take responsibility for the OCaml ones. More below in the context of your answers to my previous questions. On 2013-05-01 06:09-0400 Hezekiah M. Carty wrote: > On Wed, May 1, 2013 at 1:34 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> > wrote: >> These are important questions which I hope both Andrew and Hez will >> answer to the best of their knowledge. >> >> What is the status of plcolorbar? Has that API been finalized? >> > > I'd like some feedback before saying it's finalized. I have used > plcolorbar a lot (through the OCaml bindings) and have been pretty > happy with it. There at least one addition which I think would be > useful but I don't know if it is worth adding: > > We could add displacement, position and justification options for axis > labels such as what is available when using plmtex directly. This is > useful, for example, if you have two different unit systems labeled on > each vertical axis on a vertically oriented color bar. A work-around > is available with the current interface if you use a single label and > manually adjust the text to be centered appropriately around the bar. > One option is to add the parameters now (a few additional PLFLT > arrays) so you can do your binding propagation work. The > implementation of the feature in the C plcolorbar code could be > carried out separately from the API propagation. I don't have a lot of complex plcolorbar needs in my research, but it does sound like the further API change that you propose would be useful to you and others with more complex plcolorbar needs. So I suggest you just go ahead and make the change. We are still officially in the experimental stage for the plcolorbar functionality and API so let's take advantage of that grace period and make sure the API is right rather than having to change the API later with all the backwards incompatiblity issues that are raised by that. Furthermore, I suggest you do the plcolorbar implementation and API changes simultanously since experience shows it is hard to anticipate all API needs until you actually have some working code to test. If your time constraints allow it, it would be ideal if you could finish off this last implementation and API change to plcolorbar in the next few days. > >> If finalized, what further changes (if any) do you propose for C >> examples 16 and 33? My impression is 16 is done, and 33 just needs >> one change so that the plcolorbar part of it is changed from optional >> execution to always executed. If you confirm my impression, please >> commit that one C example 33 change so it can be propagated >> to the rest of the languages. >> > > I think C example 16 is fine the way it is. I agree. > C example 33 with the colorbar option enabled is very verbose. I'm ok > with leaving that verbosity in place but it would leave a huge number > of pages in that example. Again, I would like feedback regarding > whether the number of cases covered in this example (which still > doesn't show all of what plcolorbar can do!) is reasonable. No question, there are a lot of pages there, but as you say there is a lot of plcolorbar functionality to test/demonstrate. Having an incomplete example is bad because that means some of the plcolorbar API will be untested not only in C but when the example is propagated to other languages. Therefore, I encourage you to add more pages to C example 33 until you feel it is a good, comprehensive test of the plcolorbar API. Also, it appears to me we are currently testing most of the optional plcolorbar functionality for that example with rather compact code so despite the large number of pages being generated by that compact code, I think the propagation efforts will actually not require an onerous amount of editing work for the various example 33 implementations. Giving what you had said about the status of plcolorbar and associated examples, I will immediately concentrate today on propagating the plshade/plshades and pllegend line width changes to the swig-related bindings and associated examples 4, 15, 16, 26, and 33. And if I get a positive response from you concerning the proposed changes above to the types of labels and axis_opts for plcolorbar, then I can undertake to implement plcolorbar in the languages I am taking responsibility for and use that new API in example 16 for those languages. And also take responsibility for further propagation if you implement the further change to the plcolorbar API that you proposed above. Completing example 33 is obviously a separate issue which I assume you will want to put off until later because of your time constraints. But whenever you are done with that I would be willing to follow up by propagating those changes to example 33 for the languages I have taken responsibility for. 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 __________________________ ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
