On Aug 7, 2013, at 7:56 PM, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> wrote:
> On 2013-08-07 18:40-0700 Jerry wrote: > >> I've only glanced at these e-mails but want to make a quick response anyway. > >> I would be stunned if the GNAT version difference was causing this > because of being more careful about types. Ada has always been > rigorous about types. > >> I noted the API change at the time but assumed that this had been > discussed. Were no other languages affected? Do all the other PLplot > languages automatically convert types so that this did not appear as > an API change? > >> To answer to "if there is a simple fix" I need to know what we want > to present to the user as an API. Do we want to break backward > compatibility? If we want to keep backward compatibility then indeed a > new function is in order. It could be an overloaded function, however, > so that the same function name works depending on if the argument is > Integer or Long_Float; however, it would need to call a different C > routine. As I said, I haven't yet dug into this today so some of my > comments may have obvious answers. More later. > > Hi Jerry: > > To remind you of the background, the "Replace plwid everywhere by > plwidth" commit (revision 12288 that Orion referred to) was an > extremely broad change that created and used floating-point line > widths (for a changed function name (plwidth rather than plwid) rather > than the integer linewidths we had before with plwid that severely > limited line-width possibilities that were available for certain of > our devices. This widespread change was discussed on list at the time > and does consist of a backwards-incompatible API change as noted at > README.release. As a result of that discussion, plwid was moved to > src/pldeprecated.c which is completely ignored unless users > specifically ask for it using the -DPL_DEPRECATED=ON option. > > With regard to your last question, I think it would make the change a > little bit easier for your users if you provided an overloaded version > of the line width function that had integer arguments, but we haven't > done that for any other language (C++, Python, etc.) that has > overloading. My own feeling on this is that the integer line widths > are going to become more and more restrictive compared to what can > actually be done with floating line widths these days with modern > graphics libraries such as pango/cairo and Qt4. Therefore, "tough > love" may be the better approach for you to take with Ada users so you > break them of the habit of using integer line widths. But that is up > to you and the alternative of giving them a soft landing with > overloading is a reasonable choice as well in my opinion. I think I will put in the overload as long as you concur (and I guess you have). I assume that the change (to floats) is documented so users can know of the improvement and can opt for it if they want, and if the deprecated version goes away eventually then that should bother fewer people. > > Although your decision to give Ada users "tough love" or "soft landing" is an > important issue, it is a side issue compared to the issue of possible > Ada breakage which I want to turn to now. > > My widespread change mostly gave good test results, but there were > some exceptions such as Ada which broke. However, as far as I know > Andrew cleared up that Ada breakage (commit 12337, "Update Ada > bindings to change line width arguments from Integer to Long_Float in > pllegend and plshade.") Yes. And I also made a change at 12299 to fix a type in the actual plwidth functionality. pllegend is a new addition as I recall so "tough love" shouldn't be necessary. I don't think plshade is new. > Among other things, that fixed > bindings/ada/plplot.adb so that the incorrect integer type was changed > to the correct floating type for the new plwidth-related function. After > revision 12337 all worked well here with gnatgcc-4.6.3-14, but now > Orion apparently has found an additional issue with his (much) later > gnatgcc version. > > @Orion: just to confirm that, could you double-check you are testing > the latest revision of PLplot trunk that includes Andrew's revision > 12337 fixes for my widespread revision 12288 change? > > @Jerry: what gnatgcc version do you have access to and what > happens when you test latest PLplot trunk? I have three GNATs installed. I'm not sure what the difference is between these version requests (on gnat versus gcc), but here are the results. (1) The 2011 GPL from AdaCore: $ ./gnat --version GNAT GPL 2011 (20110419) $ ./gcc --version gcc (GCC) 4.5.3 20110419 for GNAT GPL 2011 (20110419) (2) The 2013 GPL from AdaCore: $ ./gnat --version GNAT GPL 2013 (20130314) $ ./gcc --version gcc (GCC) 4.7.4 20130416 for GNAT GPL 2013 (20130314) (3) FSF version $ ./gnat --version GNAT 4.8.0 $ ./gcc --version gcc (GCC) 4.8.0 You (Alan) might recall that a couple months ago I updated my compiler from the 2011 GPL to the 2013 GPL and was not able to build PLplot. Everyone said that I probably had spaces in a pathname somewhere but I couldn't find a problem. I set the problem aside and relied on the ability of gnatmake to compile any files that it needs when building other stuff. I think of this as a "side build." The side build works fine on a probably 2-3 month old trunk. As far as I know the 2011 GPL works fine on the same version from trunk. I have not tried to build with the 4.8.0 version. It seems like an obvious thing for me to do is to try again at least with 4.8.0 to see what happens. Jerry > > 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 > __________________________ ------------------------------------------------------------------------------ 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://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
