Re: [Plplot-devel] 5.9.7 release timing
Hi Alan, I had not used that set-up in a while and I do not worry too much about the second page (indeed a font issue). What I did see - on that particular display - is a slight but distinct difference between the background of the plot and that of the legend. You may not notice it, but it is there, whereas I thought the very same colour should have been used. Regards, Arjen On 2010-10-03 17:31, Alan W. Irwin wrote: On 2010-10-03 15:46+0200 Arjen Markus wrote: Hello Hazen, Alan, all, I have just built and tested PLplot in a very old environment (Windows XP with MSVC 6.0 as the C compiler) and I had to correct the wingcc.c file for lack of SetWindowLongPtr() and GetWindowLongPtr() in that set-up. While this worked, I did get some weird results with pllegend(): - The background is not exactly the background of the plot - The second page of example x26 is mangled. Hi Arjen: Thanks for your tests. The first page of 26 is fine; the pllegend API allows you to apply a background to the legend which I have done in example 4 and example 26. The second page is fine as well in the sense it is consistent with the bad results for xwin here which is completely unaware of unicode. So count your test result in the good column for this release. I mentioned the example 26 issue (extra large legend background) you see with all device drivers in the recent pllegend discussion. The horizontal space for the annotated strings is calculated internally by plstrl, but that routine currently has no idea about utf-8 (what the Russian strings of page 2 are written in) and thus grossly overestimates the space involved because it assumes every utf-8 byte is a (Hershey) character. The solution is to convert utf8 to UCS4 (like all other string input routines do), and for unicode aware drivers (e.g, svg, qt, cairo, and wingcc) have a variation on the normal (unicode) text processing that allows the driver to calculate how much length that UCS4 string will require to be rendered without actually doing that rendering. That improvement should make the legend size exact for the unicode case, and more reasonable for the Hershey case. Another issue with your wingcc results is it uses the plfreetype method of rendering unicode that depends directly on the freetype library. That is available for Windows as part of the Windows GTK+ package, but it appears from the example 26 results that you have not downloaded that package so wingcc has fallen back to using Hershey fonts instead (which give a blank for all unicode characters just like you get for xwin). 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); PLplot scientific plotting software package (plplot.org); 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 __ 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. -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On 2010-10-03 15:46+0200 Arjen Markus wrote: Hello Hazen, Alan, all, I have just built and tested PLplot in a very old environment (Windows XP with MSVC 6.0 as the C compiler) and I had to correct the wingcc.c file for lack of SetWindowLongPtr() and GetWindowLongPtr() in that set-up. While this worked, I did get some weird results with pllegend(): - The background is not exactly the background of the plot - The second page of example x26 is mangled. Hi Arjen: Thanks for your tests. The first page of 26 is fine; the pllegend API allows you to apply a background to the legend which I have done in example 4 and example 26. The second page is fine as well in the sense it is consistent with the bad results for xwin here which is completely unaware of unicode. So count your test result in the good column for this release. I mentioned the example 26 issue (extra large legend background) you see with all device drivers in the recent pllegend discussion. The horizontal space for the annotated strings is calculated internally by plstrl, but that routine currently has no idea about utf-8 (what the Russian strings of page 2 are written in) and thus grossly overestimates the space involved because it assumes every utf-8 byte is a (Hershey) character. The solution is to convert utf8 to UCS4 (like all other string input routines do), and for unicode aware drivers (e.g, svg, qt, cairo, and wingcc) have a variation on the normal (unicode) text processing that allows the driver to calculate how much length that UCS4 string will require to be rendered without actually doing that rendering. That improvement should make the legend size exact for the unicode case, and more reasonable for the Hershey case. Another issue with your wingcc results is it uses the plfreetype method of rendering unicode that depends directly on the freetype library. That is available for Windows as part of the Windows GTK+ package, but it appears from the example 26 results that you have not downloaded that package so wingcc has fallen back to using Hershey fonts instead (which give a blank for all unicode characters just like you get for xwin). 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); PLplot scientific plotting software package (plplot.org); 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 __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On 2010-09-24 12:45-0400 Hazen Babcock wrote: Alan W. Irwin wrote: [...]Is the 5.9.7 development release still on for next weekend? Yep, assuming that there are no objections. Hi Hazen: For those who might be doing some last-minute documentation (probably not me since I hope to finish the pllegend docbook documentation today) what day this weekend and what approximate time of day do you plan to start the release process? I was about to give you a shopping list of on-going development that would justify making the next release cycle our normal longer development cycle. For example, we need to work on plcolorbar to complement pllegend. Also, the misaligned legend results for example 26 show a lot of work needs to be done so that plstrl gives the correct string-size results for unicode-aware device drivers. However, when I checked records, it turns out our last stable release (5.8.0) was almost three years ago! Thus, we have been putting off the release of 5.10.0 for much too long a time (probably mostly due to my requests for more development release cycles). But, of course, on-going development can always be used to put off stable releases so if we don't do a stable release soon, we may never do so. Furthermore, I think we could benefit from a short stable release cycle where we concentrated exclusively on testing, bug fixing, API propagation, and documentation and where the developers made a commitment not to commit any new core development work to svn trunk during that short cycle. The first obvious question, Hazen, concerning this possibility is whether or not you can commit to a short release cycle (say with a release of 5.10.0 two or three weeks from the release of 5.9.7 this weekend)? Assuming that short time scale is possible for the next release, what do the other developers here think about this possibility? Would you be against it (because you have a lot you want to develop and waiting through a stable release cycle disrupts your plans); go along with it without participating because of other time-commitments during the next few weeks (obviously no shame is attached to that because of the extremely short notice); or would you be for it implying you could contribute some testing, bug fixing, etc., help during that time? I would be for it since I could use a week or two to properly test PLplot using MinGW under wine, and I hope others would be willing to participate as well (say by propagating pllegend to various languages and updating examples 4 and 26 in those languages earlier in the release cycle and/or running scripts/comprehensive_test.sh for their platform and reporting the results on our Wiki later in the release cycle). Note the above proposed moratorium on _core_ development (i.e., changes to libplplotd) during this short release cycle does not apply to language changes. For example, I am aware from off-list discussions with Jerry that he has some Ada changes planned, and I think those would be fine so long as he completed them early in the release cycle so that those changes got full testing later in the 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); PLplot scientific plotting software package (plplot.org); 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 __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
Alan W. Irwin wrote: On 2010-09-24 12:45-0400 Hazen Babcock wrote: Alan W. Irwin wrote: [...]Is the 5.9.7 development release still on for next weekend? Yep, assuming that there are no objections. Hi Hazen: For those who might be doing some last-minute documentation (probably not me since I hope to finish the pllegend docbook documentation today) what day this weekend and what approximate time of day do you plan to start the release process? I'm planning on doing this tomorrow (Saturday, October 2nd) morning (EST), but see discussion below. I was about to give you a shopping list of on-going development that would justify making the next release cycle our normal longer development cycle. For example, we need to work on plcolorbar to complement pllegend. Also, the misaligned legend results for example 26 show a lot of work needs to be done so that plstrl gives the correct string-size results for unicode-aware device drivers. However, when I checked records, it turns out our last stable release (5.8.0) was almost three years ago! Thus, we have been putting off the release of 5.10.0 for much too long a time (probably mostly due to my requests for more development release cycles). But, of course, on-going development can always be used to put off stable releases so if we don't do a stable release soon, we may never do so. Furthermore, I think we could benefit from a short stable release cycle where we concentrated exclusively on testing, bug fixing, API propagation, and documentation and where the developers made a commitment not to commit any new core development work to svn trunk during that short cycle. The first obvious question, Hazen, concerning this possibility is whether or not you can commit to a short release cycle (say with a release of 5.10.0 two or three weeks from the release of 5.9.7 this weekend)? That would probably be possible, but.. Assuming that short time scale is possible for the next release, what do the other developers here think about this possibility? Would you be against it (because you have a lot you want to develop and waiting through a stable release cycle disrupts your plans); go along with it without participating because of other time-commitments during the next few weeks (obviously no shame is attached to that because of the extremely short notice); or would you be for it implying you could contribute some testing, bug fixing, etc., help during that time? I am against it, unless we can get pllegend (and plsmema) propogated to all the languages before then (as you mentioned below). Also I feel that the pllegend API should be stable, and I don't have the sense that it is right now. At the rate these things seem to happen I would guess this will take a month or more. Then there is the question of whether we'd like one more development release to make sure we are comfortable with pllegend prior to a stable release. I'd propose either: (1) Another dev release 1-2 months after 5.9.7, followed shortly there after by 5.10.0. (2) Hold off on 5.9.7 for another 1-2 months. In either case we would attempt to restrict our activities between the dev release and the stable release as you suggest. I would be for it since I could use a week or two to properly test PLplot using MinGW under wine, and I hope others would be willing to participate as well (say by propagating pllegend to various languages and updating examples 4 and 26 in those languages earlier in the release cycle and/or running scripts/comprehensive_test.sh for their platform and reporting the results on our Wiki later in the release cycle). -Hazen -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On Oct 1, 2010, at 7:12 PM, Hazen Babcock wrote: Alan W. Irwin wrote: On 2010-09-24 12:45-0400 Hazen Babcock wrote: Alan W. Irwin wrote: [...]Is the 5.9.7 development release still on for next weekend? Yep, assuming that there are no objections. Hi Hazen: For those who might be doing some last-minute documentation (probably not me since I hope to finish the pllegend docbook documentation today) what day this weekend and what approximate time of day do you plan to start the release process? I'm planning on doing this tomorrow (Saturday, October 2nd) morning (EST), but see discussion below. Sorry about this, but Sunday now morning looks like it will work better for me. Assuming that short time scale is possible for the next release, what do the other developers here think about this possibility? Would you be against it (because you have a lot you want to develop and waiting through a stable release cycle disrupts your plans); go along with it without participating because of other time-commitments during the next few weeks (obviously no shame is attached to that because of the extremely short notice); or would you be for it implying you could contribute some testing, bug fixing, etc., help during that time? I am against it, unless we can get pllegend (and plsmema) propogated to all the languages before then (as you mentioned below). Also I feel that the pllegend API should be stable, and I don't have the sense that it is right now. At the rate these things seem to happen I would guess this will take a month or more. Then there is the question of whether we'd like one more development release to make sure we are comfortable with pllegend prior to a stable release. We might also need to propogate all the transform stuff that was added earlier this summer? -Hazen -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On Wed, Sep 29, 2010 at 10:57:22AM -0700, Alan Irwin wrote: On 2010-09-29 11:26-0400 Hezekiah M. Carty wrote: I'll try to get pllegend wrapped for OCaml before the 5.9.7 release, and I will wait on any plarc alterations until after the release. Of course, there is some urgency to the OCaml pllegend wrapper as well as the Octave pllegend wrapper (which I hope Andrew will implement) just in case comparisons between pllegend and the current legend functionality in OCaml and/or Octave indicate the pllegend API should be changed before the release. However, since these comparisons can be done by you (and hopefully Andrew) locally I suggest you wait to commit these wrappers until after the release. The reason I bring this up is I am doing some comprehensive testing today (and will urge others to use that same script on as many platforms as possible once I am satisfied with it) in preparation for the release, but the value of such comprehensive testing is reduced if untested changes are subsequently committed to svn trunk before the release. Thus, I suggest it would be a good idea to reserve svn commits for bug fixes and _validated_ documentation changes this close to release. Note, this is a reminder and not a demand because we have done very well previously with a rather informal release procedure where our developers have exercised extremely good judgement about what kind of trunk commits they make in the last several days before any of our releases. Alan, Sorry - I won't get chance to do a detailed comparison with the octave legend support before the weekend release. To be honest the legend support is relatively basic. Certainly for the x11 driver it doesn't work too well. I think your interface is more comprehensive in terms of flexibility. I will look at switching the support at some stage to use the new funcionality. Andrew -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On Tue, Sep 28, 2010 at 1:00 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2010-09-28 08:24-0400 Hezekiah M. Carty wrote: Or, as I'm starting to suspect, if provided, would each entry draw a single block of a given color + pattern? If this is the case then I think keeping this in pllegend seems reasonable. It would be nice to have these options used in an example. Yes a single discrete color block (of variable vertical size so the blocks can be separate or just touch or even overlap) per legend entry. So I think this API encompasses what you already do with your discrete color bar, but definitely not what you do with your continuous color bar. Separating out this discrete color block API into a separate function makes little sense to me because many of the calculations and a lot of the functionality are common with the lines and/or symbols functionality. In sum, the way I think of this is that pllegend is our discrete legend API, while plcolorbar will be our continuous legend API. This actually provides a different kind of functionality than what the OCaml colorbar support provides, so I'm glad you added it! The discrete characteristic I was referring to is meant as the difference between, for example, plimage (continuous color scale) and plshade (discrete color intervals). While I agree with this, I do think it is worth leaving the pllegend API flexible through the post-5.9.7 development cycle. I like the API overall, but given how high-level this function is compared to most of PLplot's C API I think extra time to try out pllegend before committing to the current API would be useful. I will try to get the OCaml pllegend binding working before the 5.9.7 release for testing. I would rather have to change the binding than realize a month later that we are missing some key functionality (like the missing rotation support in plarc!). Good point. So I suggest (to answer Arjen's question as well) we postpone pllegend propagation to other languages or examples until after the 5.9.7 release except possibly to OCaml and/or octave to compare with existing legend capabilities for those two languages. Ideally, (once I answer your further posted questions about API specifics) we will have finalized the pllegend API before 5.9.7, but if we have to make changes later after some further experience, I am open to that as well so long as that is accompanied by the appropriate SOVERSION bump to libplplotd to force users to recompile and also an API change warning in the release notes. By the way, I think that is the approach we should take with further plarc rotation changes as well after 5.9.7 is released. After all, a plarc API change won't affect that many users since it is relatively new functionality. The only real difference with some hypothetical pllegend API change post 5.9.7 is in the former case there is extra work to do because we would have to tweak all plarc functionality in languages and examples, but in the latter case we are holding back on doing language propagation (see above remarks) to avoid that work if there is an additional API change for pllegend. I hasten to add I don't think any plarc rotation API change should be done _before_ the 5.9.7 release because we are too close to that release to insure there are no screwups in the required dependent propagation changes. I agree. I'll try to get pllegend wrapped for OCaml before the 5.9.7 release, and I will wait on any plarc alterations until after the release. Hez -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On 2010-09-29 11:26-0400 Hezekiah M. Carty wrote: I'll try to get pllegend wrapped for OCaml before the 5.9.7 release, and I will wait on any plarc alterations until after the release. Of course, there is some urgency to the OCaml pllegend wrapper as well as the Octave pllegend wrapper (which I hope Andrew will implement) just in case comparisons between pllegend and the current legend functionality in OCaml and/or Octave indicate the pllegend API should be changed before the release. However, since these comparisons can be done by you (and hopefully Andrew) locally I suggest you wait to commit these wrappers until after the release. The reason I bring this up is I am doing some comprehensive testing today (and will urge others to use that same script on as many platforms as possible once I am satisfied with it) in preparation for the release, but the value of such comprehensive testing is reduced if untested changes are subsequently committed to svn trunk before the release. Thus, I suggest it would be a good idea to reserve svn commits for bug fixes and _validated_ documentation changes this close to release. Note, this is a reminder and not a demand because we have done very well previously with a rather informal release procedure where our developers have exercised extremely good judgement about what kind of trunk commits they make in the last several days before any of our releases. 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); PLplot scientific plotting software package (plplot.org); 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 __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On Mon, Sep 27, 2010 at 8:50 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: Hi Andrew: On 2010-09-27 20:36+0100 Andrew Ross wrote: Alan, I've had a quick look at this [pllegend API]. It is something I've desired for a while so it is great to see it! A few random thoughts. 1) This is great for non-interactive uses. For interactive use you may not know in advance how many legend entries there are. It would be nice to add entries as you go along. This is a lot more complicated, and may well not be worth the effort. It doesn't fit with the plplot design very neatly. How does plplot cope with multiple calls to pllegend if you update the legend as you go? I think interactive use like you describe would be mostly fine. For solid backgrounds, you could just increment nlegend and fill in data for the last index to (re-)produce the legend enlarged by one legend line each time. For no background, you could turn off all legends for any legend index by setting opt_array to zero for that index. For later calls, you could do that for all prior indices, increment nlegend, and fill in data for the last index to produce just one legend line in the correct place per call to pllegend. Transparent backgrounds, however, would be problematic for repeated interactive use. I agree with Alan's summary here. One (very post-release!) possibility would be to add support for multiple plot layers to PLplot. For example, x04c.c may have 3 layers: (1) The plot content inside the viewport (2) Axes and labels (3) The legend This could be a handy way to improve interactive plotting as it would allow PLplot to prevent the plot contents from obscuring axes, legends, etc. with minimal user intervention. This would be relatively straightforward with Cairo and I imagine with Qt as well. 2) A different, but related, issue is colourbars for colour contour plots. Support for this would also be good. I think a separate plcolorbar API for that capability should be worked on post-release. I'm not sure I'm following this portion of the API correctly - does pllegend support some of this already? It looks like cmap0_colors, cmap1_colors, cmap_patterns and cmap_scales are meant to support something along these lines. If that is the case, then I still think that these would fit better in the plcolorbar API. Or, as I'm starting to suspect, if provided, would each entry draw a single block of a given color + pattern? If this is the case then I think keeping this in pllegend seems reasonable. It would be nice to have these options used in an example. 3) I'm not quite sure from the examples or what you have said whether a legend outside the plot is possible, but I certainly think it should be. Yes, that capability is available now. In fact, the legend x,y position and plot_width are now expressed in normalized sub-page coordinates rather than normalized viewport coordinates as before. Sounds good to me! Overall I think the current API is probably fit for most uses. Thanks for your review. While I agree with this, I do think it is worth leaving the pllegend API flexible through the post-5.9.7 development cycle. I like the API overall, but given how high-level this function is compared to most of PLplot's C API I think extra time to try out pllegend before committing to the current API would be useful. I will try to get the OCaml pllegend binding working before the 5.9.7 release for testing. I would rather have to change the binding than realize a month later that we are missing some key functionality (like the missing rotation support in plarc!). Hez -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On 2010-09-28 08:24-0400 Hezekiah M. Carty wrote: 2) A different, but related, issue is colourbars for colour contour plots. Support for this would also be good. I think a separate plcolorbar API for that capability should be worked on post-release. I'm not sure I'm following this portion of the API correctly - does pllegend support some of this already? It looks like cmap0_colors, cmap1_colors, cmap_patterns and cmap_scales are meant to support something along these lines. If that is the case, then I still think that these would fit better in the plcolorbar API. Or, as I'm starting to suspect, if provided, would each entry draw a single block of a given color + pattern? If this is the case then I think keeping this in pllegend seems reasonable. It would be nice to have these options used in an example. Yes a single discrete color block (of variable vertical size so the blocks can be separate or just touch or even overlap) per legend entry. So I think this API encompasses what you already do with your discrete color bar, but definitely not what you do with your continuous color bar. Separating out this discrete color block API into a separate function makes little sense to me because many of the calculations and a lot of the functionality are common with the lines and/or symbols functionality. In sum, the way I think of this is that pllegend is our discrete legend API, while plcolorbar will be our continuous legend API. For now you can easily try out this color block functionality in example 4. It's all set up. All you have to do is fiddle with the opt_array options. 3) I'm not quite sure from the examples or what you have said whether a legend outside the plot is possible, but I certainly think it should be. Yes, that capability is available now. In fact, the legend x,y position and plot_width are now expressed in normalized sub-page coordinates rather than normalized viewport coordinates as before. Sounds good to me! Overall I think the current API is probably fit for most uses. Thanks for your review. While I agree with this, I do think it is worth leaving the pllegend API flexible through the post-5.9.7 development cycle. I like the API overall, but given how high-level this function is compared to most of PLplot's C API I think extra time to try out pllegend before committing to the current API would be useful. I will try to get the OCaml pllegend binding working before the 5.9.7 release for testing. I would rather have to change the binding than realize a month later that we are missing some key functionality (like the missing rotation support in plarc!). Good point. So I suggest (to answer Arjen's question as well) we postpone pllegend propagation to other languages or examples until after the 5.9.7 release except possibly to OCaml and/or octave to compare with existing legend capabilities for those two languages. Ideally, (once I answer your further posted questions about API specifics) we will have finalized the pllegend API before 5.9.7, but if we have to make changes later after some further experience, I am open to that as well so long as that is accompanied by the appropriate SOVERSION bump to libplplotd to force users to recompile and also an API change warning in the release notes. By the way, I think that is the approach we should take with further plarc rotation changes as well after 5.9.7 is released. After all, a plarc API change won't affect that many users since it is relatively new functionality. The only real difference with some hypothetical pllegend API change post 5.9.7 is in the former case there is extra work to do because we would have to tweak all plarc functionality in languages and examples, but in the latter case we are holding back on doing language propagation (see above remarks) to avoid that work if there is an additional API change for pllegend. I hasten to add I don't think any plarc rotation API change should be done _before_ the 5.9.7 release because we are too close to that release to insure there are no screwups in the required dependent propagation changes. 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); PLplot scientific plotting software package (plplot.org); 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 __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
Re: [Plplot-devel] 5.9.7 release timing
Hi Hazen, Alan, On 2010-09-24 18:45, Hazen Babcock wrote: Alan W. Irwin wrote: Hi Hazen: I am pretty sure I can stabilize the pllegend API sometime this weekend which should finish my PLplot development work for this release cycle. Is the 5.9.7 development release still on for next weekend? Yep, assuming that there are no objections. -Hazen Is the pllegend stuff sufficiently evolved to be propagated to the other languages? I have not done anything there yet, myself, as I waited for the API to settle. If so, is a week sufficient time to bring everything up-to-date for everybody? (I think I will be able to do this.) Regards, Arjen 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. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On Mon, Sep 27, 2010 at 12:03:28PM -0700, Alan Irwin wrote: On 2010-09-27 09:06+0200 Arjen Markus wrote: Hi Hazen, Alan, On 2010-09-24 18:45, Hazen Babcock wrote: Alan W. Irwin wrote: Hi Hazen: I am pretty sure I can stabilize the pllegend API sometime this weekend which should finish my PLplot development work for this release cycle. Is the 5.9.7 development release still on for next weekend? Yep, assuming that there are no objections. -Hazen Is the pllegend stuff sufficiently evolved to be propagated to the other languages? I have not done anything there yet, myself, as I waited for the API to settle. If so, is a week sufficient time to bring everything up-to-date for everybody? (I think I will be able to do this.) I finished the internal change to pllegend so that clipping occurs at subpage boundaries and not viewport boundaries. The only thing beyond that I plan for pllegend is documentation. Also, after the release I plan refinements to plstrl (which is called by pllegend to align the background), but that is entirely separate project and nothing to do with the pllegend API. Thus, I think pllegend is ready for prime time, but the API needs review by somebody else before we propagate. I have asked Hez for such a review since he is keen on the API question. It's important to finish that review before the release for obvious reasons. Furthermore, if that review is completed early (today, Monday, would be ideal) rather than later this week, then we have a chance to propagate pllegend before the release and test all those propagated changes. Otherwise, we should probably wait until after the release to avoid any substantial untested PLplot changes just before the release. Alan, I've had a quick look at this. It is something I've desired for a while so it is great to see it! A few random thoughts. 1) This is great for non-interactive uses. For interactive use you may not know in advance how many legend entries there are. It would be nice to add entries as you go along. This is a lot more complicated, and may well not be worth the effort. It doesn't fit with the plplot design very neatly. How does plplot cope with multiple calls to pllegend if you update the legend as you go? 2) A different, but related, issue is colourbars for colour contour plots. Support for this would also be good. 3) I'm not quite sure from the examples or what you have said whether a legend outside the plot is possible, but I certainly think it should be. Overall I think the current API is probably fit for most uses. Andrew -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
Hi Andrew: On 2010-09-27 20:36+0100 Andrew Ross wrote: Alan, I've had a quick look at this [pllegend API]. It is something I've desired for a while so it is great to see it! A few random thoughts. 1) This is great for non-interactive uses. For interactive use you may not know in advance how many legend entries there are. It would be nice to add entries as you go along. This is a lot more complicated, and may well not be worth the effort. It doesn't fit with the plplot design very neatly. How does plplot cope with multiple calls to pllegend if you update the legend as you go? I think interactive use like you describe would be mostly fine. For solid backgrounds, you could just increment nlegend and fill in data for the last index to (re-)produce the legend enlarged by one legend line each time. For no background, you could turn off all legends for any legend index by setting opt_array to zero for that index. For later calls, you could do that for all prior indices, increment nlegend, and fill in data for the last index to produce just one legend line in the correct place per call to pllegend. Transparent backgrounds, however, would be problematic for repeated interactive use. 2) A different, but related, issue is colourbars for colour contour plots. Support for this would also be good. I think a separate plcolorbar API for that capability should be worked on post-release. 3) I'm not quite sure from the examples or what you have said whether a legend outside the plot is possible, but I certainly think it should be. Yes, that capability is available now. In fact, the legend x,y position and plot_width are now expressed in normalized sub-page coordinates rather than normalized viewport coordinates as before. Overall I think the current API is probably fit for most uses. Thanks for your review. 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); PLplot scientific plotting software package (plplot.org); 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 __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On 2010-09-04 14:33-0400 Hazen Babcock wrote: Hazen Babcock wrote: Back when we were discussing the 5.9.6 release there was the thought that the 5.9.7 release might happen in August. Now that it is mid-August I would say that this is not so likely. Any thoughts on what people want to see in 5.9.7? And how long this might take? My goal for this release is to put the dead streams stuff into PLplot core (at present only the Cairo and Qt drivers have it). I feel that I could do this by mid-September. I'll also try and document some more of the undocumented functions in the API. I'm now thinking about the first weekend in October, i.e. October 2-3. By that time I should have some more of the documentation done. Any thoughts? Hi Hazen: I am pretty sure I can stabilize the pllegend API sometime this weekend which should finish my PLplot development work for this release cycle. Is the 5.9.7 development release still on for next weekend? 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); PLplot scientific plotting software package (plplot.org); 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 __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
Hazen Babcock wrote: Back when we were discussing the 5.9.6 release there was the thought that the 5.9.7 release might happen in August. Now that it is mid-August I would say that this is not so likely. Any thoughts on what people want to see in 5.9.7? And how long this might take? My goal for this release is to put the dead streams stuff into PLplot core (at present only the Cairo and Qt drivers have it). I feel that I could do this by mid-September. I'll also try and document some more of the undocumented functions in the API. I'm now thinking about the first weekend in October, i.e. October 2-3. By that time I should have some more of the documentation done. Any thoughts? -Hazen -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On 2010-09-04 14:33-0400 Hazen Babcock wrote: Hazen Babcock wrote: Back when we were discussing the 5.9.6 release there was the thought that the 5.9.7 release might happen in August. Now that it is mid-August I would say that this is not so likely. Any thoughts on what people want to see in 5.9.7? And how long this might take? My goal for this release is to put the dead streams stuff into PLplot core (at present only the Cairo and Qt drivers have it). I feel that I could do this by mid-September. I'll also try and document some more of the undocumented functions in the API. I'm now thinking about the first weekend in October, i.e. October 2-3. By that time I should have some more of the documentation done. Any thoughts? That weekend is fine with me. 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); PLplot scientific plotting software package (plplot.org); 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 __ -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.7 release timing
On 2010-08-11 18:56-0400 Hazen Babcock wrote: Back when we were discussing the 5.9.6 release there was the thought that the 5.9.7 release might happen in August. Now that it is mid-August I would say that this is not so likely. Any thoughts on what people want to see in 5.9.7? And how long this might take? My goal for this release is to put the dead streams stuff into PLplot core (at present only the Cairo and Qt drivers have it). I feel that I could do this by mid-September. I'll also try and document some more of the undocumented functions in the API. I did manage to translate all the PLplot examples to Lisp this summer, so I haven't been completely slacking :). http://common-lisp.net/project/cl-plplot/ Hi Hazen: I am currently working on some issues I turned up with a comprehensive test script which does our three kinds of builds (shared library + dynamic devices, shared library + static devices, and static library + static devices) and tests each of those builds 7 different ways (ctest; test_(non)interactive in build tree; test_(non)interactive in installed examples configured with ctest; and test_(non)interactive in installed examples using the traditional Makefile+pkg-config approach). Once finished, I would be glad to share that comprehensive test script since it should make that task extremely easy to do on any Unix platform and also the Cygwin and MinGW/MSYS Windows platforms. I also strongly encourage our developers with access to other Windows platforms to share their automated methods of comprehensive testing of PLplot. If the release is mid-September, I should easily be able to finish off that comprehensive testing project. That release date might also give me a chance to finish off one of my other PLplot projects that have been cooking for awhile. However, I leave the decision about exact release timing up to you (i.e., don't wait for me). Whatever you decide, it would be good to have definite notice of which weekend you have picked as far in advance as possible, and similarly for definite notice of the day in that weekend. 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); PLplot scientific plotting software package (plplot.org); 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 __ -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
