plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Alan W. I. <ir...@be...>]

Greg said:

> On Thu, Jan 28, 2016 at 8:47 PM, Jim Dishaw <ji...@di...> wrote:

>>
>> On Jan 28, 2016, at 8:15 PM, Greg Jung <gv...@gm...> wrote:
>>
>>
>>
>> Can you describe the wrong behavior?  Does it occur when you resize?
>>
>There's no re-sizing involved.   The image is put up via
>SetDIBitsToDevice(GetHdc(), 0, 0, rt.right + 1, rt.bottom + 1, 0,
>                            0, 0, rt.bottom + 1, tv_buf.lpbitmap, &tv_buf.bi,
>DIB_RGB_COLORS);
> found in {sfnet::GDL}src/gdlwinstream.cpp - gdlwinstream::Paintimage

Hi Greg:

The fact that you need GDL to demonstrate the issue makes it extremely
difficult for us to help you with this issue.  For example, the problem
might be due to GDL not being updated properly to deal with a PLplot
change, and such an issue would be out of scope for us.

So your best bet for getting help here is to show completely independent of GDL
that there is actually an issue with the master tip version of PLplot
that is unmodified by you other than possibly to modify one of our
standard examples in order to demonstrate the problem.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Phil R. <p.d...@gm...>]

I seem to remember we added those calls in because they are needed to wipe
the memory left over at the end of a plot. For example if a user starts
plotting with the default colours or colours left over from the previous
page then changes them half way through, when the plot is resized and if we
didn't have some sort of bop event then the plot would get redrawn with the
incorrect new set of colours. Same occurs for line width and other state
variables.

But in addition, there needs to be a way to set the current subpage, and
the subpage size. Otherwise when the clear command comes later the driver
does not know how big an area to clear. I think the bop call also does
things like reset the scale so that text is the right size - again
remembering that we should be able to just play a buffer on an empty
driver, which would otherwise have no idea of these variables.

The clear is definitely required, because the clear applies to each
subpage, not to the whole page and I think the user can set each subpage to
a different clear colour. So we need to time the clears correctly when we
are clipping to the correct subpage.

Phil


On 29 January 2016 at 08:13, Greg Jung <gv...@gm...> wrote:

>
>
> On Thu, Jan 28, 2016 at 8:47 PM, Jim Dishaw <ji...@di...> wrote:
>
>>
>> On Jan 28, 2016, at 8:15 PM, Greg Jung <gv...@gm...> wrote:
>>
>>
>>
>> Can you describe the wrong behavior?  Does it occur when you resize?
>>
> There's no re-sizing involved.   The image is put up via
> SetDIBitsToDevice(GetHdc(), 0, 0, rt.right + 1, rt.bottom + 1, 0,
>                             0, 0, rt.bottom + 1, tv_buf.lpbitmap, &
> tv_buf.bi, DIB_RGB_COLORS);
>  found in {sfnet::GDL}src/gdlwinstream.cpp - gdlwinstream::Paintimage
>
>
>  The test involved
> part 1: multiple windows, where a simple distribution  is laid out.
>  colors are reloaded
> (scmap0) and the distribution is painted.
>
> a=DIST(xdim, ydim)
> b1=REFORM(a,1, xdim, ydim)
> b2=REFORM(a,xdim, 1, ydim)
> b3=REFORM(a,xdim, ydim, 1)
> ;
> icolor=0
> MY_WINDOW, 0, a
> loadct,icolor & icolor++
>
> MY_WINDOW, 1, b1
> loadct,icolor & icolor++
> MY_WINDOW, 2, REFORM(b1)
> loadct,icolor & icolor++
> MY_WINDOW, 3, b2
> loadct,icolor & icolor++
> MY_WINDOW, 4, REFORM(b2)
> loadct,icolor & icolor++
> MY_WINDOW, 5, b3
> loadct,icolor & icolor++
> MY_WINDOW, 6, REFORM(b3)
> loadct,icolor & icolor++
>
> where MY_WINDOW =
>    1. create window of size to hold the 2-d
>    2. Put up the 2-D onto window
> For each window a different color table was loaded (icolor++)
> [image: Inline image 2]
>   Then this distribution is applied to sections of a larger window.
>   This works except  on the last test where a different color table should
> show for each sub-section.
> [image: Inline image 3]
> then a few exercises of "TV" routine are made, which puts the saturn.jpg
> image on a window where line-plots are already made:
> [image: Inline image 4]
> The actual wrong behavior; it ranged from segfaults to all of the windows
> blanking, to everything showing but the saturn image.
>  To find when it occurs, I built using historical plplots until I found it
> was between Jan 15 and Feb 1.  The changes in plbuf were too coarse to use
> plgit at that stage so I advanced plbuf from the working version towards
> the final plbuf.c:
>
> greg@Homerw7 MINGW32 /d/dated/plplot-git/plplot-150115
> $ git log
> commit cd749d09d1f6cbad3172e1b0b04910fc8ae3f4d8
> Author: Greg Jung <gv...@gm...>
> Date:   Sun Jan 24 08:15:19 2016 -0800
>
>        more plbuf.c advances.  seqfaults when attempting to implement
> rd_data_no_copy etc.
>
> commit b4411c72cd6c75c506574699adbb6cbfe9a7f8d2
> Author: Greg Jung <gv...@gm...>
> Date:   Sun Jan 24 06:57:54 2016 -0800
>
>       see patches/0000-656am.patch.  Compiles and runs gdl test_tv
>
> commit 27096a39cfac94c988b069d3ea94dd4c11fb3848
> Author: Greg Jung <gv...@gm...>
> Date:   Sun Jan 24 06:22:52 2016 -0800
>
>       This commit brings 150115 to the edge of break, in caase of
> plsdef.c, where
>       invoking  plP_state( PLSTATE_CHR ); at line 208 or
>     possibly line 255 produces a segfault in win32 builds.
>
> commit ccfee95ac0370f00f97b0e0deeebc450545b47e1
> Author: Alan W. Irwin <ai...@us...>
> Date:   Thu Jan 15 13:22:42 2015 -0800
>
>     Build System: Fix bug for case where no display
>
> A successful test would have the above pics displayed on the terminal
> [image: Inline image 5]
>
>  The patch files below document the changes made from the base  ccfee95ac03
> git.  Using Winmerge, I compared src/ with later versions to test when a
> problem cropped up.
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Greg J. <gv...@gm...>]

On Thu, Jan 28, 2016 at 8:47 PM, Jim Dishaw <ji...@di...> wrote:

>
> On Jan 28, 2016, at 8:15 PM, Greg Jung <gv...@gm...> wrote:
>
>
>
> Can you describe the wrong behavior?  Does it occur when you resize?
>
There's no re-sizing involved.   The image is put up via
SetDIBitsToDevice(GetHdc(), 0, 0, rt.right + 1, rt.bottom + 1, 0,
                            0, 0, rt.bottom + 1, tv_buf.lpbitmap, &tv_buf.bi,
DIB_RGB_COLORS);
 found in {sfnet::GDL}src/gdlwinstream.cpp - gdlwinstream::Paintimage


 The test involved
part 1: multiple windows, where a simple distribution  is laid out.  colors
are reloaded
(scmap0) and the distribution is painted.

a=DIST(xdim, ydim)
b1=REFORM(a,1, xdim, ydim)
b2=REFORM(a,xdim, 1, ydim)
b3=REFORM(a,xdim, ydim, 1)
;
icolor=0
MY_WINDOW, 0, a
loadct,icolor & icolor++

MY_WINDOW, 1, b1
loadct,icolor & icolor++
MY_WINDOW, 2, REFORM(b1)
loadct,icolor & icolor++
MY_WINDOW, 3, b2
loadct,icolor & icolor++
MY_WINDOW, 4, REFORM(b2)
loadct,icolor & icolor++
MY_WINDOW, 5, b3
loadct,icolor & icolor++
MY_WINDOW, 6, REFORM(b3)
loadct,icolor & icolor++

where MY_WINDOW =
   1. create window of size to hold the 2-d
   2. Put up the 2-D onto window
For each window a different color table was loaded (icolor++)
[image: Inline image 2]
  Then this distribution is applied to sections of a larger window.
  This works except  on the last test where a different color table should
show for each sub-section.
[image: Inline image 3]
then a few exercises of "TV" routine are made, which puts the saturn.jpg
image on a window where line-plots are already made:
[image: Inline image 4]
The actual wrong behavior; it ranged from segfaults to all of the windows
blanking, to everything showing but the saturn image.
 To find when it occurs, I built using historical plplots until I found it
was between Jan 15 and Feb 1.  The changes in plbuf were too coarse to use
plgit at that stage so I advanced plbuf from the working version towards
the final plbuf.c:

greg@Homerw7 MINGW32 /d/dated/plplot-git/plplot-150115
$ git log
commit cd749d09d1f6cbad3172e1b0b04910fc8ae3f4d8
Author: Greg Jung <gv...@gm...>
Date:   Sun Jan 24 08:15:19 2016 -0800

       more plbuf.c advances.  seqfaults when attempting to implement
rd_data_no_copy etc.

commit b4411c72cd6c75c506574699adbb6cbfe9a7f8d2
Author: Greg Jung <gv...@gm...>
Date:   Sun Jan 24 06:57:54 2016 -0800

      see patches/0000-656am.patch.  Compiles and runs gdl test_tv

commit 27096a39cfac94c988b069d3ea94dd4c11fb3848
Author: Greg Jung <gv...@gm...>
Date:   Sun Jan 24 06:22:52 2016 -0800

      This commit brings 150115 to the edge of break, in caase of plsdef.c,
where
      invoking  plP_state( PLSTATE_CHR ); at line 208 or
    possibly line 255 produces a segfault in win32 builds.

commit ccfee95ac0370f00f97b0e0deeebc450545b47e1
Author: Alan W. Irwin <ai...@us...>
Date:   Thu Jan 15 13:22:42 2015 -0800

    Build System: Fix bug for case where no display

A successful test would have the above pics displayed on the terminal
[image: Inline image 5]

 The patch files below document the changes made from the base  ccfee95ac03
git.  Using Winmerge, I compared src/ with later versions to test when a
problem cropped up.

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Jim D. <ji...@di...>]

> On Jan 28, 2016, at 8:15 PM, Greg Jung <gv...@gm...> wrote:
> 
> Hi all,
> 
>    I've been having difficulties under windows with plplot 5.11+
> when used with GDL (gnudatalanguage).  When I run a test
> that exercises 2-d bitmaps and line plots together (test_tv.pro <http://test_tv.pro/>),
>  I got wrong behavior.  I discovered the offense did not happen
> for plplot created in December 2014  - which I had saved - but 
> every version since therework of src/plbuf.c (mid-Jan 2015) had the issue.
> 

Can you describe the wrong behavior?  Does it occur when you resize?

>  I narrowed it down to the single line call to plP_bop() at the end
> of the rdbuf_bop routine.  When this call is not made from plbuf.c, 
> everything is working well (using wingc).
> 

I will take a look at the plP_bop() call in rdbuf_bop().  My suspicion is that it shouldn’t be removed.

Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

[Alan W. I. <ir...@be...>]

On 2016-01-28 17:15-0800 Greg Jung wrote:

> Hi all,
>
>   I've been having difficulties under windows with plplot 5.11+
> when used with GDL (gnudatalanguage).  When I run a test
> that exercises 2-d bitmaps and line plots together (test_tv.pro),
> I got wrong behavior.  I discovered the offense did not happen
> for plplot created in December 2014  - which I had saved - but
> every version since therework of src/plbuf.c (mid-Jan 2015) had the issue.

Hi Greg:

Please use the "git bisect" command to find the actual commit where
this bad behaviour starting occurring.  That will provide some useful
overall context to the other things you discovered below.

Alan

>
> I narrowed it down to the single line call to plP_bop() at the end
> of the rdbuf_bop routine.  When this call is not made from plbuf.c,
> everything is working well (using wingc).
>
> Within the GDL usage constraints, this call does not seem needed
> when used for xwin.c, either.
>  Another issue possibly related, from GDL the gdlstream::Clear()
> call which was also responsible for bad behavior:
>
> /f/gdl/src/gdlwinstream.cpp-      plstream::scolbg(red0,green0,blue0);
>>
>> /f/gdl/src/gdlwinstream.cpp-    ::c_plbop();
>>
>> /f/gdl/src/gdlwinstream.cpp: //     ::c_plclear();
>>
>>
> c_plcear() was another thing messing up the GDL plotting.  Again,
> if I also removed ::c_plclear for the xwin driver, this was no detrimental
> effects.
>
> I suspect that if plP_bop() should be generally called from plbuf then
> whatever is going wrong should be fixed in wingcc.

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] plP_bop() was killing functionality in wingcc

[Greg J. <gv...@gm...>]

Hi all,

   I've been having difficulties under windows with plplot 5.11+
when used with GDL (gnudatalanguage).  When I run a test
that exercises 2-d bitmaps and line plots together (test_tv.pro),
 I got wrong behavior.  I discovered the offense did not happen
for plplot created in December 2014  - which I had saved - but
every version since therework of src/plbuf.c (mid-Jan 2015) had the issue.

 I narrowed it down to the single line call to plP_bop() at the end
of the rdbuf_bop routine.  When this call is not made from plbuf.c,
everything is working well (using wingc).

Within the GDL usage constraints, this call does not seem needed
when used for xwin.c, either.
  Another issue possibly related, from GDL the gdlstream::Clear()
call which was also responsible for bad behavior:

/f/gdl/src/gdlwinstream.cpp-      plstream::scolbg(red0,green0,blue0);
>
> /f/gdl/src/gdlwinstream.cpp-    ::c_plbop();
>
> /f/gdl/src/gdlwinstream.cpp: //     ::c_plclear();
>
>
c_plcear() was another thing messing up the GDL plotting.  Again,
if I also removed ::c_plclear for the xwin driver, this was no detrimental
effects.

I suspect that if plP_bop() should be generally called from plbuf then
whatever is going wrong should be fixed in wingcc.

Greg

Re: [Plplot-devel] Having trouble compiling PLplot with gcc --std=c99

[Alan W. I. <ir...@be...>]

On 2016-01-26 21:17-0000 Arjen Markus wrote:

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
[...]
>> If your successful build with --std=c99 did include xwin, then that is pretty clear
>> evidence that there is nothing wrong with our xwin code and my gcc --std=c99 xwin
>> build issue is instead due to my gcc version which is "gcc (Debian 4.9.2-10) 4.9.2"
>>
> I tried it again - this time with the X Window server running to instruct the build system to include the xwin device, but it still built fine. No errors from the gcc compiler.
>

Thanks, Arjen, for taking the time to do that additional critical
test.  Based on our combined evidence I will ascribe this issue to my
gcc version and take no further action unless and until this issue
shows up for another gcc version.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Having trouble compiling PLplot with gcc --std=c99

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, January 26, 2016 8:58 PM
> To: Arjen Markus; PLplot development list
> Cc: Andrew Ross; and...@us...
> Subject: RE: [Plplot-devel] Having trouble compiling PLplot with gcc --std=c99
>
> On 2016-01-26 09:10-0000 Arjen Markus wrote:
>
> > I tried this [--std=c99] on Cygwin, using gcc 4.9.3 and that gave no complaints.
> So it may be your particular version of gcc.
>
> Thanks for your help trying to pin down the cause of this issue.
>
> Your build test result inspired me to try another build with
> --std=c99 and xwin excluded from the build using the CMake options -
> DPLD_xwin=OFF -DPLD_tk=OFF.  And the PLplot build was a complete success
> for that case!
>
> So it appears this --std=c99 (but not --std=gnu99) build bug shows up only if there
> is an attempt to build the xwin device.
>
> Some of your previous tests on Cygwin have included xwin and some have not
> because you had to take some extra steps to allow xwin to be part of the build.  Did
> your current build test with --std=c99 include xwin?
>
> If your successful build with --std=c99 did include xwin, then that is pretty clear
> evidence that there is nothing wrong with our xwin code and my gcc --std=c99 xwin
> build issue is instead due to my gcc version which is "gcc (Debian 4.9.2-10) 4.9.2"
>
I tried it again - this time with the X Window server running to instruct the build system to include the xwin device, but it still built fine. No errors from the gcc 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] Having trouble compiling PLplot with gcc --std=c99

[Alan W. I. <ir...@be...>]

On 2016-01-26 09:10-0000 Arjen Markus wrote:

> I tried this [--std=c99] on Cygwin, using gcc 4.9.3 and that gave no complaints. So it may be your particular version of gcc.

Thanks for your help trying to pin down the cause of this issue.

Your build test result inspired me to try another build with
--std=c99 and xwin excluded from the build using the CMake options
-DPLD_xwin=OFF -DPLD_tk=OFF.  And the PLplot build was a complete success for
that case!

So it appears this --std=c99 (but not --std=gnu99) build bug
shows up only if there is an attempt to build the xwin device.

Some of your previous tests on Cygwin have included xwin and some have
not because you had to take some extra steps to allow xwin to be part
of the build.  Did your current build test with --std=c99 include
xwin?

If your successful build with --std=c99 did include xwin, then that is
pretty clear evidence that there is nothing wrong with our xwin code
and my gcc --std=c99 xwin build issue is instead due to my gcc version
which is "gcc (Debian 4.9.2-10) 4.9.2"

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Having trouble compiling PLplot with gcc --std=c99

[Arjen M. <Arj...@de...>]

Hi Alan,



I tried this on Cygwin, using gcc 4.9.3 and that gave no complaints. So it may be your particular version of gcc.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, January 25, 2016 11:23 PM
> To: Andrew Ross; and...@us...; PLplot development list
> Subject: [Plplot-devel] Having trouble compiling PLplot with gcc --std=c99
>
> I think I gave too many specifics before since if there is a gcc problem, then it likely
> has nothing to do with xwin (where my build happened to fail with the --std=c99
> flag).  Anyhow, I have changed the subject line accordingly, and I would appreciate
> it if those with access to gcc (even if on platforms without X) to try the experiment
> of building PLplot with the --std=c99 flag to see whether my bad experience with
> that gcc option is unique to my system and gcc version or whether it is a common
> issue.
>


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.

[Plplot-devel] PyQt5 bindings

[Hazen B. <hba...@ma...>]

Hello,

I just added PyQt5 binding to PLplot and a corresponding example, 
examples/python/pyqt5_example.py. It should be enabled if you are using 
Qt5 and you have all the dependencies installed. I tested it and at the 
minimum it works on my linux machine :).

The biggest issue with these bindings is that PyQt5 does not provide any 
way to introspect the sip directory (PYQT_SIP_DIR), so I just used the 
default linux install location. I put in a guess for the default Windows 
install location, but perhaps someone with access to a Windows machine 
can tell me if I got it right?

best,
-Hazen

[Plplot-devel] Having trouble compiling PLplot with gcc --std=c99

[Alan W. I. <ir...@be...>]

I think I gave too many specifics before since if there is a gcc
problem, then it likely has nothing to do with xwin (where my build
happened to fail with the --std=c99 flag).  Anyhow, I have changed the
subject line accordingly, and I would appreciate it if those with
access to gcc (even if on platforms without X) to try the experiment
of building PLplot with the --std=c99 flag to see whether my bad
experience with that gcc option is unique to my system and gcc version
or whether it is a common issue.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Having trouble compiling the xwin device driver with gcc --std=c99

[Alan W. I. <ir...@be...>]

Hi Andrew:

If I specify

export CFLAGS='-O3 -std=c99 -pedantic -Wall -Wextra
-Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion
-Wshadow -Wcast-qual -Wcast-align -Wwrite-strings'

(a combination of options which you recommended in 2011 for testing our code)

and attempt to build PLplot from scratch, the xwin device driver fails
to build with gcc.

After that error, I attempted to build xwin using "make VERBOSE=1
xwin", and again the error occurred.  I then replicated that build
command by hand, and did some experimentation with removing
gcc options until I discovered that the critical flag above
that caused the xwin build error was
-std=c99.

The bits of code in xwin.c that appear to be relevant
to the error with --std=c99 are the following:

#ifdef PL_HAVE_PTHREAD
#include <pthread.h>
#include <signal.h>
....

#ifdef PL_HAVE_PTHREAD
static void
events_thread( void *pls )
{
     if ( usepthreads )
     {
         PLStream        *lpls = (PLStream *) pls;
         XwDev           *dev  = (XwDev *) lpls->dev;
         XwDisplay       *xwd  = (XwDisplay *) dev->xwd;
         PLStream        *oplsc;
         struct timespec delay;
         XEvent          event;
         long            event_mask;
         sigset_t        set;
....

The compiler chokes on that last sigset_t type for --std=c99 (as if
the above #include <signal.h> was never seen), but checking with
plplot_config.h, PL_HAVE_PTHREAD is not defined so gcc --std=c99
should just ignore both the #include <signal.h> and the above events_thread code.
Furthermore if I just replace that with -std=gnu99 (c99 + some
GNU extensions to that standard) in the hand compilation
the build error goes away.

Note the hand-compilation qualifier above since it turns out if I
build from scratch with the above CFLAGS except that c99 is replaced
by gnu99, then PL_HAVE_PTHREAD is #defined properly, and under those
circumstances as well, xwin builds without issues.  That change in
PL_HAVE_PTHREAD delivered by our build system depending on whether c99
or gnu99 is used is an additional symptom which might or might not be
related to the above issue exposed by hand-crafted compilations for a
given build-system environment.

Anyhow, from these symptoms for hand-crafted compilations for a build that
had PL_HAVE_PTHREAD undefined, I am pretty sure I am encountering a gcc bug in
how --std=c99 (but not --std=gnu99) is implemented because I don't see
how a GNU extension could normally affect whether the pre-processor
ignores #ifdef PL_HAVE_PTHREAD in one part of the xwin code but not in
other parts.

My gcc version details are

irwin@raven> gcc --version
gcc (Debian 4.9.2-10) 4.9.2
....

I would appreciate you and others here attempting to replicate this issue with
whatever gcc version you have access to, and if you feel there
is some other obvious explanation of this issue, please let me know.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] My plans for further work during this release cycle

[Alan W. I. <ir...@be...>]

Here is another issue I want to fix during this release cycle.

* Completely remove plrgb, plrgb1, and plhls (officially deprecated
   in version 5.9.8) and plwid (officially deprecated in version 5.9.10).

This will empty src/pldeprecated.c (for now) of all code other than historical
comments.

I don't think there is any question about plrgb, plrgb1, and plhls
(since their official deprecation was long after they had been declared
obsolete for years).  However, does anyone here feel it is too soon to
remove plwid (the integer version of plwidth) after a number of releases
when the user would have had to specify -DPL_DEPRECATED=ON to get
access to the integer version?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 / cmake error

[Hazen B. <hba...@ma...>]

On 01/22/2016 02:42 AM, Alan W. Irwin wrote:
> I had success with a build of PLplot against Qt5 some time ago.  But I
> am pretty
> sure that predated May 2015 when "git blame" tells me I introduced
> that PRIVATE keyword in bindings/qt_gui/CMakeLists.txt.  So I would
> try locally removing PRIVATE from the offending line in
> bindings/qt_gui/CMakeLists.txt.  That might introduce some
> overlinking issues, but I don't think you have to be concerned with
> those.

Hi Alan, Greg,

Removing the PRIVATE keyword solved the problem, thanks!

>
> Also, please follow the advice in the first two lines of cmake.txt,
> namely
>
> -- WARNING: CMAKE_VERSION = 3.2.2 is in the range from 3.2 through 3.3.1
> which has
>     a compromised find ability that was fixed in 3.3.2.  Please upgrade
> to 3.3.2 or greater.

This was not necessary so I'm just going to stay with my current version 
of cmake for the time being.

-Hazen

Re: [Plplot-devel] Can not commit to the repository

[Arjen M. <Arj...@de...>]

Hi Alan,



>
> I wonder if you might have cloned from the wrong, read-only URL.  You actually did
> this in the past, and at the time someone had a suggestion for adjusting so you
> could push, but I have forgotten what that was, and it might be better to start again
> from scratch. Anyhow, I suggest you try cloning from the read-write URL which you
> can find by logging into SF, then looking at the git URL choices given at
>
> https://sourceforge.net/p/plplot/plplot/ci/master/tree/
>
> You should use the "RW" one for cloning and not the "RO" or "HTTP" ones.
>
Yes, that is indeed the problem - because of the rather intensive work we did the last couple of weeks, I messed up my working directories and the corresponding repositories. This will take a couple of minutes only to restore.

Sorry for the noise.

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] Can not commit to the repository

[Alan W. I. <ir...@be...>]

Arjen said:

> I just made some changes to the Fortran documentation, but for a
reason that is not explained I cannot commit it:


> $ git push origin master
> fatal: Could not read from remote repository.

>Please make sure you have the correct access rights
> and the repository exists.


> It may be because I recently changed my password on SF - that is the
only reason I can think of, but I always need to type in a password
anyway. So I am at a dead end. Any suggestions?

I wonder if you might have cloned from the wrong, read-only URL.  You
actually did this in the past, and at the time someone had a
suggestion for adjusting so you could push, but I have forgotten what
that was, and it might be better to start again from scratch. Anyhow,
I suggest you try cloning from the read-write URL which you can find
by logging into SF, then looking at the git URL choices given at

https://sourceforge.net/p/plplot/plplot/ci/master/tree/

You should use the "RW" one for cloning and not the "RO" or "HTTP" ones.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Can not commit to the repository

[Arjen M. <Arj...@de...>]

Hi everyone,



I just made some changes to the Fortran documentation, but for a reason that is not explained I cannot commit it:


$ git push origin master
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.




It may be because I recently changed my password on SF - that is the only reason I can think of, but I always need to type in a password anyway. So I am at a dead end. Any suggestions?



Regards,



Arjen




Arjen Markus
Sr. Adviseur/Onderzoeker
T

+31(0)88335 8559

E

arj...@de...




[Logo]<http://www.deltares.com/>

 www.deltares.com<http://www.deltares.com/>

Postbus 177
2600 MH Delft

[Deltares Twitter]
<http://www.twitter.com/deltares>

[Deltares LinkedIn]<http://www.linkedin.com/company/217430>

[Deltares Facebook]<https://www.facebook.com/pages/Deltares/154189334634001>



[Think before printing]Please consider the environment before printing this email
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] Qt5 / cmake error

[Alan W. I. <ir...@be...>]

On 2016-01-21 21:23-0500 Hazen Babcock wrote:

>
> Hello,
>
> As Qt4 is now at least technically no longer supported I thought I might 
> spend some time to see if I could get our PyQt bindings to work with Qt5. 
> However unfortunately I can't even build PLplot with Qt5 due to a cmake 
> error. Any suggestions would be appreciated.
>
> The error message:
>
> CMake Error at bindings/qt_gui/CMakeLists.txt:54 (target_link_libraries):
>  The plain signature for target_link_libraries has already been used with
>  the target "plplotqt".  All uses of target_link_libraries with a target
>  must be either all-keyword or all-plain.
>
>  The uses of the plain signature are here:
>
>   * /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreMacros.cmake:278 
> (target_link_libraries)
>
>
> I used this command in my build directory:
> cmake -DPLPLOT_USE_QT5=ON ../plplot > cmake.txt 2>&1

Hi Hazen:

If you compare the two target_link_libraries commands on the exact
lines mentioned in the error message, bindings/qt_gui/CMakeLists.txt
uses the PRIVATE keyword, and Qt5CoreMacros.cmake uses no keywords at
all, and apparently from the error message that combination of keyword
signature and plain text signature for target_link_libraries commands
for the same target is not allowed by CMake.

I had success with a build of PLplot against Qt5 some time ago.  But I am pretty
sure that predated May 2015 when "git blame" tells me I introduced
that PRIVATE keyword in bindings/qt_gui/CMakeLists.txt.  So I would
try locally removing PRIVATE from the offending line in
bindings/qt_gui/CMakeLists.txt.  That might introduce some
overlinking issues, but I don't think you have to be concerned with
those.

Also, please follow the advice in the first two lines of cmake.txt,
namely

-- WARNING: CMAKE_VERSION = 3.2.2 is in the range from 3.2 through 3.3.1 which has
    a compromised find ability that was fixed in 3.3.2.  Please upgrade to 3.3.2 or greater.

I suggest trying 3.3.2 instead of exploring 3.4.x territory just yet
because we have a lot of good experience with 3.3.2, and we have little
experience of any kind with 3.4.x.

Anyhow, with the above workaround and CMake-3.3.2, I think you
should likely be able to build PLplot against Qt5, but let me
know if you encounter any further issues.

By the way, Qt4 is virtually CMake-unaware so that CMake has to do
everything for it in house (but in a well-understood and stable way
that virtually always works).  In contrast Qt5 supplies a lot of CMake
support files that help CMake figure out how to build software against
Qt5, but there is a lot of churn on both the CMake side and Qt5 side
on how the two work together. Part of that churn is there are about 4
different build methods of various vintages that are supported for the
two working together.  I chose the most modern of those methods that
was available for our minimum CMake version at the time, but our CMake
minimum version is higher now so I might be able to use a still more
modern build method which might avoid the above issue altogether.
Although I don't have time to explore that possibility any time soon,
it is something to keep in mind for the future.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] My plans for further work during this release cycle

[Arjen M. <Arj...@de...>]

Hi Alan,



I will do so - pity that f90ppr is not really up to the task. I wouldn't have thought that Michel Olagnon (the author of the tool) kept to this 7th column convention. I think of reasons, but not particularly good ones ;).



I have some minor edits to apply to the new Fortran documentation, I hope I can do that today.



Regards,



Arjen





> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, January 22, 2016 4:23 AM
> To: Arjen Markus; PLplot development list
> Subject: Re: [Plplot-devel] My plans for further work during this release cycle
>
> On 2016-01-21 02:24-0800 Alan W. Irwin wrote:
>
> > * Tidy/beautify our Fortran code which is currently in an identation
> > mess.
>
> Hi Arjen:
>
> I finally finished the above using emacs.  For details look at the commit message at
> <http://sourceforge.net/p/plplot/plplot/ci/75414e4bcaabf2ad99baa0f31bf28a4869bb0
> fe6/>
>
> Could you please look at the resulting Fortran source in bindings/f95 and
> examples/f95 to make sure you (and especially your favorite
> editor) are happy with the current indentation scheme (which is simply that each
> indentation level adds 4 additional spaces except for continuation lines which add 7
> spaces).
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux
> Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

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] My plans for further work during this release cycle

[Alan W. I. <ir...@be...>]

On 2016-01-21 02:24-0800 Alan W. Irwin wrote:

> * Tidy/beautify our Fortran code which is currently in an identation
> mess.

Hi Arjen:

I finally finished the above using emacs.  For details look at
the commit message at
<http://sourceforge.net/p/plplot/plplot/ci/75414e4bcaabf2ad99baa0f31bf28a4869bb0fe6/>

Could you please look at the resulting Fortran source in bindings/f95
and examples/f95 to make sure you (and especially your favorite
editor) are happy with the current indentation scheme (which is 
simply that each indentation level adds 4 additional spaces except for
continuation lines which add 7 spaces).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 / cmake error

[Greg J. <gv...@gm...>]

I know that one, it came up for me when building a new shared library
and one of the target_link_libraries() calls included "PRIVATE" as a keyword
(i.e., exactly what it said).  I took out the "PRIVATE " and it worked.
What that all means, I don't know! the result worked out for linux.

http://sourceforge.net/p/gnudatalanguage/patches/95/#4f41/b267



On Thu, Jan 21, 2016 at 6:23 PM, Hazen Babcock <hba...@ma...> wrote:

>
> Hello,
>
> As Qt4 is now at least technically no longer supported I thought I might
> spend some time to see if I could get our PyQt bindings to work with Qt5.
> However unfortunately I can't even build PLplot with Qt5 due to a cmake
> error. Any suggestions would be appreciated.
>
> The error message:
>
> CMake Error at bindings/qt_gui/CMakeLists.txt:54 (target_link_libraries):
>   The plain signature for target_link_libraries has already been used with
>   the target "plplotqt".  All uses of target_link_libraries with a target
>   must be either all-keyword or all-plain.
>
>   The uses of the plain signature are here:
>
>    * /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreMacros.cmake:278
> (target_link_libraries)
>
>
> I used this command in my build directory:
> cmake -DPLPLOT_USE_QT5=ON ../plplot > cmake.txt 2>&1
>
> CMake log files attached.
>
> lubuntu 15.10.
>
> > uname -a
> Linux Dell-XPS-8100 4.2.0-25-generic #30-Ubuntu SMP Mon Jan 18 12:31:50
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> -Hazen
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

[Plplot-devel] Qt5 / cmake error

[Hazen B. <hba...@ma...>]

Hello,

As Qt4 is now at least technically no longer supported I thought I might 
spend some time to see if I could get our PyQt bindings to work with 
Qt5. However unfortunately I can't even build PLplot with Qt5 due to a 
cmake error. Any suggestions would be appreciated.

The error message:

CMake Error at bindings/qt_gui/CMakeLists.txt:54 (target_link_libraries):
   The plain signature for target_link_libraries has already been used with
   the target "plplotqt".  All uses of target_link_libraries with a target
   must be either all-keyword or all-plain.

   The uses of the plain signature are here:

    * /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreMacros.cmake:278 
(target_link_libraries)


I used this command in my build directory:
cmake -DPLPLOT_USE_QT5=ON ../plplot > cmake.txt 2>&1

CMake log files attached.

lubuntu 15.10.

 > uname -a
Linux Dell-XPS-8100 4.2.0-25-generic #30-Ubuntu SMP Mon Jan 18 12:31:50 
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

-Hazen

Re: [Plplot-devel] My plans for further work during this release cycle

[Alan W. I. <ir...@be...>]

On 2016-01-21 02:24-0800 Alan W. Irwin wrote:

> * Tidy/beautify our Fortran code which is currently in an identation
> mess.  I am currently researching a GPL'd tool called f90ppr to do
> this.

That idea turned out to be a waste of time.  I locally built that
tool, and it does impose a uniform style on the Fortran files it
processes.  But I dislike that style.  The first level of indentation
is always 7 blanks (which is obviously a style left over from Fortran
77 fixed-length days), but more importantly in my view it changes
every empty line into one with a single blank, and we definitely don't want
such trailing blanks in our source code.

I have just now noticed some documentation of the emacs f90-mode at
<http://web.mit.edu/Emacs/source/emacs-23.1/lisp/progmodes/f90.el> which
implies you have easy and straightforward control of the indentation
spacing.  So I will try that method to force each level of indentation
to add 4 blanks to be consistent with our C code style.  If I like
that result, then I know of a straightforward way to use emacs to
style all our Fortran source.

More later.

Alan

[Plplot-devel] My plans for further work during this release cycle

[Alan W. I. <ir...@be...>]

Here are my ToDo lists for some remaining things I want to do with the
Fortran binding that just landed and also some further general PLplot
issues I want to address before the release. None of these topics are
release critical, but they are all in the "would be nice" category.

I assume most of these issues are "only" going to take from just a few
hours to a few days each to address, but there sure are a lot of them!
Anyhow, I would like to get through all the Fortran ones and most of
the others before even starting to plan when the forthcoming release
of 5.12.0 should occur (with the "12" in honor of the major change in
the Fortran binding and examples).

____________________________________________________

Fortran binding:

* Tidy/beautify our Fortran code which is currently in an identation
mess.  I am currently researching a GPL'd tool called f90ppr to do
this.  It's a dead project (no development for more than a decade),
but a lot of people swear by it, and I could easily revive it again by
storing its Fortran 90 (!) source code plus a CMake-based build system I
plan to implement myself as a subproject under the epa_build umbrella.

* Replace all use of plflt by test_flt in the examples and set this
type for arbitrary precision testing purposes in plplot.f90.  We still
provide plflt for backwards compatibility for users, but it is
strongly deprecated so I want it removed from our examples.  However,
an arbitrary kind values called test_flt should be of little interest
to users because of its name, and it is extremely useful for
developmental testing of our examples to force the case where the
example floating-point precision disagrees with PLFLT configured for
our C library.

* Redo sed script to generate included_plplot_parameters.f90

* Systematically update testing of all dimensions when
there are multiple associated arrays in the argument list
following what is done in bindings/swig-support/plplotcapi.i.
Ultimately, there should be a complete list of functions in README.release where
the API has been changed because of this.  (Note, this topic was
recently discussed on list, and the consensus is this is the correct
way to test dimension consistency.)

* Add plcont, plshade, and plshades real Fortran callback API (as
opposed to the xg, and yg 1D and 2D arguments we have always used
before to simulate Fortran callback functionality.  (We will
continue to support those variants for backwards compatibility.)

* Test the routines that have callback arguments with every variant of the callbacks
(to make sure there are no typographical errors in our interface for the callbacks).

____________________________________________________

Other PLplot issues I have noticed and would like to fix
"soon".

* search for trailing whitespace and fix it.  Arjen's editor caught a
lot of those during our collaboration on the new Fortran binding
private topic branch, but I am sure there are more that need to be
addressed.  After the issue is fixed, I vaguely recall there is a git
configuration item that can automatically keep our source code clean
of such issues.  But just running a trailing-whitespace-cleanup script
periodicially might be a better solution.

* c_plparseopts API change (that function messes with its arguments
a lot by design so that const attribute should be removed.)

* All returned values from functions changed from type of int
to PLINT. This affects c_plparseopts and plsetopt amongst others?

* test_diff_psc generates two runs of the examples to generate
the results.  Fix that build-system bug which I very
likely introduced myself.

* test blank in source, build, and install directory names.

* Documentation problems I am currently aware of that need addressing.

i. All changes above, e.g., plparsopts, plsetopt changes

ii. plerrx, plerry, plurals

iii. plimage zmin, zmax 0, 0 (this is from handwritten notes, and I
am not sure what the issue is there).

iv. Add plpat documentation

v. plmapstring is not tested in any example.

vi. Callback documentation should be done consistently with named
arguments and discussion of each of those arguments. I need to check
what has already been done for plfill, pltr0, pltr1, and pltr2
callbacks and fix those if required, but this improvement definitely
is required for the documentation of the label_func callback
(currently documented without last argument within the plslabelfunc
documentation), the coordinate_transform callback (currently
documented within the plstransform documentation), and the mapform
callback (repeatedly documented without naming arguments for each of
the plmap* routines as well as the plmeridians routine).

* -dev svg should be used by default for all tests rather than -dev
psc since the former is a full-fledged modern device driver that does
essentially everything correctly so it tests our C and bindings API's
to the limit while the latter often just produces incorrect results
(e.g., anything having to do with unicode text, alpha-transparent,
gradients, or text size) from our examples so our PostScript
difference testing merely assures us that the garbage produced is the
same for C and our language bindings.

* Lena replaced by Westie as discussed on list.

----------------------------------------------------------------

Post-release

* The rare fill issues that occur.  This may be promoted to the above
"would be nice" category if Phil can come up with even a complicated
example I can test here.

* Use arbitrary units (mm, pt, and pixels) for -dev svg just to explore what
is possible (I have an svg private topic branch for this, but it has
been a while since I worked on it).

* Remove "c_" prefix.  I just realized the current "c_" prefix manipulations are
essential for the old_f95 binding and examples.  So I don't have to
worry about this change until we finally get rid of the old_f95
approach (probably at least several releases from now depending on the
reception our new Fortran binding gets from our users.)

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________