From: Alan W. I. <ir...@be...> - 2013-01-29 03:05:41
|
On 2013-01-15 12:47+0800 Hǎiliàng Wáng wrote: > Hello, > > I'm plotting a small PDF graph (128x96) with cairopdf driver, and the > line width looks too thick with line width 1. > > To solve the problem, I modify the code within the cairo driver > (cairo.c) to set the the line width to 0.2 directly, and the result > looks pretty good. > > I have read the thread below so I know there is no plan to change > function plwid's parameter from int to float: > http://www.mail-archive.com/plp...@li.../msg00429.html > > I'm wondering if it is good idea to add another function to set the > line width with a ratio, e.g. void plwidr(double)? So that the real > line width becomes a product: linewidth*ratio. By default the ratio is > 1.0 so it will not affect the current user, but if the user want finer > line width, just set linewidth=1 and the ratio any floating point > value they want. Hi Hǎiliàng: I gave you a quick answer on plplot-general, but I think the rest of this discussion should be on plplot-devel. Please subscribe to that list (i.e., the current list) if you would like to participate further in that discussion. @Andrew: most of the rest of this is addressed to you. Since that quick answer I have looked more carefully at what external drawing libraries do. Our two best devices drivers are cairo (based on the pango and cairo external libraries) and qt (based on the Qt4 external libraries. It appears the cairo library uses a floating-point pen width which we currently specify by casting the PLplot integer width appropriately. Also, it appears from our qt code, that we propagate our linewidth to a call the Qt4 setWidth (documented at) http://harmattan-dev.nokia.com/docs/library/html/qt4/qpen.html#width which takes an integer width argument. But right next to that setWidth function they also define setWidthF which takes a floating-point pen width argument. So my guess is the Qt4 library made the same mistake as PLplot has done (integer width argument) but they fixed it later by allowing the setWidthF alternative of specifying a floating-point width. So here is what I suggest we do. 1. Define a new function plwidth just like plwid is done now but with a PLFLT line width argument. (Actually, I like the plwidth name better than plwid.) 2. Wherever plwid is called internally now change that to plwidth with approprate cast of the argument (which allows plwid to be moved to pldeprecated.c below). 3. Define plwid as void plwid(PLINT width) { plwidth( (PLFLT) width); } and move it to pldeprecated. 4. Propagate the floating point line width set by plwidth to each of our device drivers. That would immediately let users specify a 0.2 width for plwidth which would propagate directly to our cairo device driver. With some additional work (i.e., replacing setWidth with setWidthF everywhere) we could propagate floating-point pen widths to our qt device driver as well. @Andrew: do you see any issues with the above four changes? 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. 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 __________________________ |
From: Andrew R. <and...@us...> - 2013-01-29 10:23:51
|
On Mon, Jan 28, 2013 at 06:31:42PM -0800, Alan Irwin wrote: > On 2013-01-15 12:47+0800 H??ili??ng W??ng wrote: > > >Hello, > > > >I'm plotting a small PDF graph (128x96) with cairopdf driver, and the > >line width looks too thick with line width 1. > > > >To solve the problem, I modify the code within the cairo driver > >(cairo.c) to set the the line width to 0.2 directly, and the result > >looks pretty good. > > > >I have read the thread below so I know there is no plan to change > >function plwid's parameter from int to float: > >http://www.mail-archive.com/plp...@li.../msg00429.html > > > >I'm wondering if it is good idea to add another function to set the > >line width with a ratio, e.g. void plwidr(double)? So that the real > >line width becomes a product: linewidth*ratio. By default the ratio is > >1.0 so it will not affect the current user, but if the user want finer > >line width, just set linewidth=1 and the ratio any floating point > >value they want. > > Hi H??ili??ng: > > I gave you a quick answer on plplot-general, but I think the rest of > this discussion should be on plplot-devel. Please subscribe to that > list (i.e., the current list) if you would like to participate further > in that discussion. > > @Andrew: most of the rest of this is addressed to you. > > Since that quick answer I have looked more carefully at what external > drawing libraries do. Our two best devices drivers are cairo (based > on the pango and cairo external libraries) and qt (based on the Qt4 > external libraries. It appears the cairo library uses a floating-point > pen width which we currently specify by casting the PLplot integer > width appropriately. Also, it appears from our qt code, that we > propagate our linewidth to a call the Qt4 setWidth (documented at) > http://harmattan-dev.nokia.com/docs/library/html/qt4/qpen.html#width > which takes an integer width argument. But right next to that > setWidth function they also define setWidthF which takes a > floating-point pen width argument. So my guess is the Qt4 library > made the same mistake as PLplot has done (integer width argument) but > they fixed it later by allowing the setWidthF alternative of > specifying a floating-point width. > > So here is what I suggest we do. > > 1. Define a new function plwidth just like plwid is done now but with a PLFLT line > width argument. (Actually, I like the plwidth name better than plwid.) > > 2. Wherever plwid is called internally now change that to plwidth > with approprate cast of the argument (which allows plwid to > be moved to pldeprecated.c below). > > 3. Define plwid as > > void plwid(PLINT width) > { > plwidth( (PLFLT) width); > } > > and move it to pldeprecated. > > 4. Propagate the floating point line width set by plwidth to each of > our device drivers. That would immediately let users specify a 0.2 > width for plwidth which would propagate directly to our cairo device > driver. With some additional work (i.e., replacing setWidth with > setWidthF everywhere) we could propagate floating-point pen widths to > our qt device driver as well. > > @Andrew: do you see any issues with the above four changes? > > 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. Alan, I think this is the best plan. Clearly line with would be better as a float. I also think plwidth is a better name. I have no objections to 1-4 above. Some drivers (e.g. postscript) do use int internally, but I don't think that should be a problem with suitable casting. We might just want to check that small widths don't become zero and disappear. This is easily fixed though. 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. Andrew |
From: Alan W. I. <ir...@be...> - 2013-01-29 18:30:09
|
On 2013-01-29 10:23-0000 Andrew Ross wrote: > On Mon, Jan 28, 2013 at 06:31:42PM -0800, Alan Irwin wrote: >> On 2013-01-15 12:47+0800 H??ili??ng W??ng wrote: >> >>> Hello, >>> >>> I'm plotting a small PDF graph (128x96) with cairopdf driver, and the >>> line width looks too thick with line width 1. >>> >>> To solve the problem, I modify the code within the cairo driver >>> (cairo.c) to set the the line width to 0.2 directly, and the result >>> looks pretty good. >>> >>> I have read the thread below so I know there is no plan to change >>> function plwid's parameter from int to float: >>> http://www.mail-archive.com/plp...@li.../msg00429.html >>> >>> I'm wondering if it is good idea to add another function to set the >>> line width with a ratio, e.g. void plwidr(double)? So that the real >>> line width becomes a product: linewidth*ratio. By default the ratio is >>> 1.0 so it will not affect the current user, but if the user want finer >>> line width, just set linewidth=1 and the ratio any floating point >>> value they want. >> >> Hi H??ili??ng: >> >> I gave you a quick answer on plplot-general, but I think the rest of >> this discussion should be on plplot-devel. Please subscribe to that >> list (i.e., the current list) if you would like to participate further >> in that discussion. >> >> @Andrew: most of the rest of this is addressed to you. >> >> Since that quick answer I have looked more carefully at what external >> drawing libraries do. Our two best devices drivers are cairo (based >> on the pango and cairo external libraries) and qt (based on the Qt4 >> external libraries. It appears the cairo library uses a floating-point >> pen width which we currently specify by casting the PLplot integer >> width appropriately. Also, it appears from our qt code, that we >> propagate our linewidth to a call the Qt4 setWidth (documented at) >> http://harmattan-dev.nokia.com/docs/library/html/qt4/qpen.html#width >> which takes an integer width argument. But right next to that >> setWidth function they also define setWidthF which takes a >> floating-point pen width argument. So my guess is the Qt4 library >> made the same mistake as PLplot has done (integer width argument) but >> they fixed it later by allowing the setWidthF alternative of >> specifying a floating-point width. >> >> So here is what I suggest we do. >> >> 1. Define a new function plwidth just like plwid is done now but with a PLFLT line >> width argument. (Actually, I like the plwidth name better than plwid.) >> >> 2. Wherever plwid is called internally now change that to plwidth >> with approprate cast of the argument (which allows plwid to >> be moved to pldeprecated.c below). >> >> 3. Define plwid as >> >> void plwid(PLINT width) >> { >> plwidth( (PLFLT) width); >> } >> >> and move it to pldeprecated. >> >> 4. Propagate the floating point line width set by plwidth to each of >> our device drivers. That would immediately let users specify a 0.2 >> width for plwidth which would propagate directly to our cairo device >> driver. With some additional work (i.e., replacing setWidth with >> setWidthF everywhere) we could propagate floating-point pen widths to >> our qt device driver as well. >> >> @Andrew: do you see any issues with the above four changes? >> >> 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. > > Alan, > > I think this is the best plan. Clearly line with would be better as a > float. I also think plwidth is a better name. I have no objections to > 1-4 above. Some drivers (e.g. postscript) do use int internally, but I > don't think that should be a problem with suitable casting. We might > just want to check that small widths don't become zero and disappear. > This is easily fixed though. Thanks, Andrew, for your response. I think this is an important issue to fix, and we appear to be in agreement about how to do it so I will take responsibility for this part of the change. I am quite busy at the moment with the Time Ephemerides project, but I hope to squeeze in these plwid/plwidth changes in the next several weeks or so. Once that is done we can decide about the best way to deal with the similar integer ==> floating point width changes for the pllegend and plshade(s) API. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2013-01-30 04:54:29
|
Hi Andrew, Hez Jerry, and Hǎiliàng: @Hǎiliàng: the svn trunk version now supports widths < 1 for cairo devices (see discussion below). @Hez: Because of my plwidth core changes, the OCaml bindings will not build any more. More details below. To others here: use -DENABLE_ocaml=OFF for the svn trunk version until further notice. @Jerry: Ada builds okay but the results no longer agree with the corresponding C results for examples 1 and 2. I noticed some integers associated with pen widths in the Ada bindings, but I did not change those to PLFLT (or floating-point equivalent) because I was not sure of the Ada implications. However, if you deal with that issue, I think it is pretty likely that examples 1 and 2 will agree again with C. On 2013-01-29 10:30-0800 Alan W. Irwin wrote: > Thanks, Andrew, for your response. I think this is an important issue > to fix, and we appear to be in agreement about how to do it so I will > take responsibility for this part of the change. @Andrew: I decided to do this sooner rather than later, and it has generally gone well. I used find and sed to change all source code (except source code that had the term plwidgets in it for obvious reasons) to replace plwid with plwidth. I then did a number of other fixups such as using a PLFLT width in plstrm.h; dealing with specific wid ==> width issues that turned up for C++, Java, and lua (where the pl prefix is not used); and sorting out a small cairo device issue for widths less than 1. So far, I have tested these fairly intrusive changes with the test_noninteractive and test_interactive targets and all seems to be well (other than for OCaml, see below, and the minor Ada issues I mentioned to Jerry above). I have also done tests such as examples/c/x04c -dev xcairo -width 0.3 @Hǎiliàng: that works which indicates the issue you originally reported is solved, but please check the svn trunk version to make sure. I have committed the result as revision 12288. N.B. I know there are some integer ==> PLFLT pen width changes that should be done in various bindings such as the ones I mentioned to Jerry above. But currently most of these appear to be covered up by implicit casting. We need some systematic testing that e.g., -width 0.3 works for -dev xcairo for _non-C_ examples to find these instances and fix them. However, I won't have time for that so I will leave chasing those down to someone else. I do plan to still take responsibility for getting -width values less than 1. to give good results for the qt devices just like they now do for the cairo devices, and I also need to implement a plwid in pldeprecated.c for backward compatibility but that is about all I have time for. @Hez: The core changes generated build errors for the ocaml bindings so I made a number of adjustments to the OCaml bindings (such as defining a float plgwidth and float plwidth) to get the OCaml part of the build to work. I think I am closer than if you leave the ocaml bindings completely inconsistent with the PLplot core so I included these changes in the above commit. The current OCaml status is there is a build error (unless you use -DENABLE_ocaml=OFF): File "/home/software/plplot_svn/HEAD/build_dir/bindings/ocaml/plplot.ml", line 1111, characters 29-31: Error: This expression has type color_t * axis_options_t list * axis_options_t list * int * line_style_t * (plplot_axis_type -> float -> string) option but an expression was expected of type color_t * axis_options_t list * axis_options_t list * float * line_style_t * (plplot_axis_type -> float -> string) option But line 1111 in that file has nothing to do with line width in any way! Is there some sort of offset for line numbers reported by the OCaml compilers? Since I have no idea where that build error message is coming from I am stuck (and everybody else is stuck) with setting -DENABLE_ocaml=OFF for now. I think the changes I made in bindings/ocaml are pretty reasonable. What I tried to do was express all pen widths as PLFLT (or some floating-point equivalent) and plgwid ==> plgwidth (where plgwid is local to just the ocaml bindings) and plwid ==>plwidth. However, since I don't understand OCaml that well those changes were all done by rote. Do you have any idea what could be causing the above build issue? 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 __________________________ |
From: Hailiang W. <hwa...@gm...> - 2013-01-30 10:21:58
|
I have compiled and tested revision 12290 with my application, the new float line width works great! Thank you very much! Hǎiliàng On Wed, Jan 30, 2013 at 12:54 PM, Alan W. Irwin <ir...@be...> wrote: > Hi Andrew, Hez Jerry, and Hǎiliàng: > > @Hǎiliàng: the svn trunk version now supports widths < 1 > for cairo devices (see discussion below). > > @Hez: Because of my plwidth core changes, the OCaml bindings will > not build any more. More details below. > > To others here: use -DENABLE_ocaml=OFF for the svn trunk version > until further notice. > > @Jerry: Ada builds okay but the results no longer agree with the > corresponding C results for examples 1 and 2. I noticed some integers > associated with pen widths in the Ada bindings, but I did not change > those to PLFLT (or floating-point equivalent) because I was not sure > of the Ada implications. However, if you deal with that issue, I > think it is pretty likely that examples 1 and 2 will agree again with > C. > > > On 2013-01-29 10:30-0800 Alan W. Irwin wrote: > >> Thanks, Andrew, for your response. I think this is an important issue >> to fix, and we appear to be in agreement about how to do it so I will >> take responsibility for this part of the change. > > > @Andrew: I decided to do this sooner rather than later, and it has > generally gone well. I used find and sed to change all source code > (except source code that had the term plwidgets in it for obvious > reasons) to replace plwid with plwidth. I then did a number of other > fixups such as using a PLFLT width in plstrm.h; dealing > with specific wid ==> width issues that turned up for C++, Java, and > lua (where the pl prefix is not used); and sorting out a small > cairo device issue for widths less than 1. > > So far, I have tested these fairly intrusive changes with the > test_noninteractive and test_interactive targets and all seems > to be well (other than for OCaml, see below, and the minor > Ada issues I mentioned to Jerry above). I have also > done tests such as > > examples/c/x04c -dev xcairo -width 0.3 > > @Hǎiliàng: that works which indicates the issue you originally reported > is solved, but please check the svn trunk version to make sure. > > I have committed the result as revision 12288. > > N.B. I know there are some integer ==> PLFLT pen width changes that > should be done in various bindings such as the ones I mentioned to > Jerry above. But currently most of these appear to be covered up by > implicit casting. We need some systematic testing that e.g., -width > 0.3 works for -dev xcairo for _non-C_ examples to find these instances > and fix them. However, I won't have time for that so I will leave > chasing those down to someone else. > > I do plan to still take responsibility for getting -width values less > than 1. to give good results for the qt devices just like they now do > for the cairo devices, and I also need to implement a plwid in > pldeprecated.c for backward compatibility but that is about all I have > time for. > > @Hez: The core changes generated build errors for the ocaml bindings so > I made a number of adjustments to the OCaml > bindings (such as defining a float plgwidth and float plwidth) to get > the OCaml part of the build to work. I think I am closer than if you > leave the ocaml bindings completely inconsistent with the PLplot core so > I included these changes in the above commit. > > The current OCaml status is there is a build error (unless you use > -DENABLE_ocaml=OFF): > > File "/home/software/plplot_svn/HEAD/build_dir/bindings/ocaml/plplot.ml", > line 1111, characters 29-31: > Error: This expression has type > color_t * axis_options_t list * axis_options_t list * int * > line_style_t * (plplot_axis_type -> float -> string) option > but an expression was expected of type > color_t * axis_options_t list * axis_options_t list * float * > line_style_t * (plplot_axis_type -> float -> string) option > > But line 1111 in that file has nothing to do with line width in any way! > Is there some sort of offset for line numbers reported by the OCaml > compilers? > > Since I have no idea where that build error message is coming from I > am stuck (and everybody else is stuck) with setting -DENABLE_ocaml=OFF > for now. I think the changes I made in bindings/ocaml are pretty > reasonable. What I tried to do was express all pen widths as PLFLT (or > some floating-point equivalent) and plgwid ==> plgwidth (where plgwid > is local to just the ocaml bindings) and plwid ==>plwidth. However, > since I don't understand OCaml that well those changes were all done > by rote. Do you have any idea what could be causing the above build > issue? > > > 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 > __________________________ |
From: Alan W. I. <ir...@be...> - 2013-01-30 08:59:21
|
On 2013-01-29 20:54-0800 Alan W. Irwin wrote: > N.B. I know there are some integer ==> PLFLT pen width changes that > should be done in various bindings such as the ones I mentioned to > Jerry above. But currently most of these appear to be covered up by > implicit casting. We need some systematic testing that e.g., -width > 0.3 works for -dev xcairo for _non-C_ examples to find these instances > and fix them. However, I won't have time for that so I will leave > chasing those down to someone else. > > I do plan to still take responsibility for getting -width values less > than 1. to give good results for the qt devices just like they now do > for the cairo devices, and I also need to implement a plwid in > pldeprecated.c for backward compatibility but that is about all I have > time for. I have accomplished those two final goals of my floting-point pen width plan as of revision 12290. During testing of this revision I discovered one other qt issue which is that -width always applied a uniform pen width of 1.0 regardless of the value specified for width. e.g., -width 100. gave the same results -width 1.0 for qt devices. cairo devices did not have this issue. Because of this issue, to test the above qt changes by temporarily making a call to plwidth(0.2) from examples/c/x01c.c, and that gave very thin lines for all qt devices. That is, that way of applying a pen width change works fine for qt, but not via the -width command-line option for some reason. The status is floating point pen widths now fundamentally work well for our two best device drivers (qt and cairo). However, there are some known leftover issues that need to be polished up such as the qt issue with -width above, the Ada and OCaml issues I pointed out before, and the pllegend and plshade(s) API issues for pen width arguments we discussed previously. Also, this has been a quite intrusive change so undoubtedly there are some unknown issues that have been introduced as well by this change despite my good success with running the test_noninteractive and test_interactive targets. I am going to leave it to others here to polish up the rest of these issues because of constraints on how much time I can spend on PLplot. But I am very pleased that thin line widths < 1.0 work well now for both the cairo and qt devices drivers (our two best device drivers), and there are no obvious run-time issues that show up during all the tests associated with the test_noninteractive and test_interactive targets. 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 __________________________ |
From: Jerry <lan...@qw...> - 2013-01-30 09:48:08
|
On Jan 30, 2013, at 1:59 AM, Alan W. Irwin wrote: > However, there are > some known leftover issues that need to be polished up such as the qt > issue with -width above, the Ada and OCaml issues I pointed out > before I started on the Ada issues tonight but got distracted with a problem with the Aquaterm driver caused by a change I made on my computer. The Ada issues with plwidth look pretty trivial and I'll get to them soon. Jerry |
From: Hezekiah M. C. <hez...@us...> - 2013-03-15 10:17:42
|
On Tue, Jan 29, 2013 at 11:54 PM, Alan W. Irwin <ir...@be...> wrote: > @Hez: Because of my plwidth core changes, the OCaml bindings will > not build any more. More details below. > > To others here: use -DENABLE_ocaml=OFF for the svn trunk version > until further notice. > Thank you for going through most of the work required to update the OCaml bindings. I fixed the remaining binding issues with a commit last night so the OCaml bindings should build properly now. > @Hez: The core changes generated build errors for the ocaml bindings so > I made a number of adjustments to the OCaml > bindings (such as defining a float plgwidth and float plwidth) to get > the OCaml part of the build to work. I think I am closer than if you > leave the ocaml bindings completely inconsistent with the PLplot core so > I included these changes in the above commit. > Again, your changes were definitely a big help. The pieces that were still broken were in the high(er) level OCaml wrapper functions. > The current OCaml status is there is a build error (unless you use > -DENABLE_ocaml=OFF): > > File "/home/software/plplot_svn/HEAD/build_dir/bindings/ocaml/plplot.ml", > line 1111, characters 29-31: > Error: This expression has type > color_t * axis_options_t list * axis_options_t list * int * > line_style_t * (plplot_axis_type -> float -> string) option > but an expression was expected of type > color_t * axis_options_t list * axis_options_t list * float * > line_style_t * (plplot_axis_type -> float -> string) option > > But line 1111 in that file has nothing to do with line width in any way! > Is there some sort of offset for line numbers reported by the OCaml > compilers? > > Since I have no idea where that build error message is coming from I > am stuck (and everybody else is stuck) with setting -DENABLE_ocaml=OFF > for now. I think the changes I made in bindings/ocaml are pretty > reasonable. What I tried to do was express all pen widths as PLFLT (or > some floating-point equivalent) and plgwid ==> plgwidth (where plgwid > is local to just the ocaml bindings) and plwid ==>plwidth. However, > since I don't understand OCaml that well those changes were all done > by rote. Do you have any idea what could be causing the above build > issue? > The line width change caused type errors in a number of wrappers around PLplot functions. The OCaml bindings provide a way to build a plot as an ordered list of plot elements which can be passed off for rendering all at once. A number of these elements include line width information. OCaml is very strict with respect to type checking (ex. no automatic float <-> int conversion) so the line width change from an integer to a floating point value broke these elements until the types were changed to match the new pl(g)width functions. The rest of the changes were continuations of this theme - providing default values which are floating point rather than integer values and updating the examples accordingly. Thank you again Alan! Hez |
From: Hezekiah M. C. <hez...@us...> - 2013-03-15 15:39:26
|
On Tue, Jan 29, 2013 at 5:23 AM, Andrew Ross <and...@us...> 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. Hez |
From: Alan W. I. <ir...@be...> - 2013-03-15 16:40:00
|
On 2013-03-15 05:54-0400 Hezekiah M. Carty wrote: > On Tue, Jan 29, 2013 at 11:54 PM, Alan W. Irwin > <ir...@be...> wrote: >> @Hez: Because of my plwidth core changes, the OCaml bindings will >> not build any more. More details below. >> >> To others here: use -DENABLE_ocaml=OFF for the svn trunk version >> until further notice. >> > > Thank you for going through most of the work required to update the > OCaml bindings. I fixed the remaining binding issues with a commit > last night so the OCaml bindings should build properly now. @Hez: I confirm good OCaml results here with the test_noninteractive target. Thanks for completing my plwidth changes for OCaml! @Everybody here: It is recommended that you no longer specify -DENABLE_ocaml=OFF so that our ocaml bindings build by default. However, for some reason I can no longer even build our Ada bindings because of type inconsistencies concerning the plwidth changes so to get the above good results I had to specify -DENABLE_ada=OFF @Jerry: After the previously discussed conversion to Allura (which should start shortly), will you please take a look at the type inconsistencies introduced into our Ada bindings and examples by my plwidth changes? Thanks in advance. 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 __________________________ |
From: Atri <bad...@ai...> - 2013-03-18 19:49:09
Attachments:
plplot-fix-ada-with-plwidth.patch
|
Hi! To get the ada binding build successfully with the latest svn trunk (12298) (at least on openSUSE 12.2 and higher), I used the attached patch. Please have a look and let me know what you think. Thanks! -- Atri P.S.: Sorry for the top-post from a brain-dead web email client... -----Original Message----- From: Alan W. Irwin <ir...@be...> To: Hezekiah M. Carty <hez...@us...> Cc: PLplot development list <plp...@li...>; Andrew Ross <and...@us...>; Hǎiliàng Wáng <hwa...@gm...> Sent: Fri, Mar 15, 2013 11:40 am Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? On 2013-03-15 05:54-0400 Hezekiah M. Carty wrote: > On Tue, Jan 29, 2013 at 11:54 PM, Alan W. Irwin > <ir...@be...> wrote: >> @Hez: Because of my plwidth core changes, the OCaml bindings will >> not build any more. More details below. >> >> To others here: use -DENABLE_ocaml=OFF for the svn trunk version >> until further notice. >> > > Thank you for going through most of the work required to update the > OCaml bindings. I fixed the remaining binding issues with a commit > last night so the OCaml bindings should build properly now. @Hez: I confirm good OCaml results here with the test_noninteractive target. Thanks for completing my plwidth changes for OCaml! @Everybody here: It is recommended that you no longer specify -DENABLE_ocaml=OFF so that our ocaml bindings build by default. However, for some reason I can no longer even build our Ada bindings because of type inconsistencies concerning the plwidth changes so to get the above good results I had to specify -DENABLE_ada=OFF @Jerry: After the previously discussed conversion to Allura (which should start shortly), will you please take a look at the type inconsistencies introduced into our Ada bindings and examples by my plwidth changes? Thanks in advance. 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 __________________________ ------------------------------------------------------------------------- ----- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2013-03-19 03:59:48
Attachments:
plplot-fix-ada-with-plwidth.patch
|
On 2013-03-18 15:49-0400 Atri wrote: > Hi! > > To get the ada binding build successfully with the latest svn trunk (12298) > (at least on openSUSE 12.2 and higher), I used the attached patch. Please > have a look and let me know what you think. Hi Atri: I think that your patch does the job in the Ada bindings, but it appears you need to make similar changes in some/all of the Ada examples. The error message I get here is x01a.adb:101:17: expected type "Standard.Long_Float" x01a.adb:101:17: found type universal integer x01a.adb:103:17: expected type "Standard.Long_Float" x01a.adb:103:17: found type universal integer To verify this for yourself, try the following: Configure with the CMake option -DBUILD_TEST=ON Then after cmake is run, run the following target in the build tree: make VERBOSE=1 test_ada_psc >& test_ada_psc.out Thanks for your patch, and I look forward to seeing the complete version that gets rid of all errors in the test_ada_psc target. :-) 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 __________________________ |
From: Atri <bad...@ai...> - 2013-03-20 00:31:49
Attachments:
plplot-fix-plwidth-ada-binding.patch
|
Hello Alan! This is the updated patch that should take care of the problems with the examples in ada as well (I only had to correct four of the examples). After applying the patch, I built plplot with ada binding turned on, with DBUILD_TEST=ON and did a "make VERBOSE=1 test_ada_psc" just as you asked. The package, along with all the examples now builds fine. The examples that needed correcting are: x01a.adb x02a.adb xthick01a.adb xthick02a.adb Please let me know if this is okay. -- Atri -----Original Message----- From: Alan W. Irwin <ir...@be...> To: Atri <bad...@ai...> Cc: Jerry <lan...@qw...>; hezekiahcarty <hez...@us...>; PLplot development list <plp...@li...>; Andrew Ross <and...@us...>; hwang.dev <hwa...@gm...> Sent: Mon, Mar 18, 2013 10:59 pm Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? On 2013-03-18 15:49-0400 Atri wrote: > Hi! > > To get the ada binding build successfully with the latest svn trunk (12298) > (at least on openSUSE 12.2 and higher), I used the attached patch. Please > have a look and let me know what you think. Hi Atri: I think that your patch does the job in the Ada bindings, but it appears you need to make similar changes in some/all of the Ada examples. The error message I get here is x01a.adb:101:17: expected type "Standard.Long_Float" x01a.adb:101:17: found type universal integer x01a.adb:103:17: expected type "Standard.Long_Float" x01a.adb:103:17: found type universal integer To verify this for yourself, try the following: Configure with the CMake option -DBUILD_TEST=ON Then after cmake is run, run the following target in the build tree: make VERBOSE=1 test_ada_psc >& test_ada_psc.out Thanks for your patch, and I look forward to seeing the complete version that gets rid of all errors in the test_ada_psc target. :-) 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 __________________________ |
From: Jerry <lan...@qw...> - 2013-03-20 00:55:55
|
I just committed probably the same changes just minutes ago. I'm building fine on my end (OS X) now. Thanks for your help, Atri. Sorry I didn't take care of this sooner. Jerry On Mar 19, 2013, at 5:31 PM, Atri wrote: > Hello Alan! > This is the updated patch that should take care of the problems with the examples in ada as well (I only had to correct four of the examples). After applying the patch, I built plplot with ada binding turned on, with DBUILD_TEST=ON and did a "make VERBOSE=1 test_ada_psc" just as you asked. The package, along with all the examples now builds fine. The examples that needed correcting are: > x01a.adb > x02a.adb > xthick01a.adb > xthick02a.adb > > Please let me know if this is okay. > > -- > Atri > > > -----Original Message----- > From: Alan W. Irwin <ir...@be...> > To: Atri <bad...@ai...> > Cc: Jerry <lan...@qw...>; hezekiahcarty <hez...@us...>; PLplot development list <plp...@li...>; Andrew Ross <and...@us...>; hwang.dev <hwa...@gm...> > Sent: Mon, Mar 18, 2013 10:59 pm > Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? > > > On 2013-03-18 15:49-0400 Atri wrote: > >> Hi! >> >> To get the ada binding build successfully with the latest svn trunk > (12298) >> (at least on openSUSE 12.2 and higher), I used the attached patch. > Please >> have a look and let me know what you think. > > Hi Atri: > > I think that your patch does the job in the Ada bindings, but it appears you > need to make similar changes in some/all of the Ada examples. > > The error message I get here is > > x01a.adb:101:17: expected type "Standard.Long_Float" > x01a.adb:101:17: found type universal integer > x01a.adb:103:17: expected type "Standard.Long_Float" > x01a.adb:103:17: found type universal integer > > To verify this for yourself, try the following: > > Configure with the CMake option -DBUILD_TEST=ON > > Then after cmake is run, run the following target in > the build tree: > > make VERBOSE=1 test_ada_psc >& test_ada_psc.out > > Thanks for your patch, and I look forward to seeing the complete > version that gets rid of all errors in the test_ada_psc target. :-) > > 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 > __________________________ > > <plplot-fix-plwidth-ada-binding.patch> |
From: Jerry <lan...@qw...> - 2013-03-20 00:55:58
|
Atri, I'll give you an answer later this evening. I have an urgent thing to do right now. Jerry On Mar 19, 2013, at 5:44 PM, Atri wrote: > Thanks Jerry! > > However, I am a little confused as I do not see the examples having being patched with revision 12299 yet; isn't that supposed to be done as I did in the patch (attached with previous email) as well? Otherwise building the examples would lead to issues as Alan pointed out earlier. > > -- > Atri > > > -----Original Message----- > From: Jerry <lan...@qw...> > To: Atri <bad...@ai...> > Cc: Alan Irwin <ir...@be...>; Plplot-devel mailing list <plp...@li...> > Sent: Tue, Mar 19, 2013 7:37 pm > Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? > > > I just committed probably the same changes just minutes ago. I'm building fine > on my end (OS X) now. Thanks for your help, Atri. Sorry I didn't take care of > this sooner. > Jerry > > On Mar 19, 2013, at 5:31 PM, Atri wrote: > >> Hello Alan! >> This is the updated patch that should take care of the problems with > the > examples in ada as well (I only had to correct four of the examples). After > applying the patch, I built plplot with ada binding turned on, with > DBUILD_TEST=ON and did a "make VERBOSE=1 test_ada_psc" just as you asked. The > package, along with all the examples now builds fine. The examples that needed > correcting are: >> x01a.adb >> x02a.adb >> xthick01a.adb >> xthick02a.adb >> >> Please let me know if this is okay. >> >> -- >> Atri >> >> >> -----Original Message----- >> From: Alan W. Irwin <ir...@be...> >> To: Atri <bad...@ai...> >> Cc: Jerry <lan...@qw...>; hezekiahcarty > <hez...@us...>; > PLplot development list <plp...@li...>; Andrew Ross > <and...@us...>; hwang.dev <hwa...@gm...> >> Sent: Mon, Mar 18, 2013 10:59 pm >> Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be > supported? >> >> >> On 2013-03-18 15:49-0400 Atri wrote: >> >>> Hi! >>> >>> To get the ada binding build successfully with the latest svn trunk >> (12298) >>> (at least on openSUSE 12.2 and higher), I used the attached patch. >> Please >>> have a look and let me know what you think. >> >> Hi Atri: >> >> I think that your patch does the job in the Ada bindings, but it > appears you >> need to make similar changes in some/all of the Ada examples. >> >> The error message I get here is >> >> x01a.adb:101:17: expected type "Standard.Long_Float" >> x01a.adb:101:17: found type universal integer >> x01a.adb:103:17: expected type "Standard.Long_Float" >> x01a.adb:103:17: found type universal integer >> >> To verify this for yourself, try the following: >> >> Configure with the CMake option -DBUILD_TEST=ON >> >> Then after cmake is run, run the following target in >> the build tree: >> >> make VERBOSE=1 test_ada_psc >& test_ada_psc.out >> >> Thanks for your patch, and I look forward to seeing the complete >> version that gets rid of all errors in the test_ada_psc target. :-) >> >> 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 >> __________________________ >> >> <plplot-fix-plwidth-ada-binding.patch> > > > |
From: Jerry <lan...@qw...> - 2013-03-20 06:06:30
|
Hi Atri, I was in a bit of a hurry when I did the commit and failed to include all of the changed files. 12300 should be OK. Alan is already reporting good results. Jerry On Mar 19, 2013, at 5:46 PM, Jerry wrote: > Atri, > > I'll give you an answer later this evening. I have an urgent thing to do right now. > > Jerry > > On Mar 19, 2013, at 5:44 PM, Atri wrote: > >> Thanks Jerry! >> >> However, I am a little confused as I do not see the examples having being patched with revision 12299 yet; isn't that supposed to be done as I did in the patch (attached with previous email) as well? Otherwise building the examples would lead to issues as Alan pointed out earlier. >> >> -- >> Atri >> >> >> -----Original Message----- >> From: Jerry <lan...@qw...> >> To: Atri <bad...@ai...> >> Cc: Alan Irwin <ir...@be...>; Plplot-devel mailing list <plp...@li...> >> Sent: Tue, Mar 19, 2013 7:37 pm >> Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? >> >> >> I just committed probably the same changes just minutes ago. I'm building fine >> on my end (OS X) now. Thanks for your help, Atri. Sorry I didn't take care of >> this sooner. >> Jerry >> >> On Mar 19, 2013, at 5:31 PM, Atri wrote: >> >>> Hello Alan! >>> This is the updated patch that should take care of the problems with >> the >> examples in ada as well (I only had to correct four of the examples). After >> applying the patch, I built plplot with ada binding turned on, with >> DBUILD_TEST=ON and did a "make VERBOSE=1 test_ada_psc" just as you asked. The >> package, along with all the examples now builds fine. The examples that needed >> correcting are: >>> x01a.adb >>> x02a.adb >>> xthick01a.adb >>> xthick02a.adb >>> >>> Please let me know if this is okay. >>> >>> -- >>> Atri >>> >>> >>> -----Original Message----- >>> From: Alan W. Irwin <ir...@be...> >>> To: Atri <bad...@ai...> >>> Cc: Jerry <lan...@qw...>; hezekiahcarty >> <hez...@us...>; >> PLplot development list <plp...@li...>; Andrew Ross >> <and...@us...>; hwang.dev <hwa...@gm...> >>> Sent: Mon, Mar 18, 2013 10:59 pm >>> Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be >> supported? >>> >>> >>> On 2013-03-18 15:49-0400 Atri wrote: >>> >>>> Hi! >>>> >>>> To get the ada binding build successfully with the latest svn trunk >>> (12298) >>>> (at least on openSUSE 12.2 and higher), I used the attached patch. >>> Please >>>> have a look and let me know what you think. >>> >>> Hi Atri: >>> >>> I think that your patch does the job in the Ada bindings, but it >> appears you >>> need to make similar changes in some/all of the Ada examples. >>> >>> The error message I get here is >>> >>> x01a.adb:101:17: expected type "Standard.Long_Float" >>> x01a.adb:101:17: found type universal integer >>> x01a.adb:103:17: expected type "Standard.Long_Float" >>> x01a.adb:103:17: found type universal integer >>> >>> To verify this for yourself, try the following: >>> >>> Configure with the CMake option -DBUILD_TEST=ON >>> >>> Then after cmake is run, run the following target in >>> the build tree: >>> >>> make VERBOSE=1 test_ada_psc >& test_ada_psc.out >>> >>> Thanks for your patch, and I look forward to seeing the complete >>> version that gets rid of all errors in the test_ada_psc target. :-) >>> >>> 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 >>> __________________________ >>> >>> <plplot-fix-plwidth-ada-binding.patch> >> >> >> > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Atri <bad...@ai...> - 2013-03-20 01:06:36
|
Thanks Jerry! However, I am a little confused as I do not see the examples having being patched with revision 12299 yet; isn't that supposed to be done as I did in the patch (attached with previous email) as well? Otherwise building the examples would lead to issues as Alan pointed out earlier. -- Atri -----Original Message----- From: Jerry <lan...@qw...> To: Atri <bad...@ai...> Cc: Alan Irwin <ir...@be...>; Plplot-devel mailing list <plp...@li...> Sent: Tue, Mar 19, 2013 7:37 pm Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? I just committed probably the same changes just minutes ago. I'm building fine on my end (OS X) now. Thanks for your help, Atri. Sorry I didn't take care of this sooner. Jerry On Mar 19, 2013, at 5:31 PM, Atri wrote: > Hello Alan! > This is the updated patch that should take care of the problems with the examples in ada as well (I only had to correct four of the examples). After applying the patch, I built plplot with ada binding turned on, with DBUILD_TEST=ON and did a "make VERBOSE=1 test_ada_psc" just as you asked. The package, along with all the examples now builds fine. The examples that needed correcting are: > x01a.adb > x02a.adb > xthick01a.adb > xthick02a.adb > > Please let me know if this is okay. > > -- > Atri > > > -----Original Message----- > From: Alan W. Irwin <ir...@be...> > To: Atri <bad...@ai...> > Cc: Jerry <lan...@qw...>; hezekiahcarty <hez...@us...>; PLplot development list <plp...@li...>; Andrew Ross <and...@us...>; hwang.dev <hwa...@gm...> > Sent: Mon, Mar 18, 2013 10:59 pm > Subject: Re: [Plplot-devel] Should line width thinner than 1.0 be supported? > > > On 2013-03-18 15:49-0400 Atri wrote: > >> Hi! >> >> To get the ada binding build successfully with the latest svn trunk > (12298) >> (at least on openSUSE 12.2 and higher), I used the attached patch. > Please >> have a look and let me know what you think. > > Hi Atri: > > I think that your patch does the job in the Ada bindings, but it appears you > need to make similar changes in some/all of the Ada examples. > > The error message I get here is > > x01a.adb:101:17: expected type "Standard.Long_Float" > x01a.adb:101:17: found type universal integer > x01a.adb:103:17: expected type "Standard.Long_Float" > x01a.adb:103:17: found type universal integer > > To verify this for yourself, try the following: > > Configure with the CMake option -DBUILD_TEST=ON > > Then after cmake is run, run the following target in > the build tree: > > make VERBOSE=1 test_ada_psc >& test_ada_psc.out > > Thanks for your patch, and I look forward to seeing the complete > version that gets rid of all errors in the test_ada_psc target. :-) > > 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 > __________________________ > > <plplot-fix-plwidth-ada-binding.patch> |
From: Alan W. I. <ir...@be...> - 2013-03-20 02:59:14
|
On 2013-03-19 20:44-0400 Atri wrote: > Thanks Jerry! > > However, I am a little confused as I do not see the examples having being > patched with revision 12299 yet; isn't that supposed to be done as I did in > the patch (attached with previous email) as well? Otherwise building the > examples would lead to issues as Alan pointed out earlier. Hi Atri: Jerry's second commit (revision 12300) works fine for me here. So did your second patch which I was about to commit when Jerry beat me to it with his own commit. Sorry we ended up not using your work, but that is the way it goes sometimes and thanks very much for your contribution of the patch. 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 __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2013-04-28 10:31:08
|
On Fri, Mar 15, 2013 at 11:32 AM, Hezekiah M. Carty <hez...@us...> wrote: > On Tue, Jan 29, 2013 at 5:23 AM, Andrew Ross > <and...@us...> 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? Hez |
From: Alan W. I. <ir...@be...> - 2013-04-30 02:34:38
|
On 2013-04-28 06:30-0400 Hezekiah M. Carty wrote: > On Fri, Mar 15, 2013 at 11:32 AM, Hezekiah M. Carty > <hez...@us...> wrote: >> On Tue, Jan 29, 2013 at 5:23 AM, Andrew Ross >> <and...@us...> 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? Hi Hez: 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. 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 release cycle. 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 __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2013-05-01 01:17:49
|
On Mon, Apr 29, 2013 at 10:34 PM, Alan W. Irwin <ir...@be...> wrote: > On 2013-04-28 06:30-0400 Hezekiah M. Carty wrote: > >> On Fri, Mar 15, 2013 at 11:32 AM, Hezekiah M. Carty >> <hez...@us...> wrote: >>> >>> On Tue, Jan 29, 2013 at 5:23 AM, Andrew Ross >>> <and...@us...> 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 |
From: Alan W. I. <ir...@be...> - 2013-05-01 04:42:51
|
On 2013-04-30 21:17-0400 Hezekiah M. Carty wrote: > > 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. Thanks Hez: I also confirm good OCaml results here. > [different order] On Mon, Apr 29, 2013 at 10:34 PM, Alan W. Irwin > <ir...@be...> wrote: >> Once I see that change [from you], I will disable >> all language bindings by default except for C and OCaml so that >> default builds are not disrupted by your change. DONE as of revision 12314. Just to be clear here, this change only affects users who do not specify any -DENABLE_????=ON options, i.e., those that take the default bindings (which are now only ocaml due to this revision 12314 change to avoid default build breakage for our remaining bindings). To enable these bindings again by default for their language of choice, let's take Ada as an example. The interested developer for that language (probably Jerry) should propagate Hez's recent integer ==> double line width changes in the C API for pl*shade*, pllegend, and plcolorbar to the Ada bindings and make the corresponding changes in the Ada examples 4, 16, 26, and 33 to use that changed API. They should then test that result (at least by running the test_noninteractive target) with the language specifically enabled, e.g., with the -DENABLE_ada=ON option. If that testing works, then the final step is to enable the language by default again using the appropriate change in cmake/modules/ada.cmake, then commit all the changes. I have changed my mind about the choice of languages where I will propagate Hez's changes. Before I said I would do Python and Fortran, but now I will focus on the languages whose bindings are swig-generated (i.e., Python, Java, lua, and octave) since it makes sense to do all those at the same time. So I will be taking on more languages than I said before, but it does leave Fortran (and the rest of the bindings) to others here. Also, to the developer who takes on Fortran, I suggest you propagate only to Fortran 95 since we will soon be withdrawing the deprecated Fortran 77. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2013-05-01 10:21:25
|
Hi Alan, I made a quick inventory of the functions involved and of the functions that have not been implemented yet in the (Fortran) bindings. It should not be too much work and I will try to do the changes tonight for Fortran and Tcl, unless someone beat me to it. Regards, Arjen On Tue, 30 Apr 2013 21:42:40 -0700 (PDT) "Alan W. Irwin" <ir...@be...> wrote: ... > sense to do all those at the same time. So I will be >taking on more > languages than I said before, but it does leave Fortran >(and the rest > of the bindings) to others here. Also, to the developer >who takes on >Fortran, I suggest you propagate only to Fortran 95 since >we will soon > be withdrawing the deprecated Fortran 77. > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Hailiang W. <hwa...@gm...> - 2013-01-29 12:24:06
|
It is great to have float line width in the future release! Thanks! Hǎiliàng > Hi Hǎiliàng: > > I gave you a quick answer on plplot-general, but I think the rest of > this discussion should be on plplot-devel. Please subscribe to that > list (i.e., the current list) if you would like to participate further > in that discussion. > > @Andrew: most of the rest of this is addressed to you. > > Since that quick answer I have looked more carefully at what external > drawing libraries do. Our two best devices drivers are cairo (based > on the pango and cairo external libraries) and qt (based on the Qt4 > external libraries. It appears the cairo library uses a floating-point > pen width which we currently specify by casting the PLplot integer > width appropriately. Also, it appears from our qt code, that we > propagate our linewidth to a call the Qt4 setWidth (documented at) > http://harmattan-dev.nokia.com/docs/library/html/qt4/qpen.html#width > which takes an integer width argument. But right next to that > setWidth function they also define setWidthF which takes a > floating-point pen width argument. So my guess is the Qt4 library > made the same mistake as PLplot has done (integer width argument) but > they fixed it later by allowing the setWidthF alternative of > specifying a floating-point width. > > So here is what I suggest we do. > > 1. Define a new function plwidth just like plwid is done now but with a > PLFLT line > width argument. (Actually, I like the plwidth name better than plwid.) > > 2. Wherever plwid is called internally now change that to plwidth > with approprate cast of the argument (which allows plwid to > be moved to pldeprecated.c below). > > 3. Define plwid as > > void plwid(PLINT width) > { > plwidth( (PLFLT) width); > } > > and move it to pldeprecated. > > 4. Propagate the floating point line width set by plwidth to each of > our device drivers. That would immediately let users specify a 0.2 > width for plwidth which would propagate directly to our cairo device > driver. With some additional work (i.e., replacing setWidth with > setWidthF everywhere) we could propagate floating-point pen widths to > our qt device driver as well. > > @Andrew: do you see any issues with the above four changes? > > 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. > > > 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 > __________________________ |