On 2013-04-28 06:30-0400 Hezekiah M. Carty wrote:
> On Fri, Mar 15, 2013 at 11:32 AM, Hezekiah M. Carty
> <hezekiahcarty@...> wrote:
>> On Tue, Jan 29, 2013 at 5:23 AM, Andrew Ross
>> <andrewross@...> 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
>>> 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
Of course, the key is to initiate the process, and I am glad you are
willing to do that so we can get this issue taken care of in this
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).