From: Hazen B. <hba...@ma...> - 2010-08-11 22:56:44
|
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/ -Hazen |
From: Alan W. I. <ir...@be...> - 2010-08-12 00:54:54
|
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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-08-12 07:20:40
|
Hi, On 2010-08-12 03:00, Alan W. Irwin wrote: > Hi Hazen: > > I am currently working on some issues I turned up with a comprehensive > test script ... I have picked up another aspect of PLplot on Windows: I am trying to build it using the CMake option to produce Visual Studio project files/solutions. While it is still early in the game, things look bright enough to be confident that it will work (not immediately unfortunately), but I also got error messages from CMake (the CTest part) at the stage where the project files (makefiles) are written: D:\plplot-svn\build-windows-vs2008>d:\cmake28\bin\cmake ..\plplot -G "Visual Studio 9 2008" -DBUILD_TEST=ON -- Check for working C compiler using: Visual Studio 9 2008 -- Check for working C compiler using: Visual Studio 9 2008 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- CMake version = 2.8.2 -- WARNING: bash shell not found, ctest will not work properly -- Checking whether system has ANSI C header files ... ENABLE_DYNDRIVERS: ON DRIVERS_LIST: mem;null;ps;svg;wingcc;xfig DEVICES_LIST: mem;null;ps;svg;wingcc;xfig Library options: BUILD_SHARED_LIBS: ON PL_DOUBLE: ON Optional libraries: HAVE_QHULL: OFF WITH_CSA: ON HAVE_FREETYPE: HAVE_PTHREAD: HAVE_AGG: Language Bindings: ENABLE_f77: ON ENABLE_f95: ON ENABLE_cxx: ON ENABLE_java: OFF ENABLE_python: OFF ENABLE_octave: OFF ENABLE_tcl: ON ENABLE_itcl: OFF ENABLE_tk: OFF ENABLE_itk: OFF ENABLE_pdl: OFF ENABLE_wxwidgets: OFF ENABLE_ada: OFF ENABLE_d: OFF ENABLE_ocaml: OFF ENABLE_lua: OFF ENABLE_qt: OFF ENABLE_pyqt4: OFF -- Configuring done -- Generating done CMake Error: Unknown Target referenced : test_c_pdfcairo CMake Error: Target: test_all_cairo depends on unknown target: test_c_pdfcairo CMake Error: Unknown Target referenced : test_c_pngcairo CMake Error: Target: test_all_cairo depends on unknown target: test_c_pngcairo CMake Error: Unknown Target referenced : test_c_pscairo CMake Error: Target: test_all_cairo depends on unknown target: test_c_pscairo CMake Error: Unknown Target referenced : test_c_svgcairo CMake Error: Target: test_all_cairo depends on unknown target: test_c_svgcairo CMake Error: Unknown Target referenced : test_c_xcairo ... I had never seen these messages before, they are specific to the CMake generator. (But just like Alan said, do not let this work influence the time schedule) 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. |
From: Alan W. I. <ir...@be...> - 2010-08-12 15:40:09
|
On 2010-08-12 09:20+0200 Arjen Markus wrote: > CMake Error: Unknown Target referenced : test_c_pdfcairo > CMake Error: Target: test_all_cairo depends on unknown target: > test_c_pdfcairo > CMake Error: Unknown Target referenced : test_c_pngcairo > CMake Error: Target: test_all_cairo depends on unknown target: > test_c_pngcairo > CMake Error: Unknown Target referenced : test_c_pscairo > CMake Error: Target: test_all_cairo depends on unknown target: > test_c_pscairo > CMake Error: Unknown Target referenced : test_c_svgcairo > CMake Error: Target: test_all_cairo depends on unknown target: > test_c_svgcairo > CMake Error: Unknown Target referenced : test_c_xcairo > ... > > I had never seen these messages before, they are specific to the > CMake generator. Hi Arjen: Thanks for reporting this build system bug which I believe I have just fixed (revision 11127) by checking for whether a target exists before adding it as a dependency of test_all_cairo. (test_all_qt had a similar error which I have also fixed with that commit). Could you please try again with that revision? 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-08-13 08:04:57
|
Hi Alan, it almost works: ... Language Bindings: ENABLE_f77: ON ENABLE_f95: ON ENABLE_cxx: ON ENABLE_java: OFF ENABLE_python: OFF ENABLE_octave: OFF ENABLE_tcl: ON ENABLE_itcl: OFF ENABLE_tk: OFF ENABLE_itk: OFF ENABLE_pdl: OFF ENABLE_wxwidgets: OFF ENABLE_ada: OFF ENABLE_d: OFF ENABLE_ocaml: OFF ENABLE_lua: OFF ENABLE_qt: OFF ENABLE_pyqt4: OFF -- Configuring done -- Generating done CMake Error: Unknown Target referenced : xwin CMake Error: Target: test_tcl_standard_examples depends on unknown target: xwin -- Build files have been written to: D:/plplot-svn/build-windows-vs2008 Under Windows the xwin device can not be compiled (not even under Cygwin). Further observations: Intel Fortran uses the "cdecl" calling convention, not stdcall. This is not yet reflected in the selection of the STUB_LINKAGE macro (that currently only depends on the C compiler!) so this is something I need to adjust. It also means that we have to accommodate for different link names in a third variety of .def files. This is just a consequence of the software evolution on Windows ... Regards, Arjen On 2010-08-12 17:39, Alan W. Irwin wrote: > On 2010-08-12 09:20+0200 Arjen Markus wrote: > >> CMake Error: Unknown Target referenced : test_c_pdfcairo >> CMake Error: Target: test_all_cairo depends on unknown target: >> test_c_pdfcairo >> CMake Error: Unknown Target referenced : test_c_pngcairo >> CMake Error: Target: test_all_cairo depends on unknown target: >> test_c_pngcairo >> CMake Error: Unknown Target referenced : test_c_pscairo >> CMake Error: Target: test_all_cairo depends on unknown target: >> test_c_pscairo >> CMake Error: Unknown Target referenced : test_c_svgcairo >> CMake Error: Target: test_all_cairo depends on unknown target: >> test_c_svgcairo >> CMake Error: Unknown Target referenced : test_c_xcairo >> ... >> >> I had never seen these messages before, they are specific to the >> CMake generator. > > Hi Arjen: > > Thanks for reporting this build system bug which I believe I have > just fixed (revision 11127) by checking for whether a target exists > before adding it as a dependency of test_all_cairo. (test_all_qt had > a similar error which I have also fixed with that commit). > > Could you please try again with that revision? > > 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. |
From: Alan W. I. <ir...@be...> - 2010-08-13 15:12:37
|
On 2010-08-13 10:04+0200 Arjen Markus wrote: > Further observations: > Intel Fortran uses the "cdecl" calling convention, not stdcall. This > is not yet reflected in the selection of the STUB_LINKAGE macro (that > currently only depends on the C compiler!) so this is something I need > to adjust. It also means that we have to accommodate for different > link names in a third variety of .def files. > > This is just a consequence of the software evolution on Windows ... To Arjen and Werner: Is the calling convention also going to be an issue for our visibility support? Right now (in include/pldll.h(.in) we use #define PLDLLEXPORT __declspec( dllexport ) for both non-Cygwin and Cygwin windows. But I have noticed that for the libharu symbol visibility support (see cmake/external/libharu/include/hpdf.h) they use #ifdef HPDF_DLL_MAKE # define HPDF_EXPORT(A) __declspec(dllexport) A __stdcall #else # ifdef HPDF_DLL_MAKE_CDECL # define HPDF_EXPORT(A) __declspec(dllexport) A [...] where "A" is the function type and HPDF_DLL_MAKE_CDECL is defined in the Cygwin case and HPDF_DLL_MAKE defined in the non-Cygwin Windows case. Note, I don't understand Windows symbol visibility syntax at all, but the implication from the name of the macro in the Cygwin case and the use of __stdcall in the non-Cygwin Windows case is that Cygwin uses the "cdecl" calling convention (whatever that is) and non-Cygwin Windows uses "stdcall" calling convention (whatever that is). In sum, it appears the libharu developers were unaware of the cdecl calling convention for the Intel compiler, but they do appear to distinguish the two calling conventions in their visibility support so we might want to consider doing that ourselves (by adding the __stdcall attribute for the stdcall case). Even more importantly, if Cygwin really does use the cdecl calling convention it appears from Arjen's comments above there would be widespread Cygwin fortran implications (which may explain why fortran has historically been problematic for PLplot on Cygwin). I am out of my depth so I am just mentioning some possibilities here based on what libharu does to give you guys some food for thought. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-08-16 07:23:10
|
Hi Alan, Werner, On 2010-08-13 17:12, Alan W. Irwin wrote: > > To Arjen and Werner: > > Is the calling convention also going to be an issue for our visibility > support? > > Right now (in include/pldll.h(.in) we use > > #define PLDLLEXPORT __declspec( dllexport ) > > for both non-Cygwin and Cygwin windows. But I have noticed that for > the libharu symbol visibility support (see > cmake/external/libharu/include/hpdf.h) they use > > #ifdef HPDF_DLL_MAKE > # define HPDF_EXPORT(A) __declspec(dllexport) A __stdcall > #else > # ifdef HPDF_DLL_MAKE_CDECL > # define HPDF_EXPORT(A) __declspec(dllexport) A > [...] > > where "A" is the function type and HPDF_DLL_MAKE_CDECL is defined in > the Cygwin case and HPDF_DLL_MAKE defined in the non-Cygwin Windows > case. > > Note, I don't understand Windows symbol visibility syntax at all, but > the implication from the name of the macro in the Cygwin case and the > use of __stdcall in the non-Cygwin Windows case is that Cygwin uses > the "cdecl" calling convention (whatever that is) and non-Cygwin > Windows uses "stdcall" calling convention (whatever that is). > > In sum, it appears the libharu developers were unaware of the cdecl > calling convention for the Intel compiler, but they do appear to > distinguish the two calling conventions in their visibility support so > we might want to consider doing that ourselves (by adding the > __stdcall attribute for the stdcall case). > > Even more importantly, if Cygwin really does use the cdecl calling > convention it appears from Arjen's comments above there would be > widespread Cygwin fortran implications (which may explain why fortran > has historically been problematic for PLplot on Cygwin). > > I am out of my depth so I am just mentioning some possibilities here > based on what libharu does to give you guys some food for thought. > I am positive the visibility (the __declspec(ddlimp/export) attribute) is NOT influenced by the __stdcall issue. They are orthogonal matters (wonderful word). That is evidenced by the fact that we need BOTH to get the right linkage for Compaq Visual Fortran, for instance. 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. |
From: Alan W. I. <ir...@be...> - 2010-08-13 15:24:37
|
On 2010-08-13 10:04+0200 Arjen Markus wrote: > Hi Alan, > > it almost works: [...] > CMake Error: Unknown Target referenced : xwin > CMake Error: Target: test_tcl_standard_examples depends on unknown > target: xwin Hi Arjen: Please try revision 11134 where I believe I have fixed this test framework bug. I hope that is the last bug you will encounter that is caused by missing targets for your particular build platform, but I am game for more iterations today if you find anything else. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-08-16 07:20:15
|
Hi Alan, On 2010-08-13 17:24, Alan W. Irwin wrote: > On 2010-08-13 10:04+0200 Arjen Markus wrote: > >> Hi Alan, >> >> it almost works: > [...] >> CMake Error: Unknown Target referenced : xwin >> CMake Error: Target: test_tcl_standard_examples depends on unknown >> target: xwin > > Hi Arjen: > > Please try revision 11134 where I believe I have fixed this test > framework bug. I hope that is the last bug you will encounter that is > caused by missing targets for your particular build platform, but I am > game for more iterations today if you find anything else. > This has indeed removed all error/warning messages from the build file generation. Visual Studio accepts the "solution" file without a problem, but when I try to build it there are a lot of error messages (Visual Studio does not stop at the first error, it seems to continue instead with the next part it can). I will have to sort these out - not all are related to the Fortran bindings! I have made some progress with the FORTRAN 77 bindings under Intel Fortran - that is: these build fine. Fortran 90/95 is on its way. Nothing mature enough to actually commit. That would generate noise only. 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. |
From: Arjen M. <arj...@de...> - 2010-08-17 06:51:11
|
Hello all On 2010-08-13 17:24, Alan W. Irwin wrote: > Hi Arjen: > > Please try revision 11134 where I believe I have fixed this test > framework bug. I hope that is the last bug you will encounter that is > caused by missing targets for your particular build platform, but I am > game for more iterations today if you find anything else. > With my latest commits, PLplot can now be used in combination with Intel Fortran (I use version 11.1) on Windows, if you use NMake makefiles as the CMake generator. There is a strange issue with the Visual Studio 2008 generator: the solution is fine, and I can build everything with it, with the notable exception of the Fortran DLLs. For some reason, the link step is different and therefore fails: a "main" symbol is expected by the Intel library library libifcoremt.dll. I have not figured out yet what the actual differences in the link steps are, and I may need to ask the CMake people if they can shed some light on this. Perhaps a small project can demonstrate this issue - I will have to try. Meanwhile, I am glad this is working. (One step I have not taken yet: check building with the (very) old CVF compiler.) 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. |
From: Hazen B. <hba...@ma...> - 2010-09-04 18:33:18
|
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 |
From: Alan W. I. <ir...@be...> - 2010-09-05 04:18:20
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-09-24 16:04:06
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-09-29 17:57:32
|
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 __________________________ |
From: Andrew R. <and...@us...> - 2010-09-30 20:05:31
|
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 |
From: Hazen B. <hba...@ma...> - 2010-09-24 16:45:38
|
Alan W. Irwin wrote: > 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? Yep, assuming that there are no objections. -Hazen |
From: Alan W. I. <ir...@be...> - 2010-10-01 18:15:53
|
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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-09-27 07:06:12
|
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. |
From: Alan W. I. <ir...@be...> - 2010-09-27 19:03:37
|
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 __________________________ 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 __________________________ |
From: Andrew R. <and...@us...> - 2010-09-27 19:36:50
|
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 |
From: Alan W. I. <ir...@be...> - 2010-09-28 00:50:12
|
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 __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-09-28 12:31:47
|
On Mon, Sep 27, 2010 at 8:50 PM, Alan W. Irwin <ir...@be...> 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 |
From: Alan W. I. <ir...@be...> - 2010-09-28 17:00:20
|
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 __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-09-29 15:33:11
|
On Tue, Sep 28, 2010 at 1:00 PM, Alan W. Irwin <ir...@be...> 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 |
From: Hazen B. <hba...@ma...> - 2010-10-01 23:13:21
|
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 |