From: Alan W. I. <Ala...@gm...> - 2018-07-31 18:21:57
|
Hi Phil: I am moving this discussion to plplot-devel where it belongs. I think your backwards-incompatible changes [h,l,s ==> c1,c2,c3 changed member names] in the PLControlPt struct are likely a good idea since h,l,s was a misnomer. Nevertheless, those changes did cause important build problems in the Tk-related part of the build which I have now fixed (commit 94e2e5b01). Example 12 (which uses RGB interpolation) shows the effect of your change. The old code produced <http://plplot.org/examples-data/demo12/x12.01.png> which shows fairly discontinous colour results from 1982 to 1986, while the new code produces much smoother colour changes in that date range. So from this evidence I feel your change is a nice win. I previously said (in response to your question about how you should edit README.release): > I assume you will want to insert a paragraph concerning your change in a new section 2.8 of "Improvements relative to the previous release". Also, since you changed the semantics of the two functions (although not their API) for the RGB case you should probably specifically warn the users of this forthcoming release about that semantics change by adding a one-sentence new section 1.10 in "OFFICIAL NOTICES FOR USERS" that refers to your new section 2.8 for the details. Since your backwards-incompatible API change to the PLControlPt struct is going to cause build problems (just like it did in our Tk-related code) for the minority of our users who actually use that struct in their code, you should expand that suggested single sentence in 1.10 to warn users of this specific change to PLControlPt. I look forward to your commit with the suggested changes in README.release. Alan __________________________ Alan W. Irwin 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 __________________________ |
From: Phil R. <p.d...@gm...> - 2018-08-01 12:17:01
|
Hi Alan On 31 July 2018 at 19:21, Alan W. Irwin <Ala...@gm...> wrote: > Hi Phil: > > I am moving this discussion to plplot-devel where it belongs. Sorry, I hadn't realised we'd gotten off list. Thanks for moving it back. > > I think your backwards-incompatible changes [h,l,s ==> c1,c2,c3 > changed member names] in the PLControlPt struct are likely a good idea > since h,l,s was a misnomer. Nevertheless, those changes did cause > important build problems in the Tk-related part of the build which I > have now fixed (commit 94e2e5b01). Is this struct really part of our public API? It is not mentioned anywhere in the docs as far as I can tell so I presumed this was an internal use only structure. > > Example 12 (which uses RGB interpolation) shows the effect of your > change. The old code produced > <http://plplot.org/examples-data/demo12/x12.01.png> which shows fairly > discontinous colour results from 1982 to 1986, while the new code > produces much smoother colour changes in that date range. So from > this evidence I feel your change is a nice win. > > I previously said (in response to your question about how you > should edit README.release): > >> I assume you will want to insert a paragraph concerning > > your change in a new section 2.8 of "Improvements relative to the > previous release". Also, since you changed the semantics of the two > functions (although not their API) for the RGB case you should > probably specifically warn the users of this forthcoming release about > that semantics change by adding a one-sentence new section 1.10 in > "OFFICIAL NOTICES FOR USERS" that refers to your new section 2.8 for > the details. > > Since your backwards-incompatible API change to the PLControlPt struct is > going > to cause build problems (just like it did in our Tk-related code) > for the minority of our users who actually use that struct > in their code, you should expand that suggested single sentence in 1.10 to > warn users of this specific change to PLControlPt. > > I look forward to your commit with the suggested changes in README.release. They'll arrive this afternoon all being well. > > > Alan > __________________________ > Alan W. Irwin > > 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 > __________________________ |
From: Phil R. <p.d...@gm...> - 2018-08-01 12:21:48
|
Hi Again Alan >> >> I think your backwards-incompatible changes [h,l,s ==> c1,c2,c3 >> changed member names] in the PLControlPt struct are likely a good idea >> since h,l,s was a misnomer. Nevertheless, those changes did cause >> important build problems in the Tk-related part of the build which I >> have now fixed (commit 94e2e5b01). > > Is this struct really part of our public API? It is not mentioned > anywhere in the docs as far as I can tell so I presumed this was an > internal use only structure. I take it back - just found it in the docs regarding ABI |