Home / Browse / PLplot / Mail / Archive

PLplot

Email Archive: plplot-devel (read-only)

Re: [Plplot-devel] 5.9.7 release timing

From: Hezekiah M. Carty <hezekiahcarty@us...> - 2010-09-29 15:33

On Tue, Sep 28, 2010 at 1:00 PM, Alan W. Irwin
<irwin@...> 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

Thread View

Thread	Author	Date
[Plplot-devel] 5.9.7 release timing	Hazen Babcock <hbabcock@ma...>

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-08-12 00: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
__________________________

[Plplot-devel] Some initial observations wrt Visual Studio (Was: Re: 5.9.7 release timing)

From: Arjen Markus <arjen.markus@de...> - 2010-08-12 07:20

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.

Re: [Plplot-devel] Some initial observations wrt Visual Studio (Was: Re: 5.9.7 release timing)

From: Alan W. Irwin <irwin@be...> - 2010-08-12 15:40

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
__________________________

Re: [Plplot-devel] Some initial observations wrt Visual Studio (Was: Re: 5.9.7 release timing)

From: Arjen Markus <arjen.markus@de...> - 2010-08-13 08:04

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.

Re: [Plplot-devel] Some initial observations wrt Visual Studio (Was: Re: 5.9.7 release timing)

From: Alan W. Irwin <irwin@be...> - 2010-08-13 15:12

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
__________________________

Re: [Plplot-devel] Some initial observations wrt Visual Studio (Was: Re: 5.9.7 release timing)

From: Alan W. Irwin <irwin@be...> - 2010-08-13 15:24

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
__________________________

Re: [Plplot-devel] Some initial observations wrt Visual Studio (Was: Re: 5.9.7 release timing)

From: Arjen Markus <arjen.markus@de...> - 2010-08-16 07:20

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.

Re: [Plplot-devel] Some initial observations wrt Visual Studio (Was: Re: 5.9.7 release timing)

From: Arjen Markus <arjen.markus@de...> - 2010-08-16 07:23

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.

Re: [Plplot-devel] Some initial observations wrt Visual Studio (Was: Re: 5.9.7 release timing)

From: Arjen Markus <arjen.markus@de...> - 2010-08-17 06:51

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.

Re: [Plplot-devel] 5.9.7 release timing

From: Hazen Babcock <hbabcock@ma...> - 2010-09-04 18:33

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

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-09-05 04:18

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
__________________________

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-09-24 16:04

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
__________________________

Re: [Plplot-devel] 5.9.7 release timing

From: Hazen Babcock <hbabcock@ma...> - 2010-09-24 16:45

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

Re: [Plplot-devel] 5.9.7 release timing

From: Arjen Markus <arjen.markus@de...> - 2010-09-27 07:06

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.

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-09-27 19:03

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
__________________________

Re: [Plplot-devel] 5.9.7 release timing

From: Andrew Ross <andrewross@us...> - 2010-09-27 19:36

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

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-09-28 00:50

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
__________________________

Re: [Plplot-devel] 5.9.7 release timing

From: Hezekiah M. Carty <hezekiahcarty@us...> - 2010-09-28 12:31

On Mon, Sep 27, 2010 at 8:50 PM, Alan W. Irwin
<irwin@...> 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

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-09-28 17:00

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
__________________________

Re: [Plplot-devel] 5.9.7 release timing

From: Hezekiah M. Carty <hezekiahcarty@us...> - 2010-09-29 15:33

On Tue, Sep 28, 2010 at 1:00 PM, Alan W. Irwin
<irwin@...> 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

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-09-29 17:57

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
__________________________

Re: [Plplot-devel] 5.9.7 release timing

From: Andrew Ross <andrewross@us...> - 2010-09-30 20:05

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

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-10-01 18:15

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
__________________________

Re: [Plplot-devel] 5.9.7 release timing

From: Hazen Babcock <hbabcock@ma...> - 2010-10-01 23:13

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

Re: [Plplot-devel] 5.9.7 release timing

From: Hazen Babcock <hbabcock@ma...> - 2010-10-02 01:40

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

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-10-02 04:13

On 2010-10-01 19:12-0400 Hazen Babcock wrote:

>> 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.

Hi Hazen:

Thanks for your thoughts on this issue.

(1) is actually fine with me.  Your point about how long it will take
to propagate pllegend is a good one, and I do have a lot of other
things I would like to work on as well. Finally, even though it
appears our next release cycle will be a developmental one, I still
encourage developers to do some activities associated with a stable
release cycle as well such as testing, bug fixing, and documentation
since that should help us to shorten the subsequent stable release
cycle.

> (2) Hold off on 5.9.7 for another 1-2 months.

Definitely not (2).  So please go ahead on Sunday (anticipating your
next post) with the release of 5.9.7.

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
__________________________

Re: [Plplot-devel] 5.9.7 release timing

From: Arjen Markus <arjen.markus@de...> - 2010-10-03 13:46

Attachments: x26_1.PNG x26_2.PNG

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.

See the attached PNG files.

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.

Re: [Plplot-devel] 5.9.7 release timing

From: Alan W. Irwin <irwin@be...> - 2010-10-03 15:31

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
__________________________

Re: [Plplot-devel] 5.9.7 release timing

From: Arjen Markus <arjen.markus@de...> - 2010-10-04 06:35

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.