On Mon, Apr 29, 2013 at 10:34 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2013-04-28 06:30-0400 Hezekiah M. Carty wrote: > >> On Fri, Mar 15, 2013 at 11:32 AM, Hezekiah M. Carty >> <hezekiahca...@users.sourceforge.net> wrote: >>> >>> On Tue, Jan 29, 2013 at 5:23 AM, Andrew Ross >>> <andrewr...@users.sourceforge.net> wrote: >>>> >>>> On Mon, Jan 28, 2013 at 06:31:42PM -0800, Alan Irwin wrote: >>>>> >>>>> >>>>> Of course, we would still be stuck with integer line widths for the >>>>> pllegend, plshade, and plshades API until we changed those width >>>>> arguments to PLFLT. But making such changes is tougher on our users >>>>> than the above 4 changes because we don't want to change the pllegend, >>>>> plshade, and plshades function names. So we could put that change off >>>>> until later, but if we are going to do the above 4 changes, it is >>>>> probably a good time to do the pllegend, plshade, and plshades API >>>>> changes as well (so long as we warn our users about this in the >>>>> release announcement and do the appropriate SOVERSION bump to force >>>>> them to recompile their applications/libraries.) But I emphasize this >>>>> is a separate issue that should not affect what we decide to do for >>>>> plwid. >>>> >>>> >>>> I agree the pllegend, plshade(s) issues are a bit more thorny. One >>>> advantage of changing now is that we can fix plcolorbar at least before >>>> we finalise the API. In C at least old code should work, perhaps >>>> with a warning, as the int will be cast to a float. On stricter >>>> compilers this might require an explicit cast. For some languages >>>> where function arguments can be overloaded we can provide both >>>> versions for a while. >>>> >>> >>> My vote goes to changing all of the impacted functions now. With the >>> removal of plwid and addition of plwidth, leaving integer line widths >>> elsewhere in the API is an ugly inconsistency. It is something I >>> expect we will want to change at some point so sooner - before another >>> release! - would be better than later. >>> >> >> I've finally had some time to look into this. I have a patch ready >> for the core library which updates pllegend, plcolorbar and the >> plshade*/plfshade* functions. >> >> This is a fairly disruptive change to the C API. At this point I can >> only commit to propagating these changes to the OCaml bindings. >> Before I make this commit is everyone OK with most language bindings >> breaking until these type changes have been propagated? > > Nobody else has responded so I think you are free to do what you want. > But to give you some guidance on that, I think you should just go > ahead and commit your change. Once I see that change, I will disable > all language bindings by default except for C and OCaml so that > default builds are not disrupted by your change. (Of course, if you > want to do that yourself as part of your commit, change ON to OFF > appropriately in the files indicated by the 'grep -il "option(ENABLE" > cmake/modules/*.cmake' command and then do a default build to make > sure there are no build errors for that case.) > > My time is limited as well, but once you have committed your change, I > will promise to make the appropriate further changes for Python and > Fortran (and enabling those by default once my changes build). > Presumably other core developers here will chime in as well for their > own favorite languages (crowd-sourcing works well for such cases) > until this C API change has been propagated to all our language > bindings. >
The C changes are in commit 12312 and the OCaml changes are in 12313. These commits cover all of the instances of line widths I found. I didn't bother changing C examples when the integer to floating point cast wouldn't matter to limit the noise in the commit. The output diff test between C and OCaml is clean aside from the missing plcolorbar calls in OCaml's example 16. Hez ------------------------------------------------------------------------------ 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
