Alan, I think I broadly agree with all your comments below. My only concern with the plcolorbar API is that it has now become a monstorous beast. It is certainly the most complicated API call in plplot. Much of this functionality won't be needed by most users. I wonder if there is a better way to pack all these options into structure to prevent cluttering code for the majority of cases. This might be tricky to port to some languages which don't have such concepts.
I agree const arguments for the string pointers would be wise. In terms of the extra functionality I'm happy to go along with Hez's recommendation. He has developed this based on actual need so if he thinks it is required it probably is. Otherwise I'm fairly happy with the examples. I have begun the propagation of both the API and the examples some time back, but ran out of free time to devote to plplot. It is still on my list to return to this, but it won't be in the next week or two. If someone else is willing / able to pick this up it would be great. To my mind this is probably the largest remaining task ahead of the next release. Cheers Andrew On Wednesday 01 May 2013 11:32:55 Alan W. Irwin wrote: > 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 ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
