Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Alan W. Irwin]

On 2015-06-01 17:32-0400 Jim Dishaw wrote:

>>> On May 31, 2015, at 9:32 PM, Alan W. Irwin  
>>> wrote:
>>> The remaining warnings are
>>>
>>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
>>> ‘read_header’:
>>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: warning: 
>>> ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
>>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:306:9: note: 
>>> ‘pdf_rc’ was declared here
>>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
>>> ‘plreadmetafile’:
>>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:378:23: warning: 
>>> ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1117:14: note: ‘plm’ 
>>> was declared here
>>>
>
> I think these two patches will fix the warnings (I don’t get any warnings 
> with clang, but it does not have the -Wmaybe-uninitialized option).

The above warnings were fixed by your two commits.

Pushed and thanks!

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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Jim Dishaw]

> On May 31, 2015, at 10:11 PM, Jim Dishaw  wrote:
> 
> Yep, I will take a look
> 
> 
> 
>> On May 31, 2015, at 9:32 PM, Alan W. Irwin  wrote:
>> 
>>> On 2015-05-31 22:06+0100 Phil Rosenberg wrote:
>>> 
>>> Hi Alan
>>> You should now find that the plbuf.c warning is gone. I haven't
>>> touched the plmeta files. I will leave these to Jim as I don't know
>>> that code well.
>> 
>> @ Phil: I confirm you fix, and thanks!
>> 
>> @Jim:
>> 
>> The remaining warnings are
>> 
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
>> ‘read_header’:
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: warning: 
>> ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:306:9: note: ‘pdf_rc’ 
>> was declared here
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
>> ‘plreadmetafile’:
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:378:23: warning: 
>> ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1117:14: note: ‘plm’ 
>> was declared here
>> 

I think these two patches will fix the warnings (I don’t get any warnings with 
clang, but it does not have the -Wmaybe-uninitialized option). 



0001-Fixed-uninitialized-value-warning-in-plreadmetafile.patch
Description: Binary data


0002-Fixed-uninitialized-variable-error-in-read_entry.patch
Description: Binary data
 

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Jim Dishaw]

Yep, I will take a look



> On May 31, 2015, at 9:32 PM, Alan W. Irwin  wrote:
> 
>> On 2015-05-31 22:06+0100 Phil Rosenberg wrote:
>> 
>> Hi Alan
>> You should now find that the plbuf.c warning is gone. I haven't
>> touched the plmeta files. I will leave these to Jim as I don't know
>> that code well.
> 
> @ Phil: I confirm you fix, and thanks!
> 
> @Jim:
> 
> The remaining warnings are
> 
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
> ‘read_header’:
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: warning: 
> ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:306:9: note: ‘pdf_rc’ 
> was declared here
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
> ‘plreadmetafile’:
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:378:23: warning: ‘plm’ 
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1117:14: note: ‘plm’ 
> was declared here
> 
> Would you please take responsibility for analyzing these and either
> fixing (if possibility exists for using uninitialized value) or
> else squelching by doing a dummy initialization with comment (if false alarm)?
> 
> 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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Alan W. Irwin]

On 2015-05-31 22:06+0100 Phil Rosenberg wrote:

> Hi Alan
> You should now find that the plbuf.c warning is gone. I haven't
> touched the plmeta files. I will leave these to Jim as I don't know
> that code well.

@ Phil: I confirm you fix, and thanks!

@Jim:

The remaining warnings are

/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
‘read_header’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: warning: ‘pdf_rc’ 
may be used uninitialized in this function [-Wuninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:306:9: note: ‘pdf_rc’ 
was declared here
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
‘plreadmetafile’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:378:23: warning: ‘plm’ 
may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1117:14: note: ‘plm’ was 
declared here

Would you please take responsibility for analyzing these and either
fixing (if possibility exists for using uninitialized value) or
else squelching by doing a dummy initialization with comment (if false alarm)?

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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Phil Rosenberg]

Hi Alan
You should now find that the plbuf.c warning is gone. I haven't
touched the plmeta files. I will leave these to Jim as I don't know
that code well.

Phil

On 31 May 2015 at 20:14, Alan W. Irwin  wrote:
> On 2015-05-31 18:59+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>> I've worked this out, the line in question is in a function called
>> with the possibly uninitialized variable.
>> I'm writing the code now to double check everything although the only
>> case where we could get an uninitialized variable would be for a
>> corrupted buffer.
>
>
> Hi Phil:
>
> Our e-mails crossed, but it is great to read above you are analyzing
> the situation and figuring out the source of these warnings. When I
> see your commit with the fix for these warnings, I will follow up by
> trying the same build test again.
>
>
> 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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Alan W. Irwin]

On 2015-05-31 18:59+0100 Phil Rosenberg wrote:

> Hi Alan
> I've worked this out, the line in question is in a function called
> with the possibly uninitialized variable.
> I'm writing the code now to double check everything although the only
> case where we could get an uninitialized variable would be for a
> corrupted buffer.

Hi Phil:

Our e-mails crossed, but it is great to read above you are analyzing
the situation and figuring out the source of these warnings. When I
see your commit with the fix for these warnings, I will follow up by
trying the same build test again.

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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Alan W. Irwin]

On 2015-05-31 18:33+0100 Phil Rosenberg wrote:

> Hi Alan
> I'm attacking my to do list. Do you still get these warnings? I just
> looked and the line 1309 no longer makes sense in terms of a reference
> to cmd so I guess the code has changed since then. I don't get any
> unallocated variable warnings for plbuf in VC++ so perhaps someone
> else fixed this issue.

With the following compiler options:

CFLAGS=-O3 -fvisibility=hidden -Wuninitialized

and gcc on Linux, the following warnings are
generated from building the plplot target:

/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
‘read_header’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:341:8: warning: ‘pdf_rc’ 
may be used uninitialized in this function [-Wuninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:306:9: note: ‘pdf_rc’ 
was declared here
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
‘plreadmetafile’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:378:23: warning: ‘plm’ 
may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1117:14: note: ‘plm’ was 
declared here
[...]
/home/software/plplot/HEAD/plplot.git/src/plbuf.c: In function ‘rdbuf_bop’:
/home/software/plplot/HEAD/plplot.git/src/plbuf.c:1309:11: warning: ‘cmd’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
/home/software/plplot/HEAD/plplot.git/src/plbuf.c:593:19: note: ‘cmd’ was 
declared here

You should be able to replicate this on your Linux box and probably
also on your Cygwin platform.

> On 12 March 2015 at 20:14, Alan W. Irwin  wrote:
>>
>> gcc is generating these warnings when building libplplot.  Would you
>> please take a look to see whether this is either a real uninitialized issue
>> that needs to be fixed or a false alarm?

My guess is these are all due to false alarms from gcc, but if your
analysis says that is the case it is also worth squelching
these warnings by dummy initializing some variables with appropriate comment
like

// To squelch spurious gcc uninitialized warnings
 PLINT i=0; // or whatever is needed

so that real and useful warnings from gcc considering uninitialized
variables will not be obfuscated by known false alarms.

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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Phil Rosenberg]

Hi Alan
I've worked this out, the line in question is in a function called
with the possibly uninitialized variable.
 I'm writing the code now to double check everything although the only
case where we could get an uninitialized variable would be for a
corrupted buffer.

Phil

On 31 May 2015 at 18:33, Phil Rosenberg  wrote:
>  Hi Alan
> I'm attacking my to do list. Do you still get these warnings? I just
> looked and the line 1309 no longer makes sense in terms of a reference
> to cmd so I guess the code has changed since then. I don't get any
> unallocated variable warnings for plbuf in VC++ so perhaps someone
> else fixed this issue.
>
> Phil
>
> On 12 March 2015 at 20:14, Alan W. Irwin  wrote:
>> To Phil:
>>
>> gcc is generating these warnings when building libplplot.  Would you
>> please take a look to see whether this is either a real uninitialized issue
>> that needs to be fixed or a false alarm?
>>
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function
>> ‘read_header’:
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:336:8: warning:
>> ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:301:9: note: ‘pdf_rc’
>> was declared here
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function
>> ‘plreadmetafile’:
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:373:23: warning:
>> ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1112:14: note: ‘plm’
>> was declared here
>> []
>> /home/software/plplot/HEAD/plplot.git/src/plbuf.c: In function ‘rdbuf_bop’:
>> /home/software/plplot/HEAD/plplot.git/src/plbuf.c:1309:11: warning: ‘cmd’
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>> /home/software/plplot/HEAD/plplot.git/src/plbuf.c:593:19: note: ‘cmd’ was
>> declared here
>>
>> 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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Phil Rosenberg]

 Hi Alan
I'm attacking my to do list. Do you still get these warnings? I just
looked and the line 1309 no longer makes sense in terms of a reference
to cmd so I guess the code has changed since then. I don't get any
unallocated variable warnings for plbuf in VC++ so perhaps someone
else fixed this issue.

Phil

On 12 March 2015 at 20:14, Alan W. Irwin  wrote:
> To Phil:
>
> gcc is generating these warnings when building libplplot.  Would you
> please take a look to see whether this is either a real uninitialized issue
> that needs to be fixed or a false alarm?
>
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function
> ‘read_header’:
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:336:8: warning:
> ‘pdf_rc’ may be used uninitialized in this function [-Wuninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:301:9: note: ‘pdf_rc’
> was declared here
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function
> ‘plreadmetafile’:
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:373:23: warning:
> ‘plm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1112:14: note: ‘plm’
> was declared here
> []
> /home/software/plplot/HEAD/plplot.git/src/plbuf.c: In function ‘rdbuf_bop’:
> /home/software/plplot/HEAD/plplot.git/src/plbuf.c:1309:11: warning: ‘cmd’
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> /home/software/plplot/HEAD/plplot.git/src/plbuf.c:593:19: note: ‘cmd’ was
> declared here
>
> 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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-04-10 21:54+0100 Andrew Ross wrote:

>
> Hazen,
>
> That's interesting, and at odds with my tests a week or so back on Kubuntu
> 14.10. Can you confirm which flavour and version of Ubuntu you are using?
> Also, I assume this is with Qt4 and not Qt5?

Hi Andrew:

The answers to your questions have been scattered a bit in different
threads so to collect them together for you here, Hazen used Qt4.8.6,
and Lubuntu, and today he said he was pretty sure the version was
14.04.2 LTS. And he recently attached a detailed valgrind report that
showed all sorts of invalid reads for one of the qt devices on his
Lubuntu platform.  (Interestingly, the invalid reads occurred during
initialization rather than the cases we have looked at in the past
where invalid reads occurred at plend.)

So if you run that specific valgrind test on your own kubuntu version
and do not confirm the severe memory management errors, then that is a
pretty clear demonstration of a Lubuntu Qt bug, and if the Qt
packaging for Lubuntu is identical to that used for every other
variant besides Kubuntu, then it is likely a non-Kubuntu Ubuntu bug.

Since there is only a 6-month difference between 14.04.2 LTS and 14.10
and we never appear to get such severe memory management issues for at
least two variants of Debian (which sticks pretty close to the
upstream version of Qt) there is a decent chance this bug has nothing
to do with upstream Qt and instead is due to some difference in
patching between the Lubuntu Qt patches that are applied and the
Kubuntu patches that are applied to the upstream version. Anyhow,
those package patches and the equivalent package patches for the
Debian cases are the first place I would look for a relevant
difference between the various versions that work, and the one or more
(Lubuntu and possibly Ubuntu) versions that do not.

If you can pin this issue down to a package patch that was applied or
not, that is well worth a bug report to Ubuntu since it is in our
interest to have Qt working properly on all variants of Ubuntu.

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
__

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: last major uncertainty removed

[Alan W. Irwin]

I am happy to report that the epa_built "plplot_lite" comprehensive
test on the MinGW/MSYS/Wine platform completed in 30 hours.  One
component of this test had to be repeated to get good results (see
note (K) at
).
That repeated test and the rest of the comprehensive tests all gave no
errors so I judge this result to be a success.

Arjen has encountered that parallel-build issue with MSYS before so
from now on (as stated in note (K)) I think we should turn off all
parallel aspects of epa_build on MSYS using the epa_build cmake option
-DNUMBER_PARALLEL_JOBS:STRING=1 which will likely double the time
required to finish this test again in my case (a two-cpu box).  Note,
you should _not_ use this option for Cygwin or MinGW-w64/MSYS2 where
parallel builds should work just fine and make the comprehensive test
finish much more quickly on machines that have more than one cpu.

With regard to the release status, this successful comprehensive test
result for MinGW/MSYS2/Wine removes the last major uncertainty with
this release and the remainder of the release process should just be
"turning the crank" using the instructions in
README.Release_Manager_Cookbook.  So I am hoping my next post here (in
a few hours) will be a report of the actual release.  Meanwhile, (and
of course) the hard freeze on commits to the master branch still exists.

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
__

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Hazen Babcock]

On 04/10/2015 09:06 PM, Alan W. Irwin wrote:
> On 2015-04-10 12:29-0400 Hazen Babcock wrote:
>
>>>
>>> That's a fairly sparse but still acceptable comprehensive test result
>>> for
>>> this release, but to start the next release cycle properly I strongly
>>> encourage everybody here to learn to run the
>>> scripts/comprehensive_test.sh bash script to completion on all
>>> platforms accessible to you (taking the approach that you should
>>> disable any PLplot component that has errors in order to get the
>>> script to complete).  Such tests are encouraged for essentially all
>>> platforms (e.g, MSVC, Cygwin, MinGW/MSYS, MinGW-w64/MSYS2, Mac OS X,
>>> all varieties of Linux distributions, and other Unices).
>>
>> I just tried to run the non-interactive comprehensive tests on lubuntu
>> without success. Perhaps it is because I'm not running the tests
>> properly? The QT devices that are causing the problems work fine if I
>> run them by hand. I looked on the sourceforge wiki but I could not
>> find and instructions on how to do this. Attached is what I tried and
>> the results of the test.
>
> Hi Hazen:
>
> Thanks for helping out with comprehensive testing.
>
> To answer your question, you should look at
>  in general and
> 
>
> and
> https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> in specific for directions and results concerning comprehensive testing.
>
> The script results require no special setup other than what you do for
> your hand-crafted builds.  Greg had similar problems (but on the
> OpenSUSE platform) with segfaults for all Qt related ctest results.
>
> I suspect these severe memory management issues (which sometimes but
> not always will generate segfaults like you and Greg have seen) have
> nothing to do with PLplot but are instead due to bad Qt libraries or
> bad Qt library dependencies on some platforms. In contrast to your
> result and Greg's I have looked hard at qt results with valgrind on
> Debian stable, and they have no severe memory management issues with
> Qt4.8, and I think Andrew has done the same for his various Debian and
> Ubuntu platforms.  Andrew and I do have different severe memory
> management results for the Qt5 case; I get them with the epa_build of
> Qt5, and he does not for several different distros.  But Qt4 has
> always been completely reliable in this regard for us _for the
> platforms we have access to_.  But this is obviously not the case for
> you and Greg.
>
> Anyhow, for now we are just trying to keep track of exactly which
> platforms have good qt results with Qt4.8 and which do not.  However, we
> are
> also interested in exactly which components of PLplot work for all our
> different major configurations (shared libraries/dynamic devices,
> shared libraries/non-dynamic devices, and static libraries/non-dynamic
> devices. Thus, please try to get the script to finish
> with components removed that are giving trouble.  (I gave that same
> advice to Greg).
>
> So, for example, to
> drop everything Qt related you should specify
>
> --cmake_added_options "DEFAULT_NO_QT_DEVICES=ON -DENABLE_qt=OFF"
>
> when attempting to run scripts/comprehensive_testing.sh again.
>
> Once you get that script to complete, we will note in the
> corresponding report on the Wiki exactly which components had to be
> dropped and why.

It worked fine without the Qt components. Is there an output file that I 
should send?

Why do you think these Qt components fail in the tests, but work fine if 
they are run independently? What is the testing framework doing that is 
not being done from the command line?

-Hazen

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-04-10 21:54+0100 Andrew Ross wrote:

> [Hazen's poor qt result is] at odds with my tests a week or so back on Kubuntu
> 14.10.

Hi Andrew:

Could you please report the details of those good comprehensive test
results at


Thanks in advance.

Alan

__
Alan W. Irwin

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

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

Linux-powered Science
__

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-04-10 12:29-0400 Hazen Babcock wrote:

>> 
>> That's a fairly sparse but still acceptable comprehensive test result for
>> this release, but to start the next release cycle properly I strongly
>> encourage everybody here to learn to run the
>> scripts/comprehensive_test.sh bash script to completion on all
>> platforms accessible to you (taking the approach that you should
>> disable any PLplot component that has errors in order to get the
>> script to complete).  Such tests are encouraged for essentially all
>> platforms (e.g, MSVC, Cygwin, MinGW/MSYS, MinGW-w64/MSYS2, Mac OS X,
>> all varieties of Linux distributions, and other Unices).
>
> I just tried to run the non-interactive comprehensive tests on lubuntu 
> without success. Perhaps it is because I'm not running the tests properly? 
> The QT devices that are causing the problems work fine if I run them by hand. 
> I looked on the sourceforge wiki but I could not find and instructions on how 
> to do this. Attached is what I tried and the results of the test.

Hi Hazen:

Thanks for helping out with comprehensive testing.

To answer your question, you should look at
 in general and

and
https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
in specific for directions and results concerning comprehensive testing.

The script results require no special setup other than what you do for
your hand-crafted builds.  Greg had similar problems (but on the
OpenSUSE platform) with segfaults for all Qt related ctest results.

I suspect these severe memory management issues (which sometimes but
not always will generate segfaults like you and Greg have seen) have
nothing to do with PLplot but are instead due to bad Qt libraries or
bad Qt library dependencies on some platforms. In contrast to your
result and Greg's I have looked hard at qt results with valgrind on
Debian stable, and they have no severe memory management issues with
Qt4.8, and I think Andrew has done the same for his various Debian and
Ubuntu platforms.  Andrew and I do have different severe memory
management results for the Qt5 case; I get them with the epa_build of
Qt5, and he does not for several different distros.  But Qt4 has
always been completely reliable in this regard for us _for the
platforms we have access to_.  But this is obviously not the case for
you and Greg.

Anyhow, for now we are just trying to keep track of exactly which
platforms have good qt results with Qt4.8 and which do not.  However, we are
also interested in exactly which components of PLplot work for all our
different major configurations (shared libraries/dynamic devices,
shared libraries/non-dynamic devices, and static libraries/non-dynamic
devices. Thus, please try to get the script to finish
with components removed that are giving trouble.  (I gave that same
advice to Greg).

So, for example, to
drop everything Qt related you should specify

--cmake_added_options "DEFAULT_NO_QT_DEVICES=ON -DENABLE_qt=OFF"

when attempting to run scripts/comprehensive_testing.sh again.

Once you get that script to complete, we will note in the
corresponding report on the Wiki exactly which components had to be
dropped and why.

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
__

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Hazen Babcock]

On 04/10/2015 04:54 PM, Andrew Ross wrote:
>
> Hazen,
>
> That's interesting, and at odds with my tests a week or so back on Kubuntu
> 14.10. Can you confirm which flavour and version of Ubuntu you are using?
> Also, I assume this is with Qt4 and not Qt5?
>

Andrew,

This is what I have:
hb ~$ uname -a
Linux hbabcock-laptop2 3.13.0-49-generic #81-Ubuntu SMP Tue Mar 24 
19:29:48 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

hb ~$ qmake --version
QMake version 2.01a
Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu

-Hazen


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Andrew Ross]

Hazen,

That's interesting, and at odds with my tests a week or so back on Kubuntu
14.10. Can you confirm which flavour and version of Ubuntu you are using?
Also, I assume this is with Qt4 and not Qt5?

Andrew

On Fri, Apr 10, 2015 at 12:29:15PM -0400, Hazen Babcock wrote:
> >
> >That's a fairly sparse but still acceptable comprehensive test result for
> >this release, but to start the next release cycle properly I strongly
> >encourage everybody here to learn to run the
> >scripts/comprehensive_test.sh bash script to completion on all
> >platforms accessible to you (taking the approach that you should
> >disable any PLplot component that has errors in order to get the
> >script to complete).  Such tests are encouraged for essentially all
> >platforms (e.g, MSVC, Cygwin, MinGW/MSYS, MinGW-w64/MSYS2, Mac OS X,
> >all varieties of Linux distributions, and other Unices).
> 
> I just tried to run the non-interactive comprehensive tests on lubuntu
> without success. Perhaps it is because I'm not running the tests properly?
> The QT devices that are causing the problems work fine if I run them by
> hand. I looked on the sourceforge wiki but I could not find and instructions
> on how to do this. Attached is what I tried and the results of the test.
> 
> best,
> -Hazen
> 

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. Irwin]

On 2015-04-05 01:17-0700 Alan W. Irwin wrote:

> On 2015-04-04 23:11-0700 Greg Jung wrote:
>
>> afaict these environment variables are essential for plots:
>>
>> PLPLOT_DRV_DIR=/usr/local/lib/plplot5.10.0/drivers
>> PLPLOT_HOME=/usr/local/share/plplot5.10.0/
>>
>> DRV_DIR for dynamic loading, to get the driver_info files (.dll files
>> are to be pick
>> up in PATH) and PLPLOT_HOME for support files:
>
> Our build system has long (since 2000 or so) superseded those
> variables which are leftovers from the days when we essentially had no
> build system at all. So setting those varaiables should _never_ be
> needed. For example, I don't use them for any of my successful
> comprehensive testing of PLplot on the Linux and MinGW/MSYS platforms.
> Furthermore, they could introduce problems for your comprehensive testing
> issues on Cygwin. For example, the comprehensive testing script uses
> its own distinct build tree and install tree so using those variables
> to point to results from an entirely different install tree could
> introduce inconsistencies and also pollute build-tree results with
> install-tree results.  So my strong advice is to drop both
> PLPLOT_DRV_DIR and PLPLOT_HOME completely on all platforms with the
> possible exception of the advice Arjen gave to work around what I
> consider to be a bug in recent classical MSYS.
>
> My guess is you are following some severely dated documentation that still
> mentions PLPLOT_DRV_DIR and PLPLOT_HOME.  Could you tell me where that
> documentation is so I can update it to the post-2000 era?
>
> Thanks very much for including the script output in the tarball. The
> error occurred in the first attempt to run make.  So if you look at
> make.out it obviously has something to do with cairo so try removing
> all the cairo device drivers from the test (using
> -DDEFAULT_NO_CAIRO_DEVICES=ON which is much more convenient
> than setting all those -DPLD variables assocated with the many
> different cairo devices to
> OFF) and run the script again.

@Greg:

There is one issue with your script output that concerns me.  To quote
the relevant section from plplotcygwin.out

ctest_command=ctest
build_command=make
cmake_command=cmake -DENABLE_qt=OFF -DENABLE_wxwidgets=OFF -DPLD_wxwidgets=OFF
traditional_build_command=make

That cmake_command is not output from the script so I assume you
inserted that to show how you aliased cmake.  Thanks for that
additional information, but that change to the cmake command will
at minimum generate warnings (when cmake should be run without options
at all for the CMake-based build of the installed examples) 
and may generate subtle errors.

Instead you should simply use the script option

--cmake_added_options \
"-DENABLE_qt=OFF -DENABLE_wxwidgets=OFF -DPLD_wxwidgets=OFF"

and the script will use those options when necessary and drop them
when they should not be used.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. Irwin]

On 2015-04-04 23:11-0700 Greg Jung wrote:

> afaict these environment variables are essential for plots:
>
> PLPLOT_DRV_DIR=/usr/local/lib/plplot5.10.0/drivers
> PLPLOT_HOME=/usr/local/share/plplot5.10.0/
>
> DRV_DIR for dynamic loading, to get the driver_info files (.dll files
> are to be pick
> up in PATH) and PLPLOT_HOME for support files:

Our build system has long (since 2000 or so) superseded those
variables which are leftovers from the days when we essentially had no
build system at all. So setting those varaiables should _never_ be
needed. For example, I don't use them for any of my successful
comprehensive testing of PLplot on the Linux and MinGW/MSYS platforms.
Furthermore, they could introduce problems for your comprehensive testing
issues on Cygwin. For example, the comprehensive testing script uses
its own distinct build tree and install tree so using those variables
to point to results from an entirely different install tree could
introduce inconsistencies and also pollute build-tree results with
install-tree results.  So my strong advice is to drop both
PLPLOT_DRV_DIR and PLPLOT_HOME completely on all platforms with the
possible exception of the advice Arjen gave to work around what I
consider to be a bug in recent classical MSYS.

My guess is you are following some severely dated documentation that still
mentions PLPLOT_DRV_DIR and PLPLOT_HOME.  Could you tell me where that
documentation is so I can update it to the post-2000 era?

Thanks very much for including the script output in the tarball. The
error occurred in the first attempt to run make.  So if you look at
make.out it obviously has something to do with cairo so try removing
all the cairo device drivers from the test (using
-DDEFAULT_NO_CAIRO_DEVICES=ON which is much more convenient
than setting all those -DPLD variables assocated with the many
different cairo devices to
OFF) and run the script again.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Greg Jung]

afaict these environment variables are essential for plots:

PLPLOT_DRV_DIR=/usr/local/lib/plplot5.10.0/drivers
PLPLOT_HOME=/usr/local/share/plplot5.10.0/

DRV_DIR for dynamic loading, to get the driver_info files (.dll files
are to be pick
up in PATH) and PLPLOT_HOME for support files:
greg@Homerw7 /d/bld
$ ls $PLPLOT_DRV_DIR
cairo.dll  null.dll  qt.dll   wxwidgets.dll
  xwin.dll
cairo.driver_info  null.driver_info  qt.driver_info
wxwidgets.driver_info  xwin.driver_info
mem.dllps.dllsvg.dll  xfig.dll
mem.driver_infops.driver_infosvg.driver_info  xfig.driver_info

greg@Homerw7 /d/bld
$ ls $PLPLOT_HOME
cglobe.mapcmap0_white_bg.pal cmap1_gray.pal
examples usa.map
cmap0_alternate.pal   cmap1_blue_red.pal cmap1_highfreq.pal
globe.mapusaglobe.map
cmap0_black_on_white.pal  cmap1_blue_yellow.pal  cmap1_lowfreq.pal   plstnd5.fnt
cmap0_default.pal cmap1_default.pal  cmap1_radar.pal plxtnd5.fnt

The WIN32 warning will go away when the cmake_minimum_required() command is
the very first command. (and min is > 2.8.4)

greg@Homerw7 /usr/local/include
$ env | grep PKG
PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

The chatter in CMAKE tells you it detects three paths from PKG_CONFIG_PATH
and so it forms CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH with
whatever I've put there; if I had a non-empty LDFLAGS it would add
those to the mix, also.  All in addition to the traditional
list acquired at the outset.

I've now run the test again and it never goes beyond "make" from the
comprehensive test.
It can also have a make problem when run as if to simply build.  It
snags in a file comparison
of the cairo drivers during test_dyndrivers build.
I can however push the make along and complete the build.


Each of the steps in this comprehensive test may take a while
cmake -DENABLE_qt=OFF -DENABLE_wxwidgets=OFF -DPLD_wxwidgets=OFF in
the build tree
make VERBOSE=1 in the build tree
ERROR: make failed in the build tree

greg@Homerw7 /d/bld/plplot2-cygwin/shared/build_tree
$ tail ../output_tree/make.out
cd /d/bld/plplot2-cygwin/shared/build_tree/drivers &&
/opt/local/bin/cmake.exe -E compare_files
/d/bld/plplot2-cygwin/shared/build_tree/drivers/test_dyndrivers_dir/cairo.driver_info
/d/bld/plplot2-cygwin/shared/build_tree/drivers/cairo.driver_info
Files 
"/d/bld/plplot2-cygwin/shared/build_tree/drivers/test_dyndrivers_dir/cairo.driver_info"
to "/d/bld/plplot2-cygwin/shared/build_tree/drivers/cairo.driver_info"
are different.
drivers/CMakeFiles/test_cairo_dyndriver.dir/build.make:52: recipe for
target 'drivers/test_dyndrivers_dir/cairo.driver_info' failed
make[2]: *** [drivers/test_dyndrivers_dir/cairo.driver_info] Error 1
make[2]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
CMakeFiles/Makefile2:2703: recipe for target
'drivers/CMakeFiles/test_cairo_dyndriver.dir/all' failed
make[1]: *** [drivers/CMakeFiles/test_cairo_dyndriver.dir/all] Error 2
make[1]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
Makefile:147: recipe for target 'all' failed
make: *** [all] Error 2

greg@Homerw7 /d/bld/plplot2-cygwin/shared/build_tree
$ make VERBOSE=1 >& ../output_tree/make1.out &
[1] 5540
then the tail end of make1.out shows completion:

Scanning dependencies of target lena_file
make[2]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
make -f plplot_test/CMakeFiles/lena_file.dir/build.make
plplot_test/CMakeFiles/lena_file.dir/build
make[2]: Entering directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
/opt/local/bin/cmake.exe -E cmake_progress_report
/d/bld/plplot2-cygwin/shared/build_tree/CMakeFiles
[100%] Generating lena.pgm
cd /d/bld/plplot2-cygwin/shared/build_tree/plplot_test &&
/opt/local/bin/cmake.exe -E copy_if_different
/d/bld/plplot-5.11/examples/lena.pgm
/d/bld/plplot2-cygwin/shared/build_tree/plplot_test/lena.pgm
make[2]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
/opt/local/bin/cmake.exe -E cmake_progress_report
/d/bld/plplot2-cygwin/shared/build_tree/CMakeFiles
[100%] Built target lena_file
make[1]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
/opt/local/bin/cmake.exe -E cmake_progress_start
/d/bld/plplot2-cygwin/shared/build_tree/CMakeFiles 0

greg@Homerw7 /d/bld/plplot2-cygwin/shared/build_tree
So the stuff is built, but I have to test step-by-step.


On Sat, Apr 4, 2015 at 6:00 PM, Alan W. Irwin  wrote:
> On 2015-04-04 21:27- Arjen Markus wrote:
>
>> I had to suppress the test_interactive part as well as the traditional
>> build, but then it finished all right. See the attached tgz-file for the
>> details.
>
>
> I agree that limited Cygwin result looks good (other than the
> test_interactive and traditional parts). When time permits
> post-release it would be good to expand this limited Cygwin result to
> more components (via installing them on Cygw

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. Irwin]

On 2015-04-04 21:27- Arjen Markus wrote:

> I had to suppress the test_interactive part as well as the traditional build, 
> but then it finished all right. See the attached tgz-file for the details.

I agree that limited Cygwin result looks good (other than the
test_interactive and traditional parts). When time permits
post-release it would be good to expand this limited Cygwin result to
more components (via installing them on Cygwin) and also sorting out
the problems for the interactive and traditional parts of the test.
But for this release it shows at least these limited components work
for all our build configurations on Cygwin which is a great relief to
me as release manager after nothing worked for Greg.

To finish this off so I can post this result in the wiki for this
release could you also please send the script stderr and stdout output
that is normally sent to the screen?

To repeat what I told Greg recently, you can capture that script output with 
e.g.,

scripts/comprehensive_test.sh <-- options you used for that script> \
>& comprehensive_test.sh.out

Note that command will hang initially until you answer the question at
the end of comprehensive_test.sh.out that would ordinarily be sent to
the screen for the case where script output was not redirected (by
">&") to comprehensive_test.sh.out.

Thanks.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. Irwin]

On 2015-04-04 19:34- Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -Original Message-
>> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>> Sent: Saturday, April 04, 2015 9:04 PM
>> To: Arjen Markus
>> Cc: Greg Jung; Phil Rosenberg; Jim Dishaw; PLplot development list
>> Subject: RE: Release status: call for comprehensive testing: Cygwin
>>
>> Hi Arjen:
>>
>> It is very encouraging from my release manager perspective that all 
>> components of
>> PLplot that you have enabled on Cygwin appear to be working for the shared 
>> case
>> so long as you exclude the traditional build of the installed examples.  
>> >From the
>> output that you attached it appears a number of different things went wrong 
>> with that
>> traditional build and test of the installed examples.  We can address those 
>> post-
>> release.
>>
>>
>> @Greg
>>
>> This (mostly) good result from Arjen on Cygwin obviously is sharply in 
>> contrast with
>> your own results where not even ctest worked on that platform.  Therefore, I 
>> suggest
>> you get in touch with Arjen to figure out exactly what he did.  Then 
>> following that
>> procedure rigourously should give you similar good results, and probably 
>> even more
>> importantly we should be able to document exactly what you did that should be
>> avoided by others on Cygwin when they are running 
>> scripts/comprehensive_test.sh.
>>

> Alan, are you sure it's Cygwin and not MSYS/MinGW where Greg's problems occur?

On Cygwin even his initial make fails to build properly so clearly he
is doing something on that platform that you are sucessfully avoiding.
My very initial speculation there was he was not setting the environment
variable correctly to tell CMake how to correctly interpret WIN32
and CYGWIN on his Cygwin platform, and that may still be the issue for
him.

To keep topics straight the rest of this (other than the last
sentence) is about MSYS and MSYS2.

On MSYS2 (I cannot recall whether Greg has tried MSYS) make works, but
ctest completely fails at run-time.

I have seen some strange effects myself for that platform [MinGW/MSYS], 
unfortunately. I have to set:
>
> set PLPLOT_DRV_DIR=.../drivers
>
> that is set that environment variable to the directory that holds the 
> *.drvinfo files, besides prepending the PATH variable with the directory 
> containing the DLLs, even though things are running in the build tree. I 
> think that is the same problem as Greg is experiencing with his MSYS/MinGW 
> set-up.

The key code in question here is src/ltdl_win32.c where a call to
LoadLibraryA dynamically loads the devices on Windows platforms. I
have looked the documentation of that function at
.
There is says for both LoadLibrary (what we used before) and
LoadLibraryA that "... uses a standard search strategy to find the
module; for more information, see the Remarks." Those remarks then
refer to

where it says (item 6 in the order of what is searched for) that "The
directories that are listed in the PATH environment variable." So from
that you would conclude that if the devices are in the dll
subdirectory, and that subdirectory is on your PATH, then the dll's
corresponding to the device drivers should be found and ltdl_win32.c
should just work.  However, I must say that long Microsoft documentation
trail has so many "ifs, and, and buts" that it leaves a lot of room
for doubt that this whole process will work, and it is possible that
the latest MSYS that you are using deliberately interferes with this
process.

So proceeding by experiment, the whole process has worked both for you
and me historically when the call was to LoadLibrary, and I will soon
be testing the current code where the call is to LoadLibraryA.  But from
that documentation trail, I don't think that distinction matters so
I expect it will continue to work for me (since I continue to
use exactly the same MSYS and Wine that worked for me before), and
the issue may be in the more modern version of the classical MSYS that
you are trying now.

@Greg:

For the MSYS2 case, you first might want to temporarily try changing the
cmake logic in cmake/modules/drivers.cmake that currently reads

if(ENABLE_DYNDRIVERS AND WIN32_OR_CYGWIN)
   if(NOT CYGWIN)
   set(LTDL_WIN32 ON)
   set(LTDL_INCLUDE_DIR ${CMAKE_SOURCE_DIR}/include)
endif(NOT CYGWIN)
endif(ENABLE_DYNDRIVERS AND WIN32_OR_CYGWIN)

to

set(LTDL_WIN32)

i.e., to disable using the src/ltdl_win32.c code for the MSYS2 platform.
The above full logic disables that approach just for the Cygwin case on
Windows, and it is possible it should also be disabled for MSYS2.

@Arjen:

For my own MinGW/MSYS tests I am going to try both enabling and
disabling the src/ltdl_win32.c approach to see whether both
work for me.  If so, I will permanently change to disabling
src/ltdl_win32.c for the (classical) MSYS case 

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Saturday, April 04, 2015 9:04 PM
> To: Arjen Markus
> Cc: Greg Jung; Phil Rosenberg; Jim Dishaw; PLplot development list
> Subject: RE: Release status: call for comprehensive testing: Cygwin
>
> Hi Arjen:
>
> It is very encouraging from my release manager perspective that all 
> components of
> PLplot that you have enabled on Cygwin appear to be working for the shared 
> case
> so long as you exclude the traditional build of the installed examples.  
> >From the
> output that you attached it appears a number of different things went wrong 
> with that
> traditional build and test of the installed examples.  We can address those 
> post-
> release.
>
>
> @Greg
>
> This (mostly) good result from Arjen on Cygwin obviously is sharply in 
> contrast with
> your own results where not even ctest worked on that platform.  Therefore, I 
> suggest
> you get in touch with Arjen to figure out exactly what he did.  Then 
> following that
> procedure rigourously should give you similar good results, and probably even 
> more
> importantly we should be able to document exactly what you did that should be
> avoided by others on Cygwin when they are running 
> scripts/comprehensive_test.sh.
>
Alan, are you sure it's Cygwin and not MSYS/MinGW where Greg's problems occur? 
I have seen some strange effects myself for that platform, unfortunately. I 
have to set:

set PLPLOT_DRV_DIR=.../drivers

that is set that environment variable to the directory that holds the *.drvinfo 
files, besides prepending the PATH variable with the directory containing the 
DLLs, even though things are running in the build tree. I think that is the 
same problem as Greg is experiencing with his MSYS/MinGW set-up.

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.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. Irwin]

On 2015-04-04 15:31- Arjen Markus wrote:

> Hi Alan,
>
>
>
>>  -Original Message-
>> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>>
>> @Arjen, Phil, and Jim:
>>
>> As release manager, that latter possibility of a regression in comprehensive 
>> testing
>> on the Cygwin platform really concerns me, and I ask at least one of you 
>> guys to
>> confirm/deny that possibility by simply running 
>> scripts/comprehensive_test.sh on
>> Cygwin with appropriate environmental variables set (ideally with a "source"
>> script that you run from using the bash "source" command to keep everything 
>> easily
>> and automatically reproducible) to setup the Cygwin platform for the PLplot 
>> build and
>> test.
>>
>> N.B. I emphasize sourcing a "source" script from bash and running
>> scripts/comprehensive_test.sh as opposed to piece-meal tests done by hand 
>> since
>> (a) the script result should be completely automated and reproducible if you 
>> have set
>> up the platform properly, and (b) comprehensive testing is so much more 
>> powerful
>> than piece-meal tests.
>> So I would appreciate hearing from any of you quickly if you are in a good 
>> position to
>> run that script.
>>
> I ran scripts/comprehensive_test.sh with no argument and prepending two 
> directories to the PATH environment variable (.../shared/bin and 
> .../shared/lib/plplot5.10.0/drivers) and everything ran until the 
> "traditional make" step, see the attached output. The error seems to be 
> specific to Cygwin - the names of the libraries.
>
> The other steps did not reveal any problems, as far as I can tell from an 
> examination of the output files.

Hi Arjen:

It is very encouraging from my release manager perspective that all
components of PLplot that you have enabled on Cygwin appear to be
working for the shared case so long as you exclude the traditional
build of the installed examples.  From the output that you attached
it appears a number of different things went wrong with that
traditional build and test of the installed examples.  We can address
those post-release.

For now, please continue the process before this release deadline by using the
appropriate documented arguments of scripts/comprehensive_test.sh
until you get a complete run of the script with no errors.  Then we
will know where we stand, i.e., exactly which parts of the
comprehensive test work on Cygwin and which do not, and we can post
those definitive results on our wiki and refer to them in the release
notes.

The required documentation of the script is found by using the --help
argument, and it follows from that and the number of bad results you
obtained for the make + pkg-config traditional build of the installed
examples that you should re-run the script using the arguments
"--do_test_traditional_install_tree no". Hopefully, that will be
enough to give you a clean result, but if not, please continue by
re-running the script with more removed from the tests.

Once you have a clean result please post all relevant results here
(i.e., attach a compressed version of the output from the script, and
also attach a compressed tarball of _just_ the directories
comprehensive_test_disposeable/shared/output_tree
comprehensive_test_disposeable/nondynamic/output_tree
comprehensive_test_disposeable/static/output_tree) so I can use those
data to summarize the good and dropped part of your comprehensive test
on the wiki.

@Greg

This (mostly) good result from Arjen on Cygwin obviously is sharply in
contrast with your own results where not even ctest worked on that
platform.  Therefore, I suggest you get in touch with Arjen to figure
out exactly what he did.  Then following that procedure rigourously
should give you similar good results, and probably even more
importantly we should be able to document exactly what you did that
should be avoided by others on Cygwin when they are running
scripts/comprehensive_test.sh.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
__

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Arjen Markus]

Hi Alan,



>  -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> @Arjen, Phil, and Jim:
>
> As release manager, that latter possibility of a regression in comprehensive 
> testing
> on the Cygwin platform really concerns me, and I ask at least one of you guys 
> to
> confirm/deny that possibility by simply running scripts/comprehensive_test.sh 
> on
> Cygwin with appropriate environmental variables set (ideally with a "source"
> script that you run from using the bash "source" command to keep everything 
> easily
> and automatically reproducible) to setup the Cygwin platform for the PLplot 
> build and
> test.
>
> N.B. I emphasize sourcing a "source" script from bash and running
> scripts/comprehensive_test.sh as opposed to piece-meal tests done by hand 
> since
> (a) the script result should be completely automated and reproducible if you 
> have set
> up the platform properly, and (b) comprehensive testing is so much more 
> powerful
> than piece-meal tests.
> So I would appreciate hearing from any of you quickly if you are in a good 
> position to
> run that script.
>
I ran scripts/comprehensive_test.sh with no argument and prepending two 
directories to the PATH environment variable (.../shared/bin and 
.../shared/lib/plplot5.10.0/drivers) and everything ran until the "traditional 
make" step, see the attached output. The error seems to be specific to Cygwin - 
the names of the libraries.

The other steps did not reveal any problems, as far as I can tell from an 
examination of the output 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.


traditional_make_noninteractive.out
Description: traditional_make_noninteractive.out
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Arjen Markus]

Hi Alan, Greg,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> @Greg: You have much more experience with Cygwin than I do (since my actual
> experience is zero).  Nevertheless, historically there has been lots of 
> warnings on
> the CMake list that Cygwin users _must_ use the Cygwin version of CMake and 
> not
> the generic Windows version.  So because Arjen has had success with
> comprehensive testing on Cygwin in the past with that approach, and you are
> currently not having such success with a generic version of CMake rather than 
> the
> Cygwin version, I drew the conclusion you should try the Cygwin version of 
> CMake.
>
> @Arjen:
>
> Do you still use the Cygwin version of CMake for your Cygwin tests or is that
> historical advice no longer relevant so that the generic Windows version of 
> CMake
> that you can download for Kitware gives good results for you?
>
Under Cygwin I always use the Cygwin version of CMake. I simply do not know if 
that is still necessary and whether the generic Windows version would work as 
well. It is something that can easily be tested of course.

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.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: updated release notes

[Alan W. Irwin]

I have just (commit dadae4a) updated the 5.11.0 release notes
(contained in the README.release file) based on skimming the commit
messages for the ~500 commits we have done since the release of 5.10.0.

Could everyone who made commits in this release cycle review these
updated notes and commit additional changes to them if required?

@Phil:

That request is especially addressed to you since I had a lot of
trouble trying to write up your work on new wxwidgets. I based that
write up on what was said on the mailing list, but I very likely
missed or misstated some point concerning new wxwidgets so your
further help with that part of the writeup would be appreciated.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. Irwin]

On 2015-04-03 14:06-0700 Greg Jung wrote:

> In Cygwin, I do use the cygwin cmake; but it isn't distributed by
> cygwin, I built it from source.  At one point I tried the windows
> cmake from cygwin and it failed miserably.

@Greg:

Thanks for that clarification.  I agree that cmake built on Cygwin
should work fine to build and test PLplot on Cygwin.  Yet your results
are different from Arjen's historical good comprehensive test results
on Cygwin (where he did use the Cygwin install version of CMake).  So
either that difference is significant (which I agree is unlikely, but
you never know), there is some CMake version issue between the CMake
version you are using and the CMake version that Arjen historically
used (much more likely), something is wrong with your additional setup
on Cygwin (e.g., environment variables that you set that might
interfere with our testing framework, also fairly likely), or else
there is some comprehensive testing regression for PLplot for the
Cygwin platform.

@Arjen, Phil, and Jim:

As release manager, that latter possibility of a regression in
comprehensive testing on the Cygwin platform really concerns me, and I
ask at least one of you guys to confirm/deny that possibility by
simply running scripts/comprehensive_test.sh on Cygwin with
appropriate environmental variables set (ideally with a "source"
script that you run from using the bash "source" command to keep
everything easily and automatically reproducible) to setup the Cygwin
platform for the PLplot build and test.

N.B. I emphasize sourcing a "source" script from bash and running
scripts/comprehensive_test.sh as opposed to piece-meal tests done by
hand since (a) the script result should be completely automated and
reproducible if you have set up the platform properly, and (b)
comprehensive testing is so much more powerful than piece-meal tests.
So I would appreciate hearing from any of you quickly if you are in a
good position to run that script.

Meanwhile, I am going to continue with the release process culminating
(I hope this weekend) with starting scripts/comprehensive_test.sh for
the MinGW/MSYS/Wine case.  That result will take roughly 3 days to
complete (since Wine startup of each command is so much slower than
what happens for Microsoft Windows).  Once I have a good comprehensive
test result on MinGW/MSYS/Wine (likely Tuesday at the earliest) I plan
to go ahead with the release unless one of you confirms Greg's result
that running scripts/comprehensive_test.sh no longer works on Cygwin.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing: MinGW-w64/MSYS2

[Greg Jung]

The cmake I specify for MSYS is a vanilla cmake downloaded from
cmake.org; I use this because all of my other CMakes use scripts I
modified.

Cmake for Msys needs to use msys make, not mingw32-make; otherwise you
want to do a mingw build which involves hiding "sh" from the PATH,
using CMD.exe,  etc. etc. I tried it once it fell pretty quickly.

I really couldn't quote an example where msys(1) is so different from msys2
that msys2 is more unix-like.   Both use the same name-conversion
rules and both use an interface layer to look like linux.  When I
installed msys2
it succeeded in a build that mingw(org)/msys was failing.  Then I
discovered that most of the libraries I was building were already
pre-built and distributed, via the MSYS2/pacman distribution program.

I'm on Linux today, will send interim results under a different subject.

On Fri, Apr 3, 2015 at 12:26 PM, Alan W. Irwin
 wrote:
> On 2015-04-02 22:57-0700 Greg Jung wrote:
>
>>
>> In each setup there are naturally missing pieces.
>>>
>>> From my perspective,I need only libplplot.dll, libplplotcxx.dll,
>>
>> wingcc, svg, ps, null, Z, X, and maybe cairo devices, and wxwidget. If
>> a failure occurs because it isn't within this narrow requirement, that
>> is irrelevant.
>
>
> Hi Greg:
>
> But if the failure causes premature stopping of the test, then you
> don't have a complete test coverage for the components that are
> relevant to your needs.  So by all means for now explicitly drop all
> components that you don't want to comprehensively test (e.g., by using
> appropriate -DENABLE_???=OFF and -DPLD_???=OFF options via the
> --cmake_added_options option of scripts/comprehensive_test.sh) to
> allow you to complete the tests for a narrow set of components. Once
> such a limited test completes without failures, then we can note that
> success on our wiki and use it (if you are willing to make that exact
> same test again) as a benchmark for tests near the end of future
> release cycles to insure there are no regressions in the part of
> PLplot that interests you.
>
>> I should note that, in running the raw cmake without mod and without
>> setting variables,
>> I am wholly reliant on the pkgconfig system to find libraries and
>> sniff dependencies, which directs
>> cmake to look in the tree beneath the compiler distribution.
>
>
> Actually, CMake finds software using so-called find modules.  A few
> of those use pkg-config, but many do not.
>
>> in that respect the plplot build is a raging success.
>
>
> I agree that CMake is very good about finding software using whatever
> methods are used in the appropriate find module.  However, when you
> have multiple versions of the same software installed or if some of
> your installed software is installed in a non-standard location, you
> do have to direct CMake to find the correct software version that is
> appropriate for a particular platform by (typically) setting the
> environment variables PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH,
> and PKG_CONFIG_PATH.
>
>> If CMAKE were to find a library in /usr/lib this would be an error,
>> because that, analogous to the CYGWIN /usr/lib, is for programs to be
>> run under the msys- dll.
>
>
> Well, the user must set environment variables appropriate to each
> tested platform to give hints to CMake about finding software, and if
> they fail to set up a platform properly that way, it is a user error.
>
>> Compiling for Mingw using "MSYS Makefiles"
>> is really, from CMAKE point of view, a happy accident.  In that first
>> run the generator string turned out to be "Unix Makefiles" which
>> seemed to work nevertheless, in the make phase.  I re-ran mingw64 and
>> specified "MSYS Makefiles" for the same result.
>
>
> Not quite sure what you mean here because first you refer to Mingw,
> then to mingw64.  I suspect in both cases you meant MinGW-w64/MSYS2
> rather than MinGW/MSYS, but I am not completely sure.  Neverthess, I
> strongly agree with the principle that the generator you should use is
> dependent on platform.  For classical MinGW with no MSYS it is "MinGW
> Makefiles" (and you must also specify --build_command mingw32-make).
> For classicial MinGW/MSYS it is "MSYS Makefiles".  For Cygwin it is
> "Unix Makefiles".  My _guess_ for MinGW-w64/MSYS2 is that it should be
> "Unix Makefiles", (since that platform is a light-weight variant of
> modern Cygwin), but the exact generator to use is something you will
> have to discover for yourself since you are the first (that I am aware
> of) that has tried comprehensive testing on that particular platform.
>
>> My mingw tests didn't result in an install_tree/ so I suspect "make
>> install" is not an included step
>> in the script.  This is consistent with the ctest failure not picking
>> up ps driver etc.  I keep my usual
>> plplot drivers in a directory not on the MSYS path.
>>  All of the .dll files are there in the build directory but there is
>> no install directory.
>> ctest -j4 fails - if I manually go (cwd) to th

[Plplot-devel] Release status: call for comprehensive testing: wxwidgets

[Alan W. Irwin]

I have just finished (once again) a complete test of wxwidgets for all
our standard examples.  I have reported the results (which are quite
encouraging) at the (re-edited)
https://sourceforge.net/p/plplot/bugs/151/.  It's this bug
report I will refer to in the release notes.

Freeze and release process continues

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Greg Jung]

In Cygwin, I do use the cygwin cmake; but it isn't distributed by
cygwin, I built it from source.  At one point I tried the windows
cmake from cygwin and it failed miserably.

On Fri, Apr 3, 2015 at 12:20 PM, Alan W. Irwin
 wrote:
> On 2015-04-02 22:57-0700 Greg Jung wrote:
>
>> This is a long-standing cygwin warning, "CMake no longer defines WIN32
>> on Cygwin!"
>> for those rip-van-winkles coming back to cygwin and somehow wanting
>> WIN32 to be defined.
>> I am very familar with the possible quirks that can arise with Cmake;
>> if there is a systemic failure
>> it generally blows up in your face.  For the test I ran cmake without
>> modification - to do that I had to re-direct the cmake command to a
>> pristine installation.  Although you may not feel comfortable doing
>> so,
>> "trust me" its not cmake.
>
>
> @Greg: You have much more experience with Cygwin than I do (since my
> actual experience is zero).  Nevertheless, historically there has been
> lots of warnings on the CMake list that Cygwin users _must_ use the
> Cygwin version of CMake and not the generic Windows version.  So
> because Arjen has had success with comprehensive testing on Cygwin in
> the past with that approach, and you are currently not having such
> success with a generic version of CMake rather than the Cygwin
> version, I drew the conclusion you should try the Cygwin version of
> CMake.
>
> @Arjen:
>
> Do you still use the Cygwin version of CMake for your Cygwin
> tests or is that historical advice no longer relevant so that the
> generic Windows version of CMake that you can download for Kitware
> gives good results for you?
>
> 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
> __

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: call for comprehensive testing: MinGW-w64/MSYS2

[Alan W. Irwin]

On 2015-04-02 22:57-0700 Greg Jung wrote:

>
> In each setup there are naturally missing pieces.
>> From my perspective,I need only libplplot.dll, libplplotcxx.dll,
> wingcc, svg, ps, null, Z, X, and maybe cairo devices, and wxwidget. If
> a failure occurs because it isn't within this narrow requirement, that
> is irrelevant.

Hi Greg:

But if the failure causes premature stopping of the test, then you
don't have a complete test coverage for the components that are
relevant to your needs.  So by all means for now explicitly drop all
components that you don't want to comprehensively test (e.g., by using
appropriate -DENABLE_???=OFF and -DPLD_???=OFF options via the
--cmake_added_options option of scripts/comprehensive_test.sh) to
allow you to complete the tests for a narrow set of components. Once
such a limited test completes without failures, then we can note that
success on our wiki and use it (if you are willing to make that exact
same test again) as a benchmark for tests near the end of future
release cycles to insure there are no regressions in the part of
PLplot that interests you.

> I should note that, in running the raw cmake without mod and without
> setting variables,
> I am wholly reliant on the pkgconfig system to find libraries and
> sniff dependencies, which directs
> cmake to look in the tree beneath the compiler distribution.

Actually, CMake finds software using so-called find modules.  A few
of those use pkg-config, but many do not.

> in that respect the plplot build is a raging success.

I agree that CMake is very good about finding software using whatever
methods are used in the appropriate find module.  However, when you
have multiple versions of the same software installed or if some of
your installed software is installed in a non-standard location, you
do have to direct CMake to find the correct software version that is
appropriate for a particular platform by (typically) setting the
environment variables PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH,
and PKG_CONFIG_PATH.

> If CMAKE were to find a library in /usr/lib this would be an error,
> because that, analogous to the CYGWIN /usr/lib, is for programs to be
> run under the msys- dll.

Well, the user must set environment variables appropriate to each
tested platform to give hints to CMake about finding software, and if
they fail to set up a platform properly that way, it is a user error.

> Compiling for Mingw using "MSYS Makefiles"
> is really, from CMAKE point of view, a happy accident.  In that first
> run the generator string turned out to be "Unix Makefiles" which
> seemed to work nevertheless, in the make phase.  I re-ran mingw64 and
> specified "MSYS Makefiles" for the same result.

Not quite sure what you mean here because first you refer to Mingw,
then to mingw64.  I suspect in both cases you meant MinGW-w64/MSYS2
rather than MinGW/MSYS, but I am not completely sure.  Neverthess, I
strongly agree with the principle that the generator you should use is
dependent on platform.  For classical MinGW with no MSYS it is "MinGW
Makefiles" (and you must also specify --build_command mingw32-make).
For classicial MinGW/MSYS it is "MSYS Makefiles".  For Cygwin it is
"Unix Makefiles".  My _guess_ for MinGW-w64/MSYS2 is that it should be
"Unix Makefiles", (since that platform is a light-weight variant of
modern Cygwin), but the exact generator to use is something you will
have to discover for yourself since you are the first (that I am aware
of) that has tried comprehensive testing on that particular platform.

> My mingw tests didn't result in an install_tree/ so I suspect "make
> install" is not an included step
> in the script.  This is consistent with the ctest failure not picking
> up ps driver etc.  I keep my usual
> plplot drivers in a directory not on the MSYS path.
>  All of the .dll files are there in the build directory but there is
> no install directory.
> ctest -j4 fails - if I manually go (cwd) to the build directory and "ctest >& 
> "
> and get a series of the following messages:
> 1: Testing front-end c
> 1: x00c
> 1: Unable to load driver: ps.
> 1:
> 1: *** PLPLOT ERROR, IMMEDIATE EXIT ***
> 1: Unable to load driver
> so either ps.info isn't being found, or ps.dll, or both.  If it is
> working for you, perhaps you are finding these in the old
> installation.

> greg@Homerw7 MINGW64 /d/bld/plplot-mingw32/output_tree
> $ ls -la
> total 420
> drwxr-xr-x 1 greg None  0 Apr  2 21:21 .
> drwxr-xr-x 1 greg None  0 Mar 28 16:15 ..
> -rw-r--r-- 1 greg None  19804 Mar 28 16:15 cmake.out
> -rw-r--r-- 1 greg None   5568 Mar 28 17:06 ctest.out
> -rw-r--r-- 1 greg None 397277 Mar 28 16:16 make.out
> $ ls -la ../build_tree/dll
> total 2744
> drwxr-xr-x 1 greg None  0 Mar 28 16:16 .
> drwxr-xr-x 1 greg None  0 Mar 30 08:31 ..
> -rwxr-xr-x 1 greg None 143271 Mar 28 16:16 cairo.dll
> -rwxr-xr-x 1 greg None 118558 Mar 28 16:15 libcsirocsa.dll
> -rw-r--r-- 1 greg None   6542 Mar 28 16:15 libcsirocsa.dll.a
> -rwxr-xr-x 

[Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. Irwin]

On 2015-04-02 22:57-0700 Greg Jung wrote:

> This is a long-standing cygwin warning, "CMake no longer defines WIN32
> on Cygwin!"
> for those rip-van-winkles coming back to cygwin and somehow wanting
> WIN32 to be defined.
> I am very familar with the possible quirks that can arise with Cmake;
> if there is a systemic failure
> it generally blows up in your face.  For the test I ran cmake without
> modification - to do that I had to re-direct the cmake command to a
> pristine installation.  Although you may not feel comfortable doing
> so,
> "trust me" its not cmake.

@Greg: You have much more experience with Cygwin than I do (since my
actual experience is zero).  Nevertheless, historically there has been
lots of warnings on the CMake list that Cygwin users _must_ use the
Cygwin version of CMake and not the generic Windows version.  So
because Arjen has had success with comprehensive testing on Cygwin in
the past with that approach, and you are currently not having such
success with a generic version of CMake rather than the Cygwin
version, I drew the conclusion you should try the Cygwin version of
CMake.

@Arjen:

Do you still use the Cygwin version of CMake for your Cygwin
tests or is that historical advice no longer relevant so that the
generic Windows version of CMake that you can download for Kitware
gives good results for you?

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Arjen Markus]

Hi Greg,



It may or may not be related to your MSYS/MinGW issues, but I have to set some 
environment variables to get the examples under MSYS/MinGW to run (lack of 
drivers, font files). Plus I have some icky problems with make - it seems to 
become MicroSoft's nmake sometimes, at least I get nmake's start-up messages.



I have been unable so far to find the reason for these two issues. When things 
become a bit more relaxed, I intend to dig deeper. It is annoying enough.



Regards,



Arjen



> -Original Message-
> From: Greg Jung [mailto:gvj...@gmail.com]
> Sent: Friday, April 03, 2015 7:57 AM
> To: Alan W. Irwin
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Release status: call for comprehensive testing
>
> This is a long-standing cygwin warning, "CMake no longer defines WIN32 on
> Cygwin!"
> for those rip-van-winkles coming back to cygwin and somehow wanting
> WIN32 to be defined.
> I am very familar with the possible quirks that can arise with Cmake; if 
> there is a
> systemic failure it generally blows up in your face.  For the test I ran 
> cmake without
> modification - to do that I had to re-direct the cmake command to a pristine
> installation.  Although you may not feel comfortable doing so, "trust me" its 
> not
> cmake.
>
> In each setup there are naturally missing pieces.
> >From my perspective,I need only libplplot.dll, libplplotcxx.dll,
> wingcc, svg, ps, null, Z, X, and maybe cairo devices, and wxwidget. If a 
> failure
> occurs because it isn't within this narrow requirement, that is irrelevant.
>
> I should note that, in running the raw cmake without mod and without setting
> variables, I am wholly reliant on the pkgconfig system to find libraries and 
> sniff
> dependencies, which directs cmake to look in the tree beneath the compiler
> distribution. So in that respect the plplot build is a raging success.
> If CMAKE were to find a library in /usr/lib this would be an error, because 
> that,
> analogous to the CYGWIN /usr/lib, is for programs to be run under the msys- 
> dll.
> Compiling for Mingw using "MSYS Makefiles"
> is really, from CMAKE point of view, a happy accident.  In that first run the 
> generator
> string turned out to be "Unix Makefiles" which seemed to work nevertheless, 
> in the
> make phase.  I re-ran mingw64 and specified "MSYS Makefiles" for the same 
> result.
>
> My mingw tests didn't result in an install_tree/ so I suspect "make install" 
> is not an
> included step in the script.  This is consistent with the ctest failure not 
> picking up ps
> driver etc.  I keep my usual plplot drivers in a directory not on the MSYS 
> path.
>   All of the .dll files are there in the build directory but there is no 
> install directory.
> ctest -j4 fails - if I manually go (cwd) to the build directory and "ctest >& 
> "
> and get a series of the following messages:
> 1: Testing front-end c
> 1: x00c
> 1: Unable to load driver: ps.
> 1:
> 1: *** PLPLOT ERROR, IMMEDIATE EXIT ***
> 1: Unable to load driver
>  so either ps.info isn't being found, or ps.dll, or both.  If it is working 
> for you, perhaps
> you are finding these in the old installation.
>
> greg@Homerw7 MINGW64 /d/bld/plplot-mingw32/output_tree $ ls -la total 420
> drwxr-xr-x 1 greg None  0 Apr  2 21:21 .
> drwxr-xr-x 1 greg None  0 Mar 28 16:15 ..
> -rw-r--r-- 1 greg None  19804 Mar 28 16:15 cmake.out
> -rw-r--r-- 1 greg None   5568 Mar 28 17:06 ctest.out
> -rw-r--r-- 1 greg None 397277 Mar 28 16:16 make.out $ ls -la 
> ../build_tree/dll total
> 2744
> drwxr-xr-x 1 greg None  0 Mar 28 16:16 .
> drwxr-xr-x 1 greg None  0 Mar 30 08:31 ..
> -rwxr-xr-x 1 greg None 143271 Mar 28 16:16 cairo.dll -rwxr-xr-x 1 greg None 
> 118558
> Mar 28 16:15 libcsirocsa.dll
> -rw-r--r-- 1 greg None   6542 Mar 28 16:15 libcsirocsa.dll.a
> -rwxr-xr-x 1 greg None 509403 Mar 28 16:16 libplplot.dll
> -rw-r--r-- 1 greg None 194548 Mar 28 16:16 libplplot.dll.a -rwxr-xr-x 1 greg 
> None
> 190112 Mar 28 16:16 libplplotcxx.dll
> -rw-r--r-- 1 greg None 171696 Mar 28 16:16 libplplotcxx.dll.a -rwxr-xr-x 1 
> greg None
> 278549 Mar 28 16:16 libplplottcltk.dll
> -rw-r--r-- 1 greg None   3950 Mar 28 16:16 libplplottcltk.dll.a
> -rwxr-xr-x 1 greg None  92430 Mar 28 16:16 libplplottcltk_Main.dll
> -rw-r--r-- 1 greg None   1502 Mar 28 16:16 libplplottcltk_Main.dll.a
> -rwxr-xr-x 1 greg None 120392 Mar 28 16:15 libqsastime.dll
> -rw-r--r-- 1 greg None   3874 Mar 28 16:15 libqsastime.dll.a
> -rwxr-xr-x 1 greg None  96826 Mar 28 16:15 libtclmatrix.dll
> -rw-r--r-- 1 greg None   2782 Mar 28 16:15 libtclmatrix.dll.a
> -rwxr-xr-x 1 greg 

Re: [Plplot-devel] Release status: call for comprehensive testing

[Greg Jung]

This is a long-standing cygwin warning, "CMake no longer defines WIN32
on Cygwin!"
for those rip-van-winkles coming back to cygwin and somehow wanting
WIN32 to be defined.
I am very familar with the possible quirks that can arise with Cmake;
if there is a systemic failure
it generally blows up in your face.  For the test I ran cmake without
modification - to do that I had to re-direct the cmake command to a
pristine installation.  Although you may not feel comfortable doing
so,
"trust me" its not cmake.

In each setup there are naturally missing pieces.
>From my perspective,I need only libplplot.dll, libplplotcxx.dll,
wingcc, svg, ps, null, Z, X, and maybe cairo devices, and wxwidget. If
a failure occurs because it isn't within this narrow requirement, that
is irrelevant.

I should note that, in running the raw cmake without mod and without
setting variables,
I am wholly reliant on the pkgconfig system to find libraries and
sniff dependencies, which directs
cmake to look in the tree beneath the compiler distribution. So in
that respect the plplot build is a raging success.
If CMAKE were to find a library in /usr/lib this would be an error,
because that, analogous to the CYGWIN /usr/lib, is for programs to be
run under the msys- dll.  Compiling for Mingw using "MSYS Makefiles"
is really, from CMAKE point of view, a happy accident.  In that first
run the generator string turned out to be "Unix Makefiles" which
seemed to work nevertheless, in the make phase.  I re-ran mingw64 and
specified "MSYS Makefiles" for the same result.

My mingw tests didn't result in an install_tree/ so I suspect "make
install" is not an included step
in the script.  This is consistent with the ctest failure not picking
up ps driver etc.  I keep my usual
plplot drivers in a directory not on the MSYS path.
  All of the .dll files are there in the build directory but there is
no install directory.
ctest -j4 fails - if I manually go (cwd) to the build directory and "ctest >& "
and get a series of the following messages:
1: Testing front-end c
1: x00c
1: Unable to load driver: ps.
1:
1: *** PLPLOT ERROR, IMMEDIATE EXIT ***
1: Unable to load driver
 so either ps.info isn't being found, or ps.dll, or both.  If it is
working for you, perhaps you are finding these in the old
installation.

greg@Homerw7 MINGW64 /d/bld/plplot-mingw32/output_tree
$ ls -la
total 420
drwxr-xr-x 1 greg None  0 Apr  2 21:21 .
drwxr-xr-x 1 greg None  0 Mar 28 16:15 ..
-rw-r--r-- 1 greg None  19804 Mar 28 16:15 cmake.out
-rw-r--r-- 1 greg None   5568 Mar 28 17:06 ctest.out
-rw-r--r-- 1 greg None 397277 Mar 28 16:16 make.out
$ ls -la ../build_tree/dll
total 2744
drwxr-xr-x 1 greg None  0 Mar 28 16:16 .
drwxr-xr-x 1 greg None  0 Mar 30 08:31 ..
-rwxr-xr-x 1 greg None 143271 Mar 28 16:16 cairo.dll
-rwxr-xr-x 1 greg None 118558 Mar 28 16:15 libcsirocsa.dll
-rw-r--r-- 1 greg None   6542 Mar 28 16:15 libcsirocsa.dll.a
-rwxr-xr-x 1 greg None 509403 Mar 28 16:16 libplplot.dll
-rw-r--r-- 1 greg None 194548 Mar 28 16:16 libplplot.dll.a
-rwxr-xr-x 1 greg None 190112 Mar 28 16:16 libplplotcxx.dll
-rw-r--r-- 1 greg None 171696 Mar 28 16:16 libplplotcxx.dll.a
-rwxr-xr-x 1 greg None 278549 Mar 28 16:16 libplplottcltk.dll
-rw-r--r-- 1 greg None   3950 Mar 28 16:16 libplplottcltk.dll.a
-rwxr-xr-x 1 greg None  92430 Mar 28 16:16 libplplottcltk_Main.dll
-rw-r--r-- 1 greg None   1502 Mar 28 16:16 libplplottcltk_Main.dll.a
-rwxr-xr-x 1 greg None 120392 Mar 28 16:15 libqsastime.dll
-rw-r--r-- 1 greg None   3874 Mar 28 16:15 libqsastime.dll.a
-rwxr-xr-x 1 greg None  96826 Mar 28 16:15 libtclmatrix.dll
-rw-r--r-- 1 greg None   2782 Mar 28 16:15 libtclmatrix.dll.a
-rwxr-xr-x 1 greg None  90308 Mar 28 16:16 mem.dll
-rwxr-xr-x 1 greg None  95259 Mar 28 16:16 ntk.dll
-rwxr-xr-x 1 greg None  82507 Mar 28 16:16 null.dll
-rwxr-xr-x 1 greg None 120304 Mar 28 16:16 ps.dll
-rwxr-xr-x 1 greg None 108182 Mar 28 16:16 svg.dll
-rwxr-xr-x 1 greg None 106513 Mar 28 16:16 test-drv-info.exe
-rwxr-xr-x 1 greg None 107419 Mar 28 16:16 wingcc.dll
-rwxr-xr-x 1 greg None 100481 Mar 28 16:16 xfig.dll


Here now is a re-run of the mingw64 test, under msys2 using "MSYS Makefiles"
$ ./comprehensive_test.sh --prefix /d/bld/plplot-mingw64-2
--generator_string 'MSYS Makefiles' --build_command 'make -j6'
--cmake_command '/d/programs/CMake-3.1.1-win32-x86/bin/CMake'
Summary of options used for these tests

prefix=/d/bld/plplot-mingw64-2

do_clean_as_you_go=yes

generator_string=MSYS Makefiles

ctest_command=ctest -j4
build_command=make -j6
cmake_command=/d/programs/CMake-3.1.1-win32-x86/bin/CMake

Each of the steps in this comprehensive test may take a while
Prepend /d/bld/plplot-mingw64-2/shared/build_tree/dll to the original PATH
/d/programs/CMake-3.1.1-win32-x86/bin/CMake in the build tree
make -j6 VERBOSE=1 in the build tree
ctest -j4 in the build tree

$ ps
  PIDPPIDPGID WINPID   TTY UIDSTIME COMMAND
 532853205008   3520  pty0197609 21:49:04 /usr/bin

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-03-30 12:42-0700 Alan W. Irwin wrote:

> There is a big warning in plplot-cygwin/output_tree/cmake.out (for
> version 3.0.1) about "CMake no longer defines WIN32 on Cygwin!"

Hi Greg:

I believe I have now found the source of that warning message which is
(according to cmake mailing list messages I have read) that you were
using some non-Cygwin version of the cmake command, and Cygwin
requires you to use an officially packaged cmake command instead
in order for CMake-based builds to work properly on that platform.

For example, from
 it appears this
particular offical Cygwin cmake binary is installed at
/usr/bin/cmake.exe, and the corresponding cmake modules are located at
/usr/share/cmake-3.1.2/Modules while from your cmake.out output you
were instead using a cmake version whose modules were installed in
/opt/local/!

So the next time you run a Cygwin test you should be sure to (a) have
a version of CMake installed from a Cygwin package, and (b) manipulate
your PATH before running scripts/comprehensive_test.sh so that is the
cmake version that is used.

Since MinGW-w64/MSYS2 is very similar to Cygwin, I assume that
platform has a similar requirement, i.e., in that case you must
install and use the MinGW-w64/MSYS2 version of cmake which probably
explains (at least in part) the bad results you were getting
for your tests on your various MSYS2 platforms.

Note also, that Cygwin and (likely) MSYS2 are unique in this regard
and for Unix platforms a generic Unix version of cmake can be used and
for Windows platforms like MSVC and MinGW/MSYS, a generic Windows
version of cmake can be used.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-03-31 11:05-0700 Greg Jung wrote:

> Here is tarball og the output directory from recent fully-completed
> Suse-13.2 test.
> I did terminate interactive testing at the end, by killing windows,
> the strip chart was going very slow.  But the wx Viewers looked great.
>

Hi Greg:

Thanks very much for these test results.  I don't think it matters
much in this particular case, but please get into the habit of
attaching the script output for this and your other platform tests.

>From the WARNING messages in
opensuse-13.2/shared/output_tree/cmake.out your test has been
artificially limited by not installing the appropriate system
software.  Just taking those WARNING messages in order,
that missing system software includes swig (which means the
java, python, octave, and lua bindings must be dropped), development
libraries for Tcl/Tk/Itcl/Itk (which means all Tcl-related bindings
must be dropped), an Ada compiler (which means the Ada binding must be
dropped), a D compiler (which means the D binding must be dropped),
shapelib (which means interesting parts of the API and also parts of
example 19 must be dropped), qhull (which means interesting parts of
the API and also parts of example 21 must be dropped), libLASi (which
means the psttf device driver must be dropped), the development
version of Qt4 (which means the qt device driver must be dropped),
libharu (or libhpdf) (which means the pdf device driver must be
dropped), and the OCaml development libraries (which means our ocaml
binding must be dropped).  At least swig and development versions of
Tcl/Tk/Itcl/Itk and Qt4 should be readily available on OpenSuSe so I
suggest you install at least those (assuming you have control of that
machine) to increase the power of your test.

Because you terminated the test prematurely, you only got through
roughly one third of it (i.e., you didn't get to the nodynamic and
static parts of this comprehensive test).  The slowness of the
wxPLViewer application for example 17 is a well-known bug for new
wxwidgets, and the proper way to get out of it without terminating the
test is to to hit the "file" menu button on the wxPLViewer which
provides an exit option which you should take.  Also, the -np option
(the "No pause" option which is used for this test to try and reduce
how much the user has to interact with the test) is not honored (yet)
by new wxwidgets which means you have to either use the exit option to
immediately exit each of the wxwidgets examples (as for example 17) or
else hit enter to get through all the pages and eventually exit.
Similarly, if/when you install the development versions of Tcl etc.,
you will find a few of the Tcl examples do not honor the -np option so
you will have to get through them by hand, e.g., by hitting the enter
key to move through some of the pages.

So although we have reduced the tedium of running the interactive part
of the comprehensive tests an enormous amount by using the -np option,
honoring that option is not yet perfect so there still is a certain
amount of patience and interaction required to get through the
interactive part of the comprehensive test.

N.B. You can use the "--do_test_interactive no" option for
scripts/comprehensive_tests.sh if you want to completely drop the
interactive part of the tests. Such noninteractive comprehensive test
are well defined, and it certainly would still be worthwhile for me to
report such incomplete results on our wiki if you ran out of patience
with dealing with the interactive part of the test.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Greg Jung]

Here is tarball og the output directory from recent fully-completed
Suse-13.2 test.
 I did terminate interactive testing at the end, by killing windows,
 the strip chart was going very slow.  But the wx Viewers looked great.




On Tue, Mar 31, 2015 at 9:31 AM, Alan W. Irwin
 wrote:
> On 2015-03-31 09:33- Arjen Markus wrote:
>
>> Hi Alan,
>>
>>>
>>> @Arjen and Phil, will both of you please look at the cygwin.tgz
>>> attachment?
>>>
>>> There is a big warning in plplot-cygwin/output_tree/cmake.out (for
>>> version 3.0.1)
>>> about "CMake no longer defines WIN32 on Cygwin!" Have either of you run
>>> into this
>>> issue for CMake on Cygwin?  There is advice in that warning about what
>>> Greg
>>> should do to overcome this issue but with several options.  Could you
>>> advise him
>>> which option to take (and also update the Cywin part of our wiki
>>> accordingly)?
>>>
>> I have tried building Plplot using static libraries
>> (-DBUILD_SHARED_LIBS=OFF -DENABLE_DYNDRIVERS=ON), but this fails on
>> something in the Qt device:
>>
>> cd /cygdrive/d/plplot-svn/build-cygwin-static/bindings/qt_gui &&
>> /usr/bin/c++.exe   -DPLPLOT_HAVE_CONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB
>> -DQT_NO_DEBUG -DQT_SVG_LIB -I/cygdrive/d/plplot-svn/plplot-git/include
>> -I/cygdrive/d/plplot-svn/plplot-git/lib/qsastime
>> -I/cygdrive/d/plplot-svn/plplot-git/lib/nistcd
>> -I/cygdrive/d/plplot-svn/plplot-git/drivers
>> -I/cygdrive/d/plplot-svn/build-cygwin-static
>> -I/cygdrive/d/plplot-svn/build-cygwin-static/include -I/usr/include/qt4
>> -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore
>> -DUSINGDLL -o CMakeFiles/plplotqt.dir/plqt.cpp.o -c
>> /cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp
>>
>> /cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp:28:28: error:
>> definition of 'int vectorize' is marked 'dllimport'
>>
>> PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;
>>
>>^
>>
>> /cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp:28:28: warning:
>> 'vectorize' redeclared without dllimport attribute: previous dllimport
>> ignored [-Wattributes]
>>
>> /cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp:29:28: error:
>> definition of 'int lines_aa' is marked 'dllimport'
>>
>> PLDLLIMPEXP_QT_DATA( int ) lines_aa  = 1;
>>
>> I will retry it turning the Qt devices off. But this is clearly an issue
>> connected to the WIN32 macro.
>
>
> Hi Arjen:
>
> Gack.  I am really glad you found this bug in setting the -DUSINGDLL
> compile flag for libplplotqt source files (and also for smoke
> bindings) for the static library case.  This bug was caused by a commit made
> by me back in 2013.  One of our users has just run into this as well
> (see recent traffic on plplot-general).
>
> The funny thing is, this bug (which only affects Windows systems where
> plplotqt is being built) has been around so long without detection.  I
> am pretty sure that running scripts/comprehensive_testing.sh anytime
> since 2013 on a Windows system with access to Qt would have found this
> bug so this example emphasizes once again how important such
> comprehensive testing (on fully loaded systems) is.
>
> I have fixed this bug on my local system but cannot (yet) push it
> to SF because there is a complete SF outage at this time!
>
> So stay tuned to the git feed, and once this fix has been pushed, please
> follow up with the above test again (as well as comprehensive testing
> please).
>
>
> 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-opensuse13.2.tgz
Description: GNU Zip compressed data
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-03-31 09:31-0700 Alan W. Irwin wrote:

> Hi Arjen:
>
> Gack.  I am really glad you found this bug in setting the -DUSINGDLL
> compile flag for libplplotqt source files (and also for smoke
> bindings) for the static library case.  This bug was caused by a commit made
> by me back in 2013.  One of our users has just run into this as well
> (see recent traffic on plplot-general).
>
> The funny thing is, this bug (which only affects Windows systems where
> plplotqt is being built) has been around so long without detection.  I
> am pretty sure that running scripts/comprehensive_testing.sh anytime
> since 2013 on a Windows system with access to Qt would have found this
> bug so this example emphasizes once again how important such
> comprehensive testing (on fully loaded systems) is.
>
> I have fixed this bug on my local system but cannot (yet) push it
> to SF because there is a complete SF outage at this time!
>
> So stay tuned to the git feed, and once this fix has been pushed, please
> follow up with the above test again (as well as comprehensive testing
> please).

SF now working again, and I have pushed this bug fix (commit id
b6b60d1).  Please test that this solves the 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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-03-31 09:33- Arjen Markus wrote:

> Hi Alan,
>
>>
>> @Arjen and Phil, will both of you please look at the cygwin.tgz attachment?
>>
>> There is a big warning in plplot-cygwin/output_tree/cmake.out (for version 
>> 3.0.1)
>> about "CMake no longer defines WIN32 on Cygwin!" Have either of you run into 
>> this
>> issue for CMake on Cygwin?  There is advice in that warning about what Greg
>> should do to overcome this issue but with several options.  Could you advise 
>> him
>> which option to take (and also update the Cywin part of our wiki 
>> accordingly)?
>>
> I have tried building Plplot using static libraries (-DBUILD_SHARED_LIBS=OFF 
> -DENABLE_DYNDRIVERS=ON), but this fails on something in the Qt device:
>
> cd /cygdrive/d/plplot-svn/build-cygwin-static/bindings/qt_gui && 
> /usr/bin/c++.exe   -DPLPLOT_HAVE_CONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB 
> -DQT_NO_DEBUG -DQT_SVG_LIB -I/cygdrive/d/plplot-svn/plplot-git/include 
> -I/cygdrive/d/plplot-svn/plplot-git/lib/qsastime 
> -I/cygdrive/d/plplot-svn/plplot-git/lib/nistcd 
> -I/cygdrive/d/plplot-svn/plplot-git/drivers 
> -I/cygdrive/d/plplot-svn/build-cygwin-static 
> -I/cygdrive/d/plplot-svn/build-cygwin-static/include -I/usr/include/qt4 
> -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore   
>  -DUSINGDLL -o CMakeFiles/plplotqt.dir/plqt.cpp.o -c 
> /cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp
>
> /cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp:28:28: error: 
> definition of 'int vectorize' is marked 'dllimport'
>
> PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;
>
>^
>
> /cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp:28:28: warning: 
> 'vectorize' redeclared without dllimport attribute: previous dllimport 
> ignored [-Wattributes]
>
> /cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp:29:28: error: 
> definition of 'int lines_aa' is marked 'dllimport'
>
> PLDLLIMPEXP_QT_DATA( int ) lines_aa  = 1;
>
> I will retry it turning the Qt devices off. But this is clearly an issue 
> connected to the WIN32 macro.

Hi Arjen:

Gack.  I am really glad you found this bug in setting the -DUSINGDLL
compile flag for libplplotqt source files (and also for smoke
bindings) for the static library case.  This bug was caused by a commit made
by me back in 2013.  One of our users has just run into this as well
(see recent traffic on plplot-general).

The funny thing is, this bug (which only affects Windows systems where
plplotqt is being built) has been around so long without detection.  I
am pretty sure that running scripts/comprehensive_testing.sh anytime
since 2013 on a Windows system with access to Qt would have found this
bug so this example emphasizes once again how important such
comprehensive testing (on fully loaded systems) is.

I have fixed this bug on my local system but cannot (yet) push it
to SF because there is a complete SF outage at this time!

So stay tuned to the git feed, and once this fix has been pushed, please
follow up with the above test again (as well as comprehensive testing
please).

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Arjen Markus]

Hi Alan,

>
> @Arjen and Phil, will both of you please look at the cygwin.tgz attachment?
>
> There is a big warning in plplot-cygwin/output_tree/cmake.out (for version 
> 3.0.1)
> about "CMake no longer defines WIN32 on Cygwin!" Have either of you run into 
> this
> issue for CMake on Cygwin?  There is advice in that warning about what Greg
> should do to overcome this issue but with several options.  Could you advise 
> him
> which option to take (and also update the Cywin part of our wiki accordingly)?
>
I have tried building Plplot using static libraries (-DBUILD_SHARED_LIBS=OFF 
-DENABLE_DYNDRIVERS=ON), but this fails on something in the Qt device:

cd /cygdrive/d/plplot-svn/build-cygwin-static/bindings/qt_gui && 
/usr/bin/c++.exe   -DPLPLOT_HAVE_CONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB 
-DQT_NO_DEBUG -DQT_SVG_LIB -I/cygdrive/d/plplot-svn/plplot-git/include 
-I/cygdrive/d/plplot-svn/plplot-git/lib/qsastime 
-I/cygdrive/d/plplot-svn/plplot-git/lib/nistcd 
-I/cygdrive/d/plplot-svn/plplot-git/drivers 
-I/cygdrive/d/plplot-svn/build-cygwin-static 
-I/cygdrive/d/plplot-svn/build-cygwin-static/include -I/usr/include/qt4 
-I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore
-DUSINGDLL -o CMakeFiles/plplotqt.dir/plqt.cpp.o -c 
/cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp

/cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp:28:28: error: 
definition of 'int vectorize' is marked 'dllimport'

PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;

^

/cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp:28:28: warning: 
'vectorize' redeclared without dllimport attribute: previous dllimport ignored 
[-Wattributes]

/cygdrive/d/plplot-svn/plplot-git/bindings/qt_gui/plqt.cpp:29:28: error: 
definition of 'int lines_aa' is marked 'dllimport'

PLDLLIMPEXP_QT_DATA( int ) lines_aa  = 1;

I will retry it turning the Qt devices off. But this is clearly an issue 
connected to the WIN32 macro.

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.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> @Arjen and Phil, will both of you please look at the cygwin.tgz attachment?
>
> There is a big warning in plplot-cygwin/output_tree/cmake.out (for version 
> 3.0.1)
> about "CMake no longer defines WIN32 on Cygwin!" Have either of you run into 
> this
> issue for CMake on Cygwin?  There is advice in that warning about what Greg
> should do to overcome this issue but with several options.  Could you advise 
> him
> which option to take (and also update the Cywin part of our wiki accordingly)?
>
That message has been around for a while - since 2.8.4 if I am not mistaken (I 
found that version number while googling for the option I use to quiet CMake 
about it). The option

-DCMAKE_LEGACY_CYGWIN_WIN32=OFF will suppress it and I have not seen any 
problems relating to WIN32. But that may come when building with the "static" 
option.

I have not received any attachment, so unfortunately I can not have a closer 
look right now.

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.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-03-30 12:14-0700 Alan W. Irwin wrote:

> On 2015-03-30 10:40-0700 Greg Jung wrote:
>
>> Here are  gzipped- tar files sent separately because the list
>> filters may kill the message altogether.
>
> Our mailing list does not kill tarballs in my experience. So to test
> that in this case, I am forwarding this to the list.  Also, I hope it
> arrives there because I need help with some of these issues from the
> others there.

@Greg: there appears to be no problem with those attachments.

@Arjen and Phil, will both of you please look at the cygwin.tgz attachment?

There is a big warning in plplot-cygwin/output_tree/cmake.out (for
version 3.0.1) about "CMake no longer defines WIN32 on Cygwin!" Have
either of you run into this issue for CMake on Cygwin?  There is
advice in that warning about what Greg should do to overcome this
issue but with several options.  Could you advise him which option to
take (and also update the Cywin part of our wiki accordingly)?

@Greg:

Thanks very much for your four preliminary platform reports, but to
make complete sense of those  I need the other
information I requested which is the complete output from
scripts/comprehensive_test.sh in each of the four cases.

On bash you can collect such information using

scripts/comprehensive_test.sh >& comprehensive_test.sh.out

(although you also have to anticipate the script will hang until you
answer the question that will be at the end of that *.out file).

That complete output gives all sorts of useful background information
such as what options you used for the script such as the cmake
generator you specified, etc.  For example, I suspect the issues you
are seeing might be due to specifying the wrong generator, but I won't
know for sure until I can see that complete results.  Also, I suggest
you compress that output for those four cases before you attach it
because sometimes mailing software messes with plain text attachments
in my experience.

And please send those 4 compressed attachments to the mailing list and
not to me privately since we often need group expertise to give you
the best advice about how to deal with the problems running
scripts/comprehensive_test.sh thta you have encountered.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Greg Jung]

  Mingw/msys:
Because I have cmake modified to look in /usr/local
and such for libraries and such (not a good idea, I know now), I added
the option --cmake_command to the script and used

--cmake_command=/d/path-to-cmake/bin/cmake.exe and the make completed
ok but the ctest
hung at example/c/x00c; I had to kill the process.
I'm sending gzipped- tar files to you separately because the list
filters may kill the message altogether.

About Msys/Msys2:
I suppose there are 4 distinct platforms I use in Windows: Msys2 with
minw32/, with mingw64/, and msys1 with mingw standard (mingw.org).
And cygwin64.  For the purposes of these tests I'll label
them mingw32, mingw64, and mingworg.  Msys or cygwin run  posix
compatibility layers and maintain their own "mounted" file systems
within windows'  file system.  They can also interpret windows-style
pathnames. Both Msys are derived from cygwin.
Cygwin tries hard to be "your unix in the dos-box" but msys is
avowedly limited in scope to the support of cross-compilations of UNIX
builds on the windows' platform.  To do this it generally snoops on
the command line and looks for likely places that filenames would
benefit
from translation from the msys-mounted to the win-style, i.e. /usr/lib
becomes D:/path-to-msys/lib.
For cygwin, everything is kept in posix-style notation.

 As far as msys goes, msys2 is built to be 64-bit, to keep up better
with the modern cygwin layer.
Msys2 uses a pacman-based packaging update system,
https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
  The default configuration is, /msys64 toplevel directory which
becomes "/". GCC toolchain,
complete with support libraries, are installed from the mingw-w64
project into /mingw64 and, for
native 32-bit builds, /mingw32.  The big convenience for me, besides
the pre-built libraries, was
that someone decided which exception and thread models to use!!  (I
suppose they could be swapped out if needed).





On Sun, Mar 29, 2015 at 10:01 AM, Alan W. Irwin
 wrote:
> On 2015-03-28 22:20-0700 Alan W. Irwin wrote:
>
>> Also, when you report back again, will you please always specify the
>> scripts/comprehensive_test.sh options you used in every different
>> platform case?  The easiest way to do that is to always include
>> everything output from the script rather than bits and pieces like
>> above.  So ideally you would capture the whole output from the script
>> in a file, compress that file, and attach it to your post here (as
>> well as tarballs of comprehensive_test_disposeable/shared/output_tree,
>> comprehensive_test_disposeable/nondynamic/output_tree, and
>> comprehensive_test_disposeable/static/output_tree) for each platform
>> you test.
>
>
> Hi Greg:
>
> One other point I should have mentioned is you should use a different
> --prefix option for each separate run of scripts/comprehensive_test.sh
> to keep your comprehensive testing results for various platforms (if
> done on the same computer) completely separate from each other.
>
>
> 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
> __

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-03-26 18:50-0700 Alan W. Irwin wrote:

> With commit id 5f6e28f I finally have been able to complete
> scripts/comprehensive_test.sh on Linux without issues which removes
> the last known regression compared to 5.10.0 for this release which is
> a much-desired result.
>
> My next steps are [1] to do some straightforward release preliminaries
> (such as setting version strings and updating the website) followed by
> [2] epa_build and comprehensive test of "plplot" on Linux (which will do a
> similar test to what I just completed but for the latest versions of
> PLplot dependencies) and [3] "plplot_lite" on MinGW/MSYS/Wine.  Note that
> Wine test will take a couple of days (since Wine is so slow).

I am happy to report that I have finished [2] above with no issues.
The entire test took 3.7 hours to complete on my computer.  For
details about this successful comprehensive test using epa_build and
the previous success at running scripts/comprehensive_tests.sh
directly, see the reports I just posted at 
.

Note, I am not interested in posting vague "it doesn't work"
reports there, but if you did get the script to complete using one of
the scripts options, say, to remove a component of PLplot that is not
working for you, then I would definitely be interested in posting that
definite result. So to take a concrete example, Greg is currently not
having much luck with comprehensive testing on some variant of MSYS2,
but that result is too vague at the present time to report in our
wiki.  But once he gets the *.out results to me that I have requested, I
might be able to advise him what components of PLplot he should avoid
(or maybe even come up with a build system fix) to allow him to finish
scripts/comprehensive_test.sh on MSYS2, and that definite report
detailing exactly which components had to be dropped would be well
worth posting at
.

>
> While I am doing those steps I strongly encourage the rest of you to
> do comprehensive testing of PLplot master tip on all platforms that
> are accessible to you following the instructions at
> 
> and
> .

I very much appreciate the effort some of you have started putting
into comprehensive testing, and now that I have shown the epa_build
method of doing this works for master tip (as it also worked for the
last release) on Linux, then some who are having trouble with system
dependencies when running scripts/comprehensive_tests.sh directly
might want to try the epa_build method instead following the
instructions in cmake/epa_build/README.

My next planned steps in the release process are to essentially
prepare a release candidate ([1] above plus all other steps mentioned
in README.Release_Manager_Cookbook that do not involve uploads to the
SourceForge file release area) plus respond to any bugs that your own
comprehensive testing might turn up. Once I am entirely satisfied with
that result, I will finally try [3] above to give me the best chance
of not having to repeat that (very long) test.  Assuming that test
finds no regressions I plan to complete the release with the actual
upload of the tarball and signature file to SourceForge.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-03-28 22:20-0700 Alan W. Irwin wrote:

> Also, when you report back again, will you please always specify the
> scripts/comprehensive_test.sh options you used in every different
> platform case?  The easiest way to do that is to always include
> everything output from the script rather than bits and pieces like
> above.  So ideally you would capture the whole output from the script
> in a file, compress that file, and attach it to your post here (as
> well as tarballs of comprehensive_test_disposeable/shared/output_tree,
> comprehensive_test_disposeable/nondynamic/output_tree, and
> comprehensive_test_disposeable/static/output_tree) for each platform
> you test.

Hi Greg:

One other point I should have mentioned is you should use a different
--prefix option for each separate run of scripts/comprehensive_test.sh
to keep your comprehensive testing results for various platforms (if
done on the same computer) completely separate from each other.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Jim Dishaw]

> On Mar 29, 2015, at 9:17 AM, Andrew Ross  
> wrote:
> 

>  Also -np to prevent pausing between
> pages doesn't work. This is not a major issue, but is a slight pain when
> running the automatic tests.
> 
> Andrew

I believe this bug might be related to the extra plP_eop() call. This results 
in the need for extra keypresses. 
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Andrew Ross]

On Sat, Mar 28, 2015 at 05:41:12PM -0700, Alan Irwin wrote:
> On 2015-03-28 21:40- Andrew Ross wrote:
> 
> I use 2.2.1 as well but with additional patches applied.
> 
> See cmake/epa_build/libharu/CMakeLists.txt for how to locate those
> patches.
> 
> Most of those are to install a CMake-based build system which you
> don't need (except for epa_build), but one of those, i.e.,
> cmake/epa_build/libharu/large_font.patch is a bug fix for large fonts
> (as occurs for example 24), see
> .  The
> Debian maintainer responded there and said he would apply the patch to
> the Debian package, but the sid, testing, and stable version of that
> package are all the same so it appears he did not do so.  If it is
> possible for him to make that change this late in the Debian release
> cycle, could you please nag him to do so?
> 
> You may also want to nag the Ubuntu developers about that patch.

Good point. I do vaguely remember this now.

> > One other thing I noticed is that itcl / itk are disabled because the
> > header files are not found. I do have them installed. Looks like the
> > headers are now in /usr/include/itcl3/ . CMake is looking in
> > ${TCL_INCLUDE_PATH}/itcl3, but TCL_INCLUDE_PATH is /usr/include/tcl8.6 in
> > my case so this doesn't work. It used to work, so I expect this is
> > something related to the way itcl / itk are packaged on Ubuntu. Alan, do
> > you run into this on Debian?
> 
> Both Debian stable and epa_build are fine in this regard, and I suspect
> Orion would have said something if this was an issue on Fedora.
> 
> The current find_path assumption in cmake/modules/tcl-related.cmake is
> the itcl and itk headers are in subdirectories of the versioned tcl
> headers which is what occurs for both Debian stable and epa_build and
> makes some sense since itcl and itk versions depend on Tcl (and Tk)
> version.  But I guess Ubuntu have decided to violate that assumption.
> 
> I don't think that if Itcl and Itk are missing it is a
> release-critical issue since they play a fairly small role for PLplot.
> Therefore, I think we should deal with this issue post-release by
> coming up with some PATHS or HINTS options for the find_path commands
> that will make Ubuntu work automatically without interfering with what
> works for Debian stable (and other distros?) and epa_build.  However,
> for now, if you want to test Itcl and Itk on Ubuntu, you could do that
> by setting ITCL_INCLUDE_PATH and ITK_INCLUDE_PATH appropriately.

I'm surprised Debian and Ubuntu have diverged here. I'll check what is in
unstable. It may be the change is in the new Debian release too. Anyway, I
agree about the fix. Just flagging it up while testing.

Two other comments for Phil on wxwidgets. Example 17 is a mess (I'm sure
this is already on the list of bugs). Also -np to prevent pausing between
pages doesn't work. This is not a major issue, but is a slight pain when
running the automatic tests.

Andrew

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

Hi Greg:

It's important our interchanges remain on list so others can
benefit from them so please don't drop the list Cc from your replies.

Thanks for all these test results.  More below in context

On 2015-03-28 16:27-0700 Greg Jung wrote:

> HI Alan,
>
>  I did use make all on that run, but probably the issue was that the
> testing instructions were
> not simple and specific enough.
>
> ok so from an empty subdirectory of the source directory I ran the script
> from MSYS2:

For my records and for others here that might be interested in MSYS2,
could you describe the origin/version of this MSYS2? Is this
MinGW-w64/MSYS2 that you can install following the procedure given in
? Even if
you confirm that, there are several possible different options you can
take so a full description of your MSYS2 install would be best.

> Each of the steps in this comprehensive test may take a while
> cmake in the build tree
> make -j4 VERBOSE=1 in the build tree
> ctest -j4 in the build tree
> ERROR: ctest -j4 failed in the build tree

On the assumption that the above results were for the very first
(shared library) part of the comprehensive test, could you pack up
everything in comprehensive_test_disposeable/shared/output_tree/ into
a compressed tarball and send it here as an attachment to help
me figure out what is going wrong with ctest?

> [...]So I try now with Mingw.org msys:
> Each of the steps in this comprehensive test may take a while
> cmake in the build tree
> make -j4 VERBOSE=1 in the build tree
>
>  This seems hung, even though the activity indicators seem to be
> going.

Parallel builds hang on MinGW/MSYS due to a very long-standing bug for
that platform. To work around that MinGW/MSYS bug you have to use the

--build_command make

option (i.e., drop the -j4 option for make) for the 
scripts/comprehensive_test.sh command.

That, of course, is going to slow the comprehensive test for
MinGW/MSYS, but your report for that platform would be most welcome,
and I hope you will achieve complete success there (like I did
much earlier in this release cycle although I hope to confirm that
again for myself for the master tip version in the next several days).

> from linux:
> I got a clean bill of health under OpenSuse13.2 wx 3.0/ gtk2u
>
> Each of the steps in this comprehensive test may take a while
> cmake in the build tree
> make -j4 VERBOSE=1 in the build tree
> ctest -j4 in the build tree
> make -j4 clean_ctest_plot_files in the build tree (since we are done with 
> ctest)
> make -j4 VERBOSE=1 test_noninteractive in the build tree
> make -j4 VERBOSE=1 install in the build tree
> make -j4 clean in the build tree (since we are done with it at least
> for the non-interactive test case)
> Prepend 
> /home/plplot-5.11/../comprehensive_test_disposeable/shared/install_tree/bin
> to the original PATH
> cmake in the installed examples build tree
> make -j4 VERBOSE=1 test_noninteractive in the installed examples build tree
> make -j4 clean in the installed examples build tree (since we are done
> with it at least for the non-interactive test case)
> Traditional make -j4 test_noninteractive in the installed examples tree
> Traditional make -j4 clean in the installed examples tree (since we
> are done with it at least for the non-interactive test case)
> make -j4 VERBOSE=1 test_interactive in the build tree
> ERROR: make -j4 test_interactive failed in the build tree  (I'm
> deleting open windows at this stage, shutting down)

Hmm.  Letting the whole OpenSuse13.2 comprehensive test complete would be 
extremely
worthwhile also since I don't think we have ever seen a complete
comprehensive test for that variant of Linux.

> I'll go back to windows and see whats up there, now that I know what I
> should be seeing.
>
> OK CygWIN(64) is a bust - make has a problem.

tarball of comprehensive_test_disposeable/shared/output_tree?

> /mingw64/ via Msys2 - make sailed through, same ctest failure.
> /mingw32/ via msys2 - make is ok, ctest has hung with no discernable
> activity, on c++/x00:

I thought you reported MSYS2 results above.  Are you referring to a
different platform there as opposed to the two platforms here?
Anyhow, more descriptive details concerning these various platforms you are 
reporting
are essential.

In any case, whenever there is a problem, please collect everything in
comprehensive_test_disposeable/shared/output_tree,
comprehensive_test_disposeable/nondynamic/output_tree, and 
comprehensive_test_disposeable/static/output_tree in a tarball (the
latter two directories only if you get that far).  Also, please
exclude everything else from the tarball because it would be too
large.

Thanks again for attempting all this testing for a large number of
different platforms, and I look forward to your several different
output_tree tarball replies, and also a report from you that when you
let the OpenSuse version actually finish, that you obtained
comprehen

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-03-28 21:40- Andrew Ross wrote:

> On Sat, Mar 28, 2015 at 09:07:46PM +, Andrew Ross wrote:
>>
>> Alan,
>>
>> For me with Ubuntu 14.10 (Utopic Unicorn) scripts/comprehensive_test.sh
>> fails. Compile all goes fine, but the test of the C examples with the pdf
>> driver fails at example 24 with
>>
>> ERROR: error_no=1050, detail_no=0
>> ERROR in haru library
>>
>> I'm assuming this is a libharu issue since no-one else has run into it.
>> A quick google search suggests this error is "An invalid font-size was
>> set." For reference this is version 2.2.1-1.1. Alan, what version are you
>> running?

I use 2.2.1 as well but with additional patches applied.

See cmake/epa_build/libharu/CMakeLists.txt for how to locate those
patches.

Most of those are to install a CMake-based build system which you
don't need (except for epa_build), but one of those, i.e.,
cmake/epa_build/libharu/large_font.patch is a bug fix for large fonts
(as occurs for example 24), see
.  The
Debian maintainer responded there and said he would apply the patch to
the Debian package, but the sid, testing, and stable version of that
package are all the same so it appears he did not do so.  If it is
possible for him to make that change this late in the Debian release
cycle, could you please nag him to do so?

You may also want to nag the Ubuntu developers about that patch.

>>
>> I'll disable the pdf driver and try again.
>
> This gets me through the shared library ctest test in the build tree. The
> rest is still running.
>
> One other thing I noticed is that itcl / itk are disabled because the
> header files are not found. I do have them installed. Looks like the
> headers are now in /usr/include/itcl3/ . CMake is looking in
> ${TCL_INCLUDE_PATH}/itcl3, but TCL_INCLUDE_PATH is /usr/include/tcl8.6 in
> my case so this doesn't work. It used to work, so I expect this is
> something related to the way itcl / itk are packaged on Ubuntu. Alan, do
> you run into this on Debian?

Both Debian stable and epa_build are fine in this regard, and I suspect
Orion would have said something if this was an issue on Fedora.

The current find_path assumption in cmake/modules/tcl-related.cmake is
the itcl and itk headers are in subdirectories of the versioned tcl
headers which is what occurs for both Debian stable and epa_build and
makes some sense since itcl and itk versions depend on Tcl (and Tk)
version.  But I guess Ubuntu have decided to violate that assumption.

I don't think that if Itcl and Itk are missing it is a
release-critical issue since they play a fairly small role for PLplot.
Therefore, I think we should deal with this issue post-release by
coming up with some PATHS or HINTS options for the find_path commands
that will make Ubuntu work automatically without interfering with what
works for Debian stable (and other distros?) and epa_build.  However,
for now, if you want to test Itcl and Itk on Ubuntu, you could do that
by setting ITCL_INCLUDE_PATH and ITK_INCLUDE_PATH appropriately.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Andrew Ross]

On Sat, Mar 28, 2015 at 09:07:46PM +, Andrew Ross wrote:
> 
> Alan,
> 
> For me with Ubuntu 14.10 (Utopic Unicorn) scripts/comprehensive_test.sh
> fails. Compile all goes fine, but the test of the C examples with the pdf
> driver fails at example 24 with
> 
> ERROR: error_no=1050, detail_no=0
> ERROR in haru library
> 
> I'm assuming this is a libharu issue since no-one else has run into it.
> A quick google search suggests this error is "An invalid font-size was
> set." For reference this is version 2.2.1-1.1. Alan, what version are you
> running?
> 
> I'll disable the pdf driver and try again.

This gets me through the shared library ctest test in the build tree. The
rest is still running.

One other thing I noticed is that itcl / itk are disabled because the
header files are not found. I do have them installed. Looks like the
headers are now in /usr/include/itcl3/ . CMake is looking in
${TCL_INCLUDE_PATH}/itcl3, but TCL_INCLUDE_PATH is /usr/include/tcl8.6 in
my case so this doesn't work. It used to work, so I expect this is
something related to the way itcl / itk are packaged on Ubuntu. Alan, do
you run into this on Debian?

Andrew

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: call for comprehensive testing

[Andrew Ross]

On Thu, Mar 26, 2015 at 06:50:22PM -0700, Alan Irwin wrote:
> On 2015-03-25 14:30-0700 Alan W. Irwin wrote:
> 
> >> 2. Because of issues like the qt_example segfault that I have just
> >> fixed, I have as yet been unable to complete a comprehensive test of
> >> PLplot on Linux.  Until I can get such a clean test the possibility
> >> exists there are other such segfault issues lurking in our master tip
> >> code base due to some regression since the 5.10.0 release.
> 
> With commit id 5f6e28f I finally have been able to complete
> scripts/comprehensive_test.sh on Linux without issues which removes
> the last known regression compared to 5.10.0 for this release which is
> a much-desired result.
> 
> My next steps are to do some straightforward release preliminaries
> (such as setting version strings and updating the website) followed by
> epa_build and comprehensive test of "plplot" on Linux (which will do a
> similar test to what I just completed but for the latest versions of
> PLplot dependencies) and "plplot_lite" on MinGW/MSYS/Wine.  Note that
> Wine test will take a couple of days (since Wine is so slow).
> 
> While I am doing those steps I strongly encourage the rest of you to
> do comprehensive testing of PLplot master tip on all platforms that
> are accessible to you following the instructions at
> 
> and
> .
> 
> In the past such comprehensive testing results have been good on Linux
> for me and others, good on MinGW/MSYS (for me), bad on MinGW/MSYS (for
> unknown reasons) for Arjen, partially successful on Cygwin for Arjen,
> partially tested (just the test_noninteractive target for shared
> library case) on Mac OS X (for Jim), and completely untested for
> MinGW-w64/MSY2 and MSVC.  So I view essentially all the non-Linux
> platforms as either showing mixed results (MinGW/MSYS) or not
> comprehensively tested (i.e., either partial results or no results) at
> this time. Therefore, I hope you will all try comprehensive testing to
> help bring these non-Linux platforms up to the same reliability that
> we enjoy on Linux.
> 
> N.B. For a given PLplot developer, a clean result for
> scripts/comprehensive_test.sh for all platforms accessible to you is
> greatly to be desired, since that result allows you to re-run the test
> semi-automatically and conveniently from time to time to catch most
> future PLplot regressions for all platforms that interest you.

Alan,

For me with Ubuntu 14.10 (Utopic Unicorn) scripts/comprehensive_test.sh
fails. Compile all goes fine, but the test of the C examples with the pdf
driver fails at example 24 with

ERROR: error_no=1050, detail_no=0
ERROR in haru library

I'm assuming this is a libharu issue since no-one else has run into it.
A quick google search suggests this error is "An invalid font-size was
set." For reference this is version 2.2.1-1.1. Alan, what version are you
running?

I'll disable the pdf driver and try again.

Andrew

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: call for comprehensive testing

[Alan W. Irwin]

On 2015-03-25 14:30-0700 Alan W. Irwin wrote:

>> 2. Because of issues like the qt_example segfault that I have just
>> fixed, I have as yet been unable to complete a comprehensive test of
>> PLplot on Linux.  Until I can get such a clean test the possibility
>> exists there are other such segfault issues lurking in our master tip
>> code base due to some regression since the 5.10.0 release.

With commit id 5f6e28f I finally have been able to complete
scripts/comprehensive_test.sh on Linux without issues which removes
the last known regression compared to 5.10.0 for this release which is
a much-desired result.

My next steps are to do some straightforward release preliminaries
(such as setting version strings and updating the website) followed by
epa_build and comprehensive test of "plplot" on Linux (which will do a
similar test to what I just completed but for the latest versions of
PLplot dependencies) and "plplot_lite" on MinGW/MSYS/Wine.  Note that
Wine test will take a couple of days (since Wine is so slow).

While I am doing those steps I strongly encourage the rest of you to
do comprehensive testing of PLplot master tip on all platforms that
are accessible to you following the instructions at

and
.

In the past such comprehensive testing results have been good on Linux
for me and others, good on MinGW/MSYS (for me), bad on MinGW/MSYS (for
unknown reasons) for Arjen, partially successful on Cygwin for Arjen,
partially tested (just the test_noninteractive target for shared
library case) on Mac OS X (for Jim), and completely untested for
MinGW-w64/MSY2 and MSVC.  So I view essentially all the non-Linux
platforms as either showing mixed results (MinGW/MSYS) or not
comprehensively tested (i.e., either partial results or no results) at
this time. Therefore, I hope you will all try comprehensive testing to
help bring these non-Linux platforms up to the same reliability that
we enjoy on Linux.

N.B. For a given PLplot developer, a clean result for
scripts/comprehensive_test.sh for all platforms accessible to you is
greatly to be desired, since that result allows you to re-run the test
semi-automatically and conveniently from time to time to catch most
future PLplot regressions for all platforms that interest you.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Alan W. Irwin]

On 2015-03-21 12:29-0700 Alan W. Irwin wrote:

> Just to summarize where we stand there are several open-ended issues
> blocking the release.
>
> 1. I am in the middle of a hunt for plend memory management issues caused by 
> redundant
> library linking (see previous post to Andrew).

I have finished that hunt, but will only fix the two cases found
(for -dev tk and -dev tkwin) post-relase (see just prior post for more
details).

>
> 2. Because of issues like the qt_example segfault that I have just
> fixed, I have as yet been unable to complete a comprehensive test of
> PLplot on Linux.  Until I can get such a clean test the possibility
> exists there are other such segfault issues lurking in our master tip
> code base due to some regression since the 5.10.0 release.
>

> 3. -DOLD_WXWIDGETS=ON does not yet work.
Thanks to Phil's efforts it now works for me so I think we
are likely done here unless Phil proves the one OLD_WXWIDGETS
issue he found on his system (which I did not find on mine) is
a regression from PLplot-5.10.0

In sum, 1 and 3 are no longer relevant, I am still working on 2, and deep 
freeze continues.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: another plend segfault and/or double free

[Alan W. Irwin]

On 2015-03-21 11:57-0700 Alan W. Irwin wrote:

> Hi Andrew:
>
> I have now (commit fa0c879) solved this release-critical regression.
>
> The crux of the problem is redundant linking of qt_example to both
> plplot (which contained all of the code in plplotqt for this
> ENABLE_DYNDRIVERS=NO case) and plplotqt. examples/c++/qt_example had no severe
> memory management issues if I manipulated visibility so that I used
> either the plplotqt symbols from just plplot or just plplotqt.
> However, if both sets of symbols are made visible (the change that
> formally caused this regression), it caused severe memory management
> issues when the libraries were closed at plend.  The obvious fix for
> this issue has been applied which is to drop the redundant linking of
> qt_example to libplplotqt for the ENABLE_DYNDRIVERS=NO case.
>
> There are obvious broader implications here now that we have a clear
> case of plend memory management issues caused by redundant linking to
> two sets of the identical code located in two different libraries. I
> frankly never expected this to be an issue since I thought the linker
> would choose one set or the other with no other consequences. But from
> this experience this is obviously not the case (probably due to all
> the behind-the-scenes shenanigans that go on when libraries are
> closed). Anyhow, since I have not been aware of this issue for all the
> years I have been trying to maintain correct PLplot linking, I am
> virtually positive there are similar instances of this same problem
> for other device drivers.  Note, for example, that for the
> ENABLE_DYNDRIVERS=NO case there is necessarily always two copies of
> the device driver binding code (e.g., like the libplplotqt binding
> code) to break circular linking issues.
>
> So my current plan is to look very carefully for such issues and fix
> them (likely most of those fixes will occur post-release if there is
> not a clear regression from 5.10.0 results) in the hope this
> refinement of our linking model will ultimately resolve a substantial
> number of the plend memory management issues we have been
> encountering.

It turns out this is not an issue at all for wxwidgets because that
driver code does not depend on bindings/wxwidgets code.

So the only maintained drivers where for ENABLE_DYNDRIVERS=NO
duplicate code occurs in two separate libraries is for -dev tk and
-dev tkwin.  But the plplot library currently does not have visible
symbols corresponding to the libplplottcltk symbols so from the experience with 
plplot and plplotqt there should
be no memory management issues for Windows and Unix forms of gcc if
the gcc compile option -fvisibility=hidden is used and also no such
issues for the MSVC case.

Therefore, for Linux I dropped the gcc -fvisibility=hidden option in
anticipation that would generate severe memory management issues for
-dev tk, but it did not.  So experience with the C++ qt device driver
does not predict exactly what will happen for the C tk device driver.
Nevertheless, we do have a large number of outstanding plend memory
management issues for anything having to do with Tcl and Tk, and at
least in the C++ case, duplicate symbols defined in two separate
libraries does lead to plend memory management trouble. Therefore, as
a post-release project I plan to make visible all the libplplottcltk
symbols that are currently not visible in plplot, and then drop
libplplottcltk from all link commands to see whether that fixes some
of the current plend issues with Tcl/Tk.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: need help with OLD_WXWIDGETS=ON option (fwd)

[Alan W. Irwin]

On 2015-03-25 15:39- Phil Rosenberg wrote:

> Hi Alan
> I have pushed that fix. There was also a problem on resize that caused
> a hang due to re-entrancy in the event loop which I have fixed too.
>
> There is also a problem with rendering the wxPLplotDemo whereby there
> are sections of the window that are not being rendered. I'm not sure
> if this is a long standing issue that nobody has noticed before or if
> it is something that has changed in wxWidgets 3.0 or if it is a new
> thing. However all the examples render correctly.

Hi Phil:

Your fix works perfectly here.

I have had a look at a small sample of the examples with
-DOLD_WXWIDGETS=ON and -dev wxwidgets, and they appear to render as
before.  Note, I don't say they render correctly because there were
some long-standing rendering issues with old wxwidgets such as affine
transform issues with example 8 backend=0, and I am just glad we don't
have to worry about fixing those anymore.  In other words,
-DOLD_WXWIDGETS=ON appears to deliver exactly what we had before
for 5.10.0, warts and all, which is our goal.

I have also looked at wxPLplotDemo results with -DOLD_WXWIDGETS=ON,
and that renders perfectly with the Debian stable version of the
wxwidgets libraries (2.8.12.1).  So that supports your hypothesis
above that the rendering issue you found for this case is due to an
inconsistency with wxWidgets 3.0.  So if you confirm this issue also
existed for the 5.10.0 version of the wxwidgets device driver, then
there is nothing more you should do here since the only fixing we
should do for the -DOLD_WXWIDGETS=ON case is if there is a regression
(change) from what occurred for the wxwidgets device driver for
PLplot-5.10.0.

So anticipating you will not find such a regression, then thanks very
much for fixing the -DOLD_WXWIDGETS=ON case which was a major
showstopper for this release, and it looks like the rest of this
release is largely up to me (unless I find more regressions with any
aspect of PLplot that I need help fixing).

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: another plend segfault and/or double free

[Andrew Ross]

Alan,

Thanks for the update. I'm glad you managed to track it down. I'd held of
delving into this as you seemed to have it under control. I'm also
slightly surprised at the linker not being more intelligent here.
Certainly something we need to be wary of.

Andrew

On Sat, Mar 21, 2015 at 11:57:20AM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> I have now (commit fa0c879) solved this release-critical regression.
> 
> The crux of the problem is redundant linking of qt_example to both
> plplot (which contained all of the code in plplotqt for this
> ENABLE_DYNDRIVERS=NO case) and plplotqt. examples/c++/qt_example had no severe
> memory management issues if I manipulated visibility so that I used
> either the plplotqt symbols from just plplot or just plplotqt.
> However, if both sets of symbols are made visible (the change that
> formally caused this regression), it caused severe memory management
> issues when the libraries were closed at plend.  The obvious fix for
> this issue has been applied which is to drop the redundant linking of
> qt_example to libplplotqt for the ENABLE_DYNDRIVERS=NO case.
> 
> There are obvious broader implications here now that we have a clear
> case of plend memory management issues caused by redundant linking to
> two sets of the identical code located in two different libraries. I
> frankly never expected this to be an issue since I thought the linker
> would choose one set or the other with no other consequences. But from
> this experience this is obviously not the case (probably due to all
> the behind-the-scenes shenanigans that go on when libraries are
> closed). Anyhow, since I have not been aware of this issue for all the
> years I have been trying to maintain correct PLplot linking, I am
> virtually positive there are similar instances of this same problem
> for other device drivers.  Note, for example, that for the
> ENABLE_DYNDRIVERS=NO case there is necessarily always two copies of
> the device driver binding code (e.g., like the libplplotqt binding
> code) to break circular linking issues.
> 
> So my current plan is to look very carefully for such issues and fix
> them (likely most of those fixes will occur post-release if there is
> not a clear regression from 5.10.0 results) in the hope this
> refinement of our linking model will ultimately resolve a substantial
> number of the plend memory management issues we have been
> encountering.
> 
> 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
> __
> 
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status

[Alan W. Irwin]

Just to summarize where we stand there are several open-ended issues
blocking the release.

1. I am in the middle of a hunt for plend memory management issues caused by 
redundant
library linking (see previous post to Andrew).

2. Because of issues like the qt_example segfault that I have just
fixed, I have as yet been unable to complete a comprehensive test of
PLplot on Linux.  Until I can get such a clean test the possibility
exists there are other such segfault issues lurking in our master tip
code base due to some regression since the 5.10.0 release.

3. -DOLD_WXWIDGETS=ON does not yet work.  For this case, all the
wxwidgets related code in drivers, bindings/wxwidgets, and
examples/c++ is identical to the old wxwidgets code that worked
before. So the working hypothesis is there was some wxwidgets-only
core change in bindings/c++, include, or src that is incompatable with
the way the old wxwidgets code worked.  This core change likely does
not involve plbuf since old wxwidgets and our other device drivers
depend on plbuf in similar ways.  Thus, the problem is to find that
old wxwidgets incompatible core change and make it conditional
depending on OLD_WXWIDGETS.  Both Jim and I have had a go at this
issue, but we have both failed due to our lack of knowledge concerning
wxwidets.  As a last resort (because he is swamped by other
commitments at this time) our leading wxwidgets expert, Phil, has
kindly agreed to take a look at this issue although no promises
as to when he will be able to figure this out.

In sum, deep freeze (only documentation changes and fixes for
regressions compared to 5.10.0 should be committed to master although
otherwise development should continue on private topic branches)
continues.  Also, although we are obviously in the end stages of this
release cycle there is no possibility of making even a reasonable
estimate of the date for the release until the above 3 open-ended
issues have been dealt with.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: another plend segfault and/or double free

[Alan W. Irwin]

Hi Andrew:

I have now (commit fa0c879) solved this release-critical regression.

The crux of the problem is redundant linking of qt_example to both
plplot (which contained all of the code in plplotqt for this
ENABLE_DYNDRIVERS=NO case) and plplotqt. examples/c++/qt_example had no severe
memory management issues if I manipulated visibility so that I used
either the plplotqt symbols from just plplot or just plplotqt.
However, if both sets of symbols are made visible (the change that
formally caused this regression), it caused severe memory management
issues when the libraries were closed at plend.  The obvious fix for
this issue has been applied which is to drop the redundant linking of
qt_example to libplplotqt for the ENABLE_DYNDRIVERS=NO case.

There are obvious broader implications here now that we have a clear
case of plend memory management issues caused by redundant linking to
two sets of the identical code located in two different libraries. I
frankly never expected this to be an issue since I thought the linker
would choose one set or the other with no other consequences. But from
this experience this is obviously not the case (probably due to all
the behind-the-scenes shenanigans that go on when libraries are
closed). Anyhow, since I have not been aware of this issue for all the
years I have been trying to maintain correct PLplot linking, I am
virtually positive there are similar instances of this same problem
for other device drivers.  Note, for example, that for the
ENABLE_DYNDRIVERS=NO case there is necessarily always two copies of
the device driver binding code (e.g., like the libplplotqt binding
code) to break circular linking issues.

So my current plan is to look very carefully for such issues and fix
them (likely most of those fixes will occur post-release if there is
not a clear regression from 5.10.0 results) in the hope this
refinement of our linking model will ultimately resolve a substantial
number of the plend memory management issues we have been
encountering.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: another plend segfault and/or double free

[Alan W. Irwin]

On 2015-03-19 14:38-0700 Alan W. Irwin wrote:

> Hi Andrew (again):
>
> I just discovered this issue was a regression compared to 5.10.0.  So
> I will git bisect it to see which commit first created this issue, and
> get back to you at that point if I cannot figure out the problem
> introduced by that commit.

According to git bisect the issue first appeared for 6f5dc7b546f05c79

That's one of my commits which is a small but rather subtle symbol visibility 
change given by the
following diff:

software@raven> git diff 6f5dc7b546f05c79^ 6f5dc7b546f05c79
diff --git a/include/pldll.h.in b/include/pldll.h.in
index bdf5f7e..f818b64 100644
--- a/include/pldll.h.in
+++ b/include/pldll.h.in
@@ -131,7 +131,10 @@
#define PLDLLIMPEXP_PLPLOT_MODULE_DATA( type )PLDLLIMPORT type
  #endif

-#if defined ( plplotqt_EXPORTS )
+// Note for the case when ENABLE_DYNDRIVERS is not defined, the
+// libplplot build specifically includes bindings/qt-gui/plqt.cpp (see
+// cmake/modules/qt.cmake).
+#if defined ( plplotqt_EXPORTS ) || ( !defined ( ENABLE_DYNDRIVERS ) && 
defined ( plplot_EXPORTS ) )
#define PLDLLIMPEXP_QTPLDLLEXPORT
#define PLDLLIMPEXP_QT_DATA( type )PLDLLEXPORT type
  #else

So the difference means that for the case where ENABLE_DYNDRIVERS is
not #defined, then for _both_ the build of libplplotqt and the build
of libplplot, PLDLLIMPEXP_QT and PLDLLIMPEXP_QT_DATA are both defined
(which makes complete sense to me since some the qt device driver code
gets into libplplot for the nondynamic devices case). So I don't see
anything wrong with the above change at all, but if anyone spots a
problem, please let me know.  Meanwhile, I will keep investigating by
seeing whether temporarily reverting the above change for master tip
solves the segfault issue (confirming the above change is
the only source of the problem) and by investigations with nm.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: another plend segfault and/or double free

[Alan W. Irwin]

Hi Andrew (again):

I just discovered this issue was a regression compared to 5.10.0.  So
I will git bisect it to see which commit first created this issue, and
get back to you at that point if I cannot figure out the problem
introduced by that commit.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: another plend segfault and/or double free

[Alan W. Irwin]

Hi Andrew:

I just discovered another issue which may be release critical.

For the -DENABLE_DYNDRIVERS=OFF case (with everything else default so
this issue occurs when qt_example is built against the system Qt4
libraries), the usual test_interactive target generated a glibc double
free error message for examples/c++/qt_example.

When I investigated further with valgrind, here were the results.

==9797== Memcheck, a memory error detector
==9797== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==9797== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==9797== Command: examples/c++/qt_example
==9797== 
==9797== Invalid free() / delete / delete[] / realloc()
==9797==at 0x4C279DC: operator delete(void*) (vg_replace_malloc.c:457)
==9797==by 0x6F28E64: __cxa_finalize (cxa_finalize.c:56)
==9797==by 0x644B352: ??? (in 
/home/software/plplot/HEAD/build_dir/src/libplplot.so.12.0.1)
==9797==by 0x400E4CB: _dl_fini (dl-fini.c:244)
==9797==by 0x6F28AE1: __run_exit_handlers (exit.c:78)
==9797==by 0x6F28B34: exit (exit.c:100)
==9797==by 0x6F10EB3: (below main) (libc-start.c:276)
==9797==  Address 0x10ad0500 is 0 bytes inside a block of size 40 free'd
==9797==at 0x4C279DC: operator delete(void*) (vg_replace_malloc.c:457)
==9797==by 0x6F28E64: __cxa_finalize (cxa_finalize.c:56)
==9797==by 0x621D362: ??? (in 
/home/software/plplot/HEAD/build_dir/bindings/qt_gui/libplplotqt.so.1.0.0)
==9797==by 0x400E4CB: _dl_fini (dl-fini.c:244)
==9797==by 0x6F28AE1: __run_exit_handlers (exit.c:78)
==9797==by 0x6F28B34: exit (exit.c:100)
==9797==by 0x6F10EB3: (below main) (libc-start.c:276)
==9797== 
==9797== Invalid read of size 1
==9797==at 0x5ED0FCD: QObject::~QObject() (in 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.2)
==9797==by 0x6F28E64: __cxa_finalize (cxa_finalize.c:56)
==9797==by 0x644B352: ??? (in 
/home/software/plplot/HEAD/build_dir/src/libplplot.so.12.0.1)
==9797==by 0x400E4CB: _dl_fini (dl-fini.c:244)
==9797==by 0x6F28AE1: __run_exit_handlers (exit.c:78)
==9797==by 0x6F28B34: exit (exit.c:100)
==9797==by 0x6F10EB3: (below main) (libc-start.c:276)
==9797==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==9797== 
==9797== 
==9797== Process terminating with default action of signal 11 (SIGSEGV)
==9797==  Access not within mapped region at address 0x20
==9797==at 0x5ED0FCD: QObject::~QObject() (in 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.2)
==9797==by 0x6F28E64: __cxa_finalize (cxa_finalize.c:56)
==9797==by 0x644B352: ??? (in 
/home/software/plplot/HEAD/build_dir/src/libplplot.so.12.0.1)
==9797==by 0x400E4CB: _dl_fini (dl-fini.c:244)
==9797==by 0x6F28AE1: __run_exit_handlers (exit.c:78)
==9797==by 0x6F28B34: exit (exit.c:100)
==9797==by 0x6F10EB3: (below main) (libc-start.c:276)
==9797==  If you believe this happened as a result of a stack
==9797==  overflow in your program's main thread (unlikely but
==9797==  possible), you can try to increase the size of the
==9797==  main thread stack using the --main-stacksize= flag.
==9797==  The main thread stack size used in this run was 8388608.
==9797== 
==9797== HEAP SUMMARY:
==9797== in use at exit: 360,355 bytes in 3,145 blocks
==9797==   total heap usage: 21,464 allocs, 18,320 frees, 5,936,081 bytes 
allocated
==9797== 
==9797== LEAK SUMMARY:
==9797==definitely lost: 1,776 bytes in 13 blocks
==9797==indirectly lost: 3,466 bytes in 84 blocks
==9797==  possibly lost: 3,032 bytes in 12 blocks
==9797==still reachable: 352,081 bytes in 3,036 blocks
==9797== suppressed: 0 bytes in 0 blocks
==9797== Rerun with --leak-check=full to see details of leaked memory
==9797== 
==9797== For counts of detected and suppressed errors, rerun with: -v
==9797== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 12 from 8)
Segmentation fault

In contrast I get relatively good valgrind results when
-DENABLE_DYNDRIVERS=ON (the default case)

==12544== Memcheck, a memory error detector
==12544== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==12544== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==12544== Command: examples/c++/qt_example
==12544== 
==12544== 
==12544== HEAP SUMMARY:
==12544== in use at exit: 268,716 bytes in 2,536 blocks
==12544==   total heap usage: 20,738 allocs, 18,202 frees, 5,877,042 bytes 
allocated
==12544== 
==12544== LEAK SUMMARY:
==12544==definitely lost: 1,600 bytes in 11 blocks
==12544==indirectly lost: 3,466 bytes in 84 blocks
==12544==  possibly lost: 2,448 bytes in 7 blocks
==12544==still reachable: 261,202 bytes in 2,434 blocks
==12544== suppressed: 0 bytes in 0 blocks
==12544== Rerun with --leak-check=full to see details of leaked memory
==12544== 
==12544== For counts of detected and suppressed errors, rerun with: -v
==12544== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 6)

In both cases I simply exited t

Re: [Plplot-devel] Release status

[Jim Dishaw]

On Mar 19, 2015, at 12:57 PM, "Alan W. Irwin"  wrote:

> On 2015-03-19 09:23-0600 Orion Poplawski wrote:
> 
>> On 03/19/2015 12:41 AM, Alan W. Irwin wrote:
>>> On 2015-03-18 21:26-0600 Orion Poplawski wrote:
>>> 
 On 03/18/2015 08:41 PM, Alan W. Irwin wrote:
> Here is where I think we are.
 
 The issues in Fedora land are:
 
 - The octave+swig+UTF-8 issue I just reported
 - The move to the cairo2 ocaml bindings.  We'll need to get this packaged 
 in
 Fedora to support it.
>>> 
>>> Thanks for that report.  If you test 5.10.0 the same way do you get
>>> similar results?  That additional test would help to sort out whether
>>> these issues have been recently introduced in PLplot or whether the
>>> latest Fedora environment is somewhow incompatible with PLplot
>>> regardless of PLplot version.
>>> 
>>> Alan
>> 
>> Yeah, it's Fedora.  I also replied to Jim's email.

I am installing Fedora rawhide in a VM and will see if I can track down the bug.

> 
> That is good to know from our perspective of just making a new
> release, but I am also curious what could be causing the issue on
> Fedora.  I think you have already mentioned a gcc-5 bug as a
> possibility, but could it also be a regression in behaviour for some
> new swig or octave version?
> 

My hypothesis is that a unicode string that is encoded in a non UTF-8 format is 
being passed to plP_text()



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Alan W. Irwin]

On 2015-03-19 09:23-0600 Orion Poplawski wrote:

> On 03/19/2015 12:41 AM, Alan W. Irwin wrote:
>> On 2015-03-18 21:26-0600 Orion Poplawski wrote:
>>
>>> On 03/18/2015 08:41 PM, Alan W. Irwin wrote:
 Here is where I think we are.
>>>
>>> The issues in Fedora land are:
>>>
>>> - The octave+swig+UTF-8 issue I just reported
>>> - The move to the cairo2 ocaml bindings.  We'll need to get this packaged in
>>> Fedora to support it.
>>
>> Thanks for that report.  If you test 5.10.0 the same way do you get
>> similar results?  That additional test would help to sort out whether
>> these issues have been recently introduced in PLplot or whether the
>> latest Fedora environment is somewhow incompatible with PLplot
>> regardless of PLplot version.
>>
>> Alan
>
> Yeah, it's Fedora.  I also replied to Jim's email.

That is good to know from our perspective of just making a new
release, but I am also curious what could be causing the issue on
Fedora.  I think you have already mentioned a gcc-5 bug as a
possibility, but could it also be a regression in behaviour for some
new swig or octave version?

I have had several interactions with the octave developers, and in my
opinion they are somewhat blind to the possibilities with UTF-8.  For
example, our own octave plplot documentation is written in UTF-8 (for
the math symbols), and it turned out that just worked in octave, but
their internationalization team did not appear to be interested in the
slightest in that obvious possibility for translating their own
documentation strings to other languages.

Anyhow, in my opinion it is quite possible that octave developers have
introduced a UTF-8-related regression since they use UTF-8 so little
themselves.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status

[Alan W. Irwin]

Here is where I think we are.

The deep freeze is still in effect.

I have given up on the possibility of fixing the plend problems this
late in the release cycle which I thought might be a spin-off from
Norm's xwin plend fix that was being discussed.  We will also put off
dealing with that xwin fix itself until post release.

Phil has told me off list that he is swamped so it is unlikely he can
contribute further to this release effort.  Therefore, to deal
partially with that I will write the release notes for wxwidgets, and
let the other wxwidgets documentation issues slide. Also, Jim has
kindly agreed to at least look at the one last release-critical
wxwidgets issue which is to get OLD_WXWIDGETS=ON to work properly.

I am currently dealing with two build-system issues which are (1) the
remaining MSVC visibility issues that I became aware of yesterday (to
fix that all apps need the -DUSINGDLL COMPILE_FLAGS property set for
the shared library case), and (2) some target dependency logic that
doesn't work correctly for the installed examples build-system case
that is screwing up my attempts to do comprehensive testing on Linux.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: epa_build: libharu and general release topics

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Saturday, March 14, 2015 1:19 AM
> To: Andrew Ross
> Cc: PLplot development list
> Subject: [Plplot-devel] Release status: epa_build: libharu and general 
> release topics
>
>
> @ Arjen: If there is anything else release-rated we have discussed that I have
> forgotten or you notice any new release-related topic, please let me know.
>


I had a curious error when I tried to build Plplot and the C and C++ examples 
with VS 2010. Something to do with the macro WIN32. But when I tried to 
identify the exact configuration (32 bits, 64 bits, something described as 
"cross tools"), the problem had disappeared.

However, using only C and C++ did bring up an issue I had not noticed before: 
VS 2010 complains about MIN() and MAX() in examples x08.cc and x33.cc - loss of 
precision going from PLFLT to PLINT. I have stared at the code but as far as I 
can tell there should be no mixup of precisions. It is probably nothing 
important, but I thought I'd mention it anyway.

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.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: request for release notes on plbuf and plmeta/plrender changes

[Alan W. Irwin]

On 2015-03-15 16:24-0400 Jim Dishaw wrote:

> Release notes:
>
> An experimental plot metafile input function, plreadmetafile(), was 
> implemented to provide an integrated read/write capability into the core of 
> PLplot.  In conjunction, the plmeta driver has been updated to support a 
> transition to a new format.  A key
> change is storing the raw string data used to represent text and plot symbols 
> into the metafile instead of the rendered
> characters.  The new features are currently disabled in order to prevent 
> breaking compatibility with the existing format.
>
> The plbuf.c file was cleaned up by removing code that was used to write 
> temporary files.  The temporary file implementation
> has been deprecated for almost five years and was in an unmaintained state.  
> This improved the readability of the code.  Performance enhancements were 
> also made to plbuf to improve performance:  First, the rd_data_no_copy() 
> internal function was implemented to avoid needless memory allocation and 
> copying in plbuf.c; and, second, a two-byte alignment is maintained in the 
> plot buffer as most architectures have better memory access performance with 
> an even byte alignment.  An experimental plot buffer import was implemented 
> as a PLESC operation to support wxwidget development.  The plot state save at 
> the
> beginning of plot (BOP) was improved in order to fix rendering artifacts when 
> plots were resized. In addition, the text handling
> operations in the buffer have been improved; however, the cairo driver does 
> not correctly handle resizes correctly and it
> uses an alternate text processing method that is currently disabled in the 
> plot buffer.  A bug in pattern fills was corrected and
> the plot buffer now will only contain the PLSTATE_FILL operation rather than 
> both PLSTATE_FILL and the individual LINE commands of the fill.  This was 
> causing a line doubling effect when plots were resized.
>

Hi Jim:

Thanks very much for these release notes which I have edited and
inserted into README.relase file (commit id e048de7).  I believe that
completes our pre-release business.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

[Alan W. Irwin]

On 2015-03-15 20:03-0400 Jim Dishaw wrote:

> Did we ever come to a resolution on this?
>
>> On Mar 13, 2015, at 3:10 PM, Jim Dishaw  wrote:
>> The plP_eop() call, for some reason, results in extra keypresses
needed to advance to the next page. I thought I knew the reason, but
after examining the code, my initial hypothesis doesn't look correct.
I will step through the code to see what is causing the issue.

Hi Jim:

I have some points to offer.

I confirm the issue (which shows up whenever I attempt to resize -dev
xwin).

I have no idea whether Phil is investigating fixing this or not.

But regardless of whether you or Phil fixes the issue, the fix should
be done on a topic branch now and pushed to master post-release since
the fix very likely involves a change to plbuf, which I want to avoid
at this late date in the release cycle.

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

[Jim Dishaw]

Did we ever come to a resolution on this?



> On Mar 13, 2015, at 3:10 PM, Jim Dishaw  wrote:
> 
> 
>> On Mar 13, 2015, at 2:34 PM, Phil Rosenberg  wrote:
>> 
>> Hi Jim Alan
>> Firstly I'm not in front of a pc right now so I'm doing function names from 
>> memory. Apologies if they are wrong.
>> 
>> Are you talking about the call to plP_eop() that is in the plreplot() 
>> function?
>> 
>> If so, I put that there. The reason is that when creating the first page 
>> from a buffer,   we need to do the bop actions, however due to the plinit 
>> call the status is already set to bop, so the call to plP_bop does nothing. 
>> The state #define values are not exposed to plbuf.c so the appropriate 
>> action appeared to be to end the existing page.
>> It might be that changes to device initialization mean this is no longer 
>> necessary, but I don't know without testing. I'm not sure why it would cause 
>> the behaviour you describe though. Which device were they in?
> 
> The plP_eop() call, for some reason, results in extra keypresses needed to 
> advance to the next page. I thought I knew the reason, but after examining 
> the code, my initial hypothesis doesn't look correct. I will step through the 
> code to see what is causing the issue. 
> 
>> Phil
>> From: Alan W. Irwin
>> Sent: ‎13/‎03/‎2015 17:59
>> To: Phil Rosenberg; Jim Dishaw
>> Cc: PLplot development list
>> Subject: Release status: fix for plbuf resizing issue
>> 
>> On 2015-03-13 11:10-0400 Jim Dishaw wrote:
>> 
>> > Alan,
>> >
>> 
>> > I noticed a bug that occurs when resizing a plot.  Every time a plot
>> is resized, an extra key press is required to advance the page.  The
>> problem appears to be a pop_eop() that was added in plRemakePlot()
>> during one of your fixes (afd73a98).  If I comment that line out, the
>> bug goes way.  There should already be an EOP (or at least in most
>> cases) at the end of the buffer because Does calling plP_eop()
>> internally cause problems if the application was not expecting it? 
>> I've run through all the examples without the plP_eop() call and
>> cannot detect a problem.  Example 17 had no issues and that does not
>> have an EOP.
>> 
>> >
>> > If the plP_eop() is required, I propose two solutions:
>> >
>> > 1) Check for an EOP before putting another one.
>> > 2) Do not replay the plot buffer unless there is an EOP (which would 
>> > prevent redraws until an EOP and break example 17).
>> >
>> 
>> Hi Jim:
>> 
>> I verify that bug here (using examples/c/x01c -dev xwin).
>> 
>> However, you have to dig deeper to find out who to blame.  In other
>> words, "It wasn't me".  :-)
>> 
>> Here is the git magic you need.
>> 
>> software@raven> git blame src/plbuf.c |grep plP_eop
>> afd37a98 (Alan W. Irwin  2015-03-11 02:33:40 -0700 1222) plP_eop();
>> 
>> So far so good, but if you use git log to look up that commit, it was just a 
>> whitespace
>> (style) change by me.  So taking the search one step further
>> (afd37a98^ is the parent commit of afd37a98)
>> 
>> software@raven> git blame afd37a98^ src/plbuf.c |grep plP_eop
>> 1e402417 (Phil Rosenberg 2015-02-27 17:12:03 + 1218) plP_eop();
>> 
>> and if you look up 1e402417 using git log the first line of the
>> commit message is
>> 
>> Fixed bug in rdbuf_di.
>> 
>> So that is a serious (non-style) commit, and Phil is the one to
>> ask about your possible solutions for this bug.
>> 
>> So I have put this on the list and also added Phil to the recipients.
>> 
>> @Phil: I have no objections to your pushing a simple, well-tested fix for
>> this bug, but if the fix is complicated or you don't have time to
>> thoroughly test it, you should probably wait until post-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); 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
>> __
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
--

[Plplot-devel] Release status: need help with OLD_WXWIDGETS=ON option

[Alan W. Irwin]

Hi Phil:

I have implemented the OLD_WXWIDGETS option as of
commit bae1161, but there is one remaining issue
with it that I need your help to fix.

The old wxwidgets device driver appears to work as well as ever for
the -DOLD_WXWIDGETS=ON case, but if you build the
wxwidgets and wxPLplotDemo targets then attempt to
run

examples/c++/wxPLplotDemo

you gets lots of run-time error messages such as

plmkstrm: Cannot create new stream
plsstrm: Illegal stream number -1, must be in [0, 100]
plsstrm: Illegal stream number -1, must be in [0, 100]
plsstrm: Illegal stream number -1, must be in [0, 100]
plsstrm: Illegal stream number -1, must be in [0, 100]


If I change to the old version of wxwidgets before you introduced your
changes, i.e.,

git checkout 924b06ccffee1f

the above test works fine.  So apparently there are backwards
incompatible changes in C++ support for streams in the master
tip which the old wxwidgets code, i.e.,

./bindings/wxwidgets/deprecated_wxPLplotwindow.cpp
./bindings/wxwidgets/deprecated_wxPLplotstream.h.in
./bindings/wxwidgets/deprecated_wxPLplotwindow.h
./bindings/wxwidgets/deprecated_wxPLplotstream.cpp
./drivers/deprecated_wxwidgets_app.cpp
./drivers/deprecated_wxwidgets_dc.cpp
./drivers/deprecated_wxwidgets.cpp
./drivers/deprecated_wxwidgets_gc.cpp
./drivers/deprecated_wxwidgets_agg.cpp
./drivers/deprecated_wxwidgets.h
./examples/c++/deprecated_wxPLplotDemo.cpp

is not compatible with.  For example, I noticed a call to sdevdata in
bindings/wxwidgets/wxPLplotstream.cpp that is not in
bindings/deprecated_wxwidgets/wxPLplotstream.cpp, but it turns out
putting that call in the deprecated version does not solve the issue
so that change cannot be the entire story with differences in C++
stream support for master tip.

As a matter of urgency (since getting OLD_WXWIDGETS=ON to work is
release critical) could you figure out what needs to be changed in the
above files to make them compatible with C++ stream support for master
tip?

Thanks in advance.

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: request for release notes on plbuf and plmeta/plrender changes

[Jim Dishaw]

Release notes:

An experimental plot metafile input function, plreadmetafile(), was implemented 
to provide an integrated read/write capability into the core of PLplot.  In 
conjunction, the plmeta driver has been updated to support a transition to a 
new format.  A key 
change is storing the raw string data used to represent text and plot symbols 
into the metafile instead of the rendered 
characters.  The new features are currently disabled in order to prevent 
breaking compatibility with the existing format.  

The plbuf.c file was cleaned up by removing code that was used to write 
temporary files.  The temporary file implementation
has been deprecated for almost five years and was in an unmaintained state.  
This improved the readability of the code.  Performance enhancements were also 
made to plbuf to improve performance:  First, the rd_data_no_copy() internal 
function was implemented to avoid needless memory allocation and copying in 
plbuf.c; and, second, a two-byte alignment is maintained in the plot buffer as 
most architectures have better memory access performance with an even byte 
alignment.  An experimental plot buffer import was implemented as a PLESC 
operation to support wxwidget development.  The plot state save at the
beginning of plot (BOP) was improved in order to fix rendering artifacts when 
plots were resized. In addition, the text handling
operations in the buffer have been improved; however, the cairo driver does not 
correctly handle resizes correctly and it
uses an alternate text processing method that is currently disabled in the plot 
buffer.  A bug in pattern fills was corrected and
the plot buffer now will only contain the PLSTATE_FILL operation rather than 
both PLSTATE_FILL and the individual LINE commands of the fill.  This was 
causing a line doubling effect when plots were resized.

On Mar 14, 2015, at 12:15 PM, Alan W. Irwin  wrote:

> Hi Jim:
> 
> I am about to start working on the release notes (README.release) which 
> currently
> are quite out of date.  I plan to say something like many bugs were
> fixed (notably for plbuf), but if there is more to say than that about
> your plbuf changes, please send me a paragraph describing those changes.
> 
> I also need a paragraph from you describing where we are now with
> plmeta/plrender compared to previously. And also one or two sentences
> about your future plans for plmeta/plrender would be appropriate. Note
> I will likely edit your notes afterward to emphasize that we have
> transitioned from an unmaintained state with PLD_plmeta OFF to an
> experimental state (still with PLD_plmeta OFF) if you don't make that
> point yourself.
> 
> 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
> __


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: Jim's release-related topics

[Alan W. Irwin]

Hi Jim:

I finally pushed your DocBook patch (commit id 2ff8d66) which validated
and built nicely.  Thanks for that!

I think that is the next-to-last release-related topic between us.  So
I believe that the only topic left between us that is release related
is my request earlier today concerning plbuf and plmeta/plrender
release notes from you.

If there is any other release-related topic between us that I have
forgotten, 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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: Java, D, Python warnings generated by doxygen parser

[Alan W. Irwin]

Hi Andrew:

If I configure PLplot with -DBUILD_DOX_DOC=ON and run

make build_doxygen

the following warnings are generated.

[...]
/home/software/plplot/HEAD/plplot.git/bindings/java/PLCallbackCT.java:5: 
warning: Internal inconsistency: scope for class plplot::core::PLCallbackCT not 
found!
/home/software/plplot/HEAD/plplot.git/bindings/java/PLCallbackLabel.java:5: 
warning: Internal inconsistency: scope for class plplot::core::PLCallbackLabel 
not found!
/home/software/plplot/HEAD/plplot.git/bindings/java/PLCallbackMapform.java:5: 
warning: Internal inconsistency: scope for class 
plplot::core::PLCallbackMapform not found!
/home/software/plplot/HEAD/plplot.git/bindings/java/PLStream.java:32: warning: 
Internal inconsistency: scope for class plplot::core::PLStream not found!
/home/software/plplot/HEAD/build_dir/bindings/java/config.java:23: warning: 
Internal inconsistency: scope for class plplot::core::config not found!
/home/software/plplot/HEAD/build_dir/bindings/java/PLGraphicsIn.java:11: 
warning: Internal inconsistency: scope for class plplot::core::PLGraphicsIn not 
found!
/home/software/plplot/HEAD/build_dir/bindings/java/plplotjavac.java:11: 
warning: Internal inconsistency: scope for class plplot::core::plplotjavac not 
found!
/home/software/plplot/HEAD/build_dir/bindings/java/plplotjavacConstants.java:11:
 warning: Internal inconsistency: scope for class 
plplot::core::plplotjavacConstants not found!
/home/software/plplot/HEAD/build_dir/bindings/java/plplotjavacJNI.java:11: 
warning: Internal inconsistency: scope for class plplot::core::plplotjavacJNI 
not found!
[...]
Searching for member function documentation...
/home/software/plplot/HEAD/plplot.git/bindings/d/plplot.d:18: warning: no 
matching class member found for
   alias void plplot::function(PLINT, PLFLT *, PLFLT *)

/home/software/plplot/HEAD/plplot.git/bindings/d/plplot.d:19: warning: no 
matching class member found for
   alias void plplot::function(PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer)
[...]
/home/software/plplot/HEAD/plplot.git/bindings/python/Plframe.py:476: warning: 
Unsupported xml/html tag  found
/home/software/plplot/HEAD/plplot.git/bindings/python/Plframe.py:455: warning: 
Unsupported xml/html tag  found

It has been a long time, but I don't recall such warnings for the last
release.  I thought I should let you know about these warnings even
though it is probably best at this late stage to wait until post-release
to deal with them.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: request for release notes concerning wxwidgets changes

[Alan W. Irwin]

Hi Phil:

Please add a paragraph to the release notes (README.release)
concerning your wxwidgets changes.  If you don't do it yourself, I
plan to add to that description that the old version of wxwidgets is
available as an alternative if the user specifies the
-DOLD_WXWIDGETS=ON option.  (I plan to actually implement that option
today as we discussed some time ago.)

Also, drivers/README.wxwidgets is grossly out of date so I
hope you have time to fix that as well.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: request for release notes on plbuf and plmeta/plrender changes

[Alan W. Irwin]

Hi Jim:

I am about to start working on the release notes (README.release) which 
currently
are quite out of date.  I plan to say something like many bugs were
fixed (notably for plbuf), but if there is more to say than that about
your plbuf changes, please send me a paragraph describing those changes.

I also need a paragraph from you describing where we are now with
plmeta/plrender compared to previously. And also one or two sentences
about your future plans for plmeta/plrender would be appropriate. Note
I will likely edit your notes afterward to emphasize that we have
transitioned from an unmaintained state with PLD_plmeta OFF to an
experimental state (still with PLD_plmeta OFF) if you don't make that
point yourself.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: epa_build: pango/cairo build issues

[Andrew Ross]

On Fri, Mar 13, 2015 at 12:23:56PM -0700, Alan Irwin wrote:
> On 2015-03-13 10:26-0700 Alan W. Irwin wrote:
> >On 2015-03-13 10:19- Andrew Ross wrote:
> >>1) The cairo build fails (seems to be due to a bug in cairo build scripts
> >>exposed in gcc-4.9.0 - see http://sourceforge.net/p/mingw-w64/bugs/396/)
> 
> Hi Andrew:
> 
> That thread implies the problem is caused by the build scripts for
> GTK+ which apparently use the -flto link time option that is described
> at .
> However, there is no mention of "flto" in the epa_build tree so unless
> -flto is on by default with gcc-4.9.0, the source of the issue with
> epa_build of GTK+ (or the pango/cairo subset of that) must be
> something else.  Also note that gcc-4.7.2 knows nothing about the
> -flto option so if the solution is turning off that option for gcc-4.9.x
> that can only be done for that version of gcc.
> 
> In sum, dealing with this epa_build issue for pango/cairo is likely
> not going to be a simple fix so we should look at this again
> post-release.

I agree. Since the epa_build is not core to plplot I don't see this as a
release issue. For reference Debian unstable has gcc-4.9.2. It might be 
interesting to look at the Debian build for the packages / any Debian
specific patches for clues to this issue.

Andrew

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: epa_build: libharu and general release topics

[Andrew Ross]

On Fri, Mar 13, 2015 at 05:19:02PM -0700, Alan Irwin wrote:
> On 2015-03-13 10:26-0700 Alan W. Irwin wrote:
> >On 2015-03-13 10:19- Andrew Ross wrote:
> >>2) The libharu build succeeds, but the hpdf_pdfa.h include file is not
> >>installed so the plplot build of the pdf driver fails.
> 
> Hi Andrew:
> 
> As of commit fac174e I have changed the CMake-based libharu build
> system to install both hpdf_namedict.h and hpdf_pdfa.h because both
> those headers are installed by the autotools-based libharu build
> system. As far as I can tell, my own epa_build should have complained
> about missing hpdf_pdfa.h, but for some unknown reason it didn't.  But
> in any case, thanks for reporting this issue which has now been fixed.
> 
> I also took this opportunity to search the -dev pdf results for
> rendering issues, and I have documented everything I spotted at
> .  I think all of these I
> have seen before so I conclude they are not due to any recent changes.
> In agreement with that conclusion, note that most devices do not share
> these rendering issues so they cannot be due to recent plbuf changes
> (which typically clobber every device result).  So this comprehensive
> check of the rendering for all our examples has been most reassuring
> from the release quality perspective.

Thanks Alan. I suspect you also had the Debian packages installed? The
header would be picked up from there, even if you were linking against
the epa_build version. Providing the versions weren't too out of sync
it wouldn't be problematic and there would be no way of telling. This
is one advantage of the pbuilder approach. Each time you start with
a pristine base install and only install additional packages which
are explicitly requested.

> @ Andrew: I think this concludes all release topics that we have discussed
> previously, but if there is anything else we have discussed that I
> have forgotten or you notice any new release-related topic, please let
> me know.

I agree. There is the outstanding octave segfault which occurs with one
of the p?? examples when run explicitly, but not with the test scripts.
This is odd, but probably not release critical. I may still get chance
to track this down, but debugging such issues with octave is tricky
since you can't easily use gdb. I can't see what the difference is
between the two cases, but this at least provides a starting point.

Otherwise it is the documented issues with the various drivers, but 
these are longstanding in most cases. A good goal for the next release
cycle would be to try and squash as many of these as we can to get
more uniform behaviour between all (or at least our main) drivers.
 
Andrew

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: epa_build: libharu and general release topics

[Alan W. Irwin]

On 2015-03-13 10:26-0700 Alan W. Irwin wrote:
> On 2015-03-13 10:19- Andrew Ross wrote:
>> 2) The libharu build succeeds, but the hpdf_pdfa.h include file is not
>> installed so the plplot build of the pdf driver fails.

Hi Andrew:

As of commit fac174e I have changed the CMake-based libharu build
system to install both hpdf_namedict.h and hpdf_pdfa.h because both
those headers are installed by the autotools-based libharu build
system. As far as I can tell, my own epa_build should have complained
about missing hpdf_pdfa.h, but for some unknown reason it didn't.  But
in any case, thanks for reporting this issue which has now been fixed.

I also took this opportunity to search the -dev pdf results for
rendering issues, and I have documented everything I spotted at
.  I think all of these I
have seen before so I conclude they are not due to any recent changes.
In agreement with that conclusion, note that most devices do not share
these rendering issues so they cannot be due to recent plbuf changes
(which typically clobber every device result).  So this comprehensive
check of the rendering for all our examples has been most reassuring
from the release quality perspective.

@ Andrew: I think this concludes all release topics that we have discussed
previously, but if there is anything else we have discussed that I
have forgotten or you notice any new release-related topic, please let
me know.

@ Arjen: If there is anything else release-rated we have discussed that I have
forgotten or you notice any new release-related topic, please let me
know.

@ Phil and Jim: There are still some on-going release-related topics
being discussed between us.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: epa_build: pango/cairo build issues

[Alan W. Irwin]

On 2015-03-13 10:26-0700 Alan W. Irwin wrote:
> On 2015-03-13 10:19- Andrew Ross wrote:
>> 1) The cairo build fails (seems to be due to a bug in cairo build scripts
>> exposed in gcc-4.9.0 - see http://sourceforge.net/p/mingw-w64/bugs/396/)

Hi Andrew:

That thread implies the problem is caused by the build scripts for
GTK+ which apparently use the -flto link time option that is described
at .
However, there is no mention of "flto" in the epa_build tree so unless
-flto is on by default with gcc-4.9.0, the source of the issue with
epa_build of GTK+ (or the pango/cairo subset of that) must be
something else.  Also note that gcc-4.7.2 knows nothing about the
-flto option so if the solution is turning off that option for gcc-4.9.x
that can only be done for that version of gcc.

In sum, dealing with this epa_build issue for pango/cairo is likely
not going to be a simple fix so we should look at this again
post-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); 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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

[Jim Dishaw]

> On Mar 13, 2015, at 2:34 PM, Phil Rosenberg  wrote:
> 
> Hi Jim Alan
> Firstly I'm not in front of a pc right now so I'm doing function names from 
> memory. Apologies if they are wrong.
> 
> Are you talking about the call to plP_eop() that is in the plreplot() 
> function?
> 
> If so, I put that there. The reason is that when creating the first page from 
> a buffer,   we need to do the bop actions, however due to the plinit call the 
> status is already set to bop, so the call to plP_bop does nothing. The state 
> #define values are not exposed to plbuf.c so the appropriate action appeared 
> to be to end the existing page.
> It might be that changes to device initialization mean this is no longer 
> necessary, but I don't know without testing. I'm not sure why it would cause 
> the behaviour you describe though. Which device were they in?
> 

The plP_eop() call, for some reason, results in extra keypresses needed to 
advance to the next page. I thought I knew the reason, but after examining the 
code, my initial hypothesis doesn't look correct. I will step through the code 
to see what is causing the issue. 

> Phil
> From: Alan W. Irwin
> Sent: ‎13/‎03/‎2015 17:59
> To: Phil Rosenberg; Jim Dishaw
> Cc: PLplot development list
> Subject: Release status: fix for plbuf resizing issue
> 
> On 2015-03-13 11:10-0400 Jim Dishaw wrote:
> 
> > Alan,
> >
> 
> > I noticed a bug that occurs when resizing a plot.  Every time a plot
> is resized, an extra key press is required to advance the page.  The
> problem appears to be a pop_eop() that was added in plRemakePlot()
> during one of your fixes (afd73a98).  If I comment that line out, the
> bug goes way.  There should already be an EOP (or at least in most
> cases) at the end of the buffer because Does calling plP_eop()
> internally cause problems if the application was not expecting it? 
> I've run through all the examples without the plP_eop() call and
> cannot detect a problem.  Example 17 had no issues and that does not
> have an EOP.
> 
> >
> > If the plP_eop() is required, I propose two solutions:
> >
> > 1) Check for an EOP before putting another one.
> > 2) Do not replay the plot buffer unless there is an EOP (which would 
> > prevent redraws until an EOP and break example 17).
> >
> 
> Hi Jim:
> 
> I verify that bug here (using examples/c/x01c -dev xwin).
> 
> However, you have to dig deeper to find out who to blame.  In other
> words, "It wasn't me".  :-)
> 
> Here is the git magic you need.
> 
> software@raven> git blame src/plbuf.c |grep plP_eop
> afd37a98 (Alan W. Irwin  2015-03-11 02:33:40 -0700 1222) plP_eop();
> 
> So far so good, but if you use git log to look up that commit, it was just a 
> whitespace
> (style) change by me.  So taking the search one step further
> (afd37a98^ is the parent commit of afd37a98)
> 
> software@raven> git blame afd37a98^ src/plbuf.c |grep plP_eop
> 1e402417 (Phil Rosenberg 2015-02-27 17:12:03 + 1218) plP_eop();
> 
> and if you look up 1e402417 using git log the first line of the
> commit message is
> 
> Fixed bug in rdbuf_di.
> 
> So that is a serious (non-style) commit, and Phil is the one to
> ask about your possible solutions for this bug.
> 
> So I have put this on the list and also added Phil to the recipients.
> 
> @Phil: I have no objections to your pushing a simple, well-tested fix for
> this bug, but if the fix is complicated or you don't have time to
> thoroughly test it, you should probably wait until post-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); 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
> __
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

[Phil Rosenberg]

Hi Jim Alan
Firstly I'm not in front of a pc right now so I'm doing function names from 
memory. Apologies if they are wrong.

Are you talking about the call to plP_eop() that is in the plreplot() function?

If so, I put that there. The reason is that when creating the first page from a 
buffer,   we need to do the bop actions, however due to the plinit call the 
status is already set to bop, so the call to plP_bop does nothing. The state 
#define values are not exposed to plbuf.c so the appropriate action appeared to 
be to end the existing page.
It might be that changes to device initialization mean this is no longer 
necessary, but I don't know without testing. I'm not sure why it would cause 
the behaviour you describe though. Which device were they in?

Phil

-Original Message-
From: "Alan W. Irwin" 
Sent: ‎13/‎03/‎2015 17:59
To: "Phil Rosenberg" ; "Jim Dishaw" 
Cc: "PLplot development list" 
Subject: Release status: fix for plbuf resizing issue

On 2015-03-13 11:10-0400 Jim Dishaw wrote:

> Alan,
>

> I noticed a bug that occurs when resizing a plot.  Every time a plot
is resized, an extra key press is required to advance the page.  The
problem appears to be a pop_eop() that was added in plRemakePlot()
during one of your fixes (afd73a98).  If I comment that line out, the
bug goes way.  There should already be an EOP (or at least in most
cases) at the end of the buffer because Does calling plP_eop()
internally cause problems if the application was not expecting it? 
I've run through all the examples without the plP_eop() call and
cannot detect a problem.  Example 17 had no issues and that does not
have an EOP.

>
> If the plP_eop() is required, I propose two solutions:
>
> 1) Check for an EOP before putting another one.
> 2) Do not replay the plot buffer unless there is an EOP (which would prevent 
> redraws until an EOP and break example 17).
>

Hi Jim:

I verify that bug here (using examples/c/x01c -dev xwin).

However, you have to dig deeper to find out who to blame.  In other
words, "It wasn't me".  :-)

Here is the git magic you need.

software@raven> git blame src/plbuf.c |grep plP_eop
afd37a98 (Alan W. Irwin  2015-03-11 02:33:40 -0700 1222) plP_eop();

So far so good, but if you use git log to look up that commit, it was just a 
whitespace
(style) change by me.  So taking the search one step further
(afd37a98^ is the parent commit of afd37a98)

software@raven> git blame afd37a98^ src/plbuf.c |grep plP_eop
1e402417 (Phil Rosenberg 2015-02-27 17:12:03 + 1218) plP_eop();

and if you look up 1e402417 using git log the first line of the
commit message is

Fixed bug in rdbuf_di.

So that is a serious (non-style) commit, and Phil is the one to
ask about your possible solutions for this bug.

So I have put this on the list and also added Phil to the recipients.

@Phil: I have no objections to your pushing a simple, well-tested fix for
this bug, but if the fix is complicated or you don't have time to
thoroughly test it, you should probably wait until post-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); 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
__
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: fix for plbuf resizing issue

[Alan W. Irwin]

On 2015-03-13 10:59-0700 Alan W. Irwin wrote:

> On 2015-03-13 11:10-0400 Jim Dishaw wrote:
>
>> Alan,
>>
>
>> I noticed a bug that occurs when resizing a plot.  Every time a plot
> is resized, an extra key press is required to advance the page.  The
> problem appears to be a pop_eop() that was added in plRemakePlot()
> during one of your fixes (afd73a98).  If I comment that line out, the
> bug goes way.  There should already be an EOP (or at least in most
> cases) at the end of the buffer because Does calling plP_eop()
> internally cause problems if the application was not expecting it?
> I've run through all the examples without the plP_eop() call and
> cannot detect a problem.  Example 17 had no issues and that does not
> have an EOP.
>
>>
>> If the plP_eop() is required, I propose two solutions:
>>
>> 1) Check for an EOP before putting another one.
>> 2) Do not replay the plot buffer unless there is an EOP (which would prevent 
>> redraws until an EOP and break example 17).
>>
>
> Hi Jim:
>
> I verify that bug here (using examples/c/x01c -dev xwin).
>
> However, you have to dig deeper to find out who to blame.  In other
> words, "It wasn't me".  :-)
>
> Here is the git magic you need.
>
> software@raven> git blame src/plbuf.c |grep plP_eop
> afd37a98 (Alan W. Irwin  2015-03-11 02:33:40 -0700 1222) plP_eop();
>
> So far so good, but if you use git log to look up that commit, it was just a 
> whitespace
> (style) change by me.  So taking the search one step further
> (afd37a98^ is the parent commit of afd37a98)
>
> software@raven> git blame afd37a98^ src/plbuf.c |grep plP_eop
> 1e402417 (Phil Rosenberg 2015-02-27 17:12:03 + 1218) plP_eop();
>
> and if you look up 1e402417 using git log the first line of the
> commit message is
>
> Fixed bug in rdbuf_di.
>
> So that is a serious (non-style) commit, and Phil is the one to
> ask about your possible solutions for this bug.
>
> So I have put this on the list and also added Phil to the recipients.
>
> @Phil: I have no objections to your pushing a simple, well-tested fix for
> this bug, but if the fix is complicated or you don't have time to
> thoroughly test it, you should probably wait until post-release.

Oops.  It just sunk in that this is a plbuf change where we have at
least one example (example 2.02) where there were unintended
wide-spread consequences of a plbuf change for all devices.  And also
some plbuf change and a subsequent fix for that was the likely cause
of the on-again/off-again -dev tk zoom issue. So my advice is to hold
off on this fix until post-release so we have a full release cycle to
test it.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: fix for plbuf resizing issue

[Alan W. Irwin]

On 2015-03-13 11:10-0400 Jim Dishaw wrote:

> Alan,
>

> I noticed a bug that occurs when resizing a plot.  Every time a plot
is resized, an extra key press is required to advance the page.  The
problem appears to be a pop_eop() that was added in plRemakePlot()
during one of your fixes (afd73a98).  If I comment that line out, the
bug goes way.  There should already be an EOP (or at least in most
cases) at the end of the buffer because Does calling plP_eop()
internally cause problems if the application was not expecting it? 
I've run through all the examples without the plP_eop() call and
cannot detect a problem.  Example 17 had no issues and that does not
have an EOP.

>
> If the plP_eop() is required, I propose two solutions:
>
> 1) Check for an EOP before putting another one.
> 2) Do not replay the plot buffer unless there is an EOP (which would prevent 
> redraws until an EOP and break example 17).
>

Hi Jim:

I verify that bug here (using examples/c/x01c -dev xwin).

However, you have to dig deeper to find out who to blame.  In other
words, "It wasn't me".  :-)

Here is the git magic you need.

software@raven> git blame src/plbuf.c |grep plP_eop
afd37a98 (Alan W. Irwin  2015-03-11 02:33:40 -0700 1222) plP_eop();

So far so good, but if you use git log to look up that commit, it was just a 
whitespace
(style) change by me.  So taking the search one step further
(afd37a98^ is the parent commit of afd37a98)

software@raven> git blame afd37a98^ src/plbuf.c |grep plP_eop
1e402417 (Phil Rosenberg 2015-02-27 17:12:03 + 1218) plP_eop();

and if you look up 1e402417 using git log the first line of the
commit message is

Fixed bug in rdbuf_di.

So that is a serious (non-style) commit, and Phil is the one to
ask about your possible solutions for this bug.

So I have put this on the list and also added Phil to the recipients.

@Phil: I have no objections to your pushing a simple, well-tested fix for
this bug, but if the fix is complicated or you don't have time to
thoroughly test it, you should probably wait until post-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); 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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmeta/plrender

[Jim Dishaw]

On Mar 12, 2015, at 3:38 PM, "Alan W. Irwin"  wrote:

> Hi Jim:
> 
> Here are the results of a simple test I tried with -DPLD_plmeta=ON
> 
> # Build what is relevant
> make plrender
> make plmeta
> make x01c
> make ps
> 
> # Test
> examples/c/x01c -dev psc -o test1.psc
> examples/c/x01c -dev plmeta -o test.plmeta
> utils/plrender test.plmeta -dev psc -o test2.psc
> 
> There were no build issues and no run time issues.  However, test1.psc
> was quite different (text size, etc.,) from test2.psc, and I was under
> the impression that the effect of all your recent plmeta/plrender
> changes was those two files should be identical (modulo the
> possibility of some small rounding errors).
> 

I left plrender to behave like it did before my changes in order not to cause 
any issues if it was being used.  I did not feel the code I had written was 
ready for the release.

> This issue is not release critical (since -DPLD_plmeta=OFF by
> default), and I definitely don't plan to push any further
> plmeta/plrender changes prior to the release (deep freeze and all
> that) nor try -DPLD_plmeta=ON again until post-release.  However, I
> did notice this issue so I thought I should bring it to your
> attention, and I encourage you to follow up immediately on a topic
> branch with the goal of pushing the plmeta/plrender fix for this issue
> soon after the release.
> 

I am planning to pick it up after release.


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmeta/plrender

[Jim Dishaw]

> On Mar 12, 2015, at 6:08 PM, Alan W. Irwin  wrote:
> 
> Hi Jim:
> 
> Could you clarify the purpose of the -mfi and -mfo options
> and the plreadmetafile routine?
> 

-mfi sets the file name that plreadmetafile will use if one is not otherwise 
specified by the caller. Nothing will happen unless there is a plreadmetafile() 
call in the program. 

-mfo option is a placeholder at this point. What it will do is save all the 
plots to a metafile simultaneous with the output device. I have not decided 
what to do if plmeta is selected. 

> It appears the options simply set metafile input and output file names without
> doing anything else contrary to their self documentation in src/plargs.c
> of "Read the specified PLplot metafile" and "Write the plot to the
> specified PLplot metafile".
> 
> The only potential actual use of mf_infile I can find within the
> source tree is in plreadmetafile.  That function appears to do
> something similar to plrender, and it is only used in
> examples/c/test_plbuf.c with an explicit name rather than NULL so the
> result is mf_infile is just a placeholder (i.e., never actually used
> in our current source tree).

I set a name in test_plbuf just to make it easier during testing. I set it up 
to support both ways because both ways are useful. Right now the metafile is 
rendered with a plreadmetafile() call. I experimented with different 
approaches, but settled on triggering the rendering with a function call. This 
merits further discussion after release. 

> 
> By the way, if my interpretation of the purpose of plreadmetafile is
> correct, can plrender simply call plreadmetafile (with an explicit
> name for the plmeta file as read from the command line) to allow
> removal of a lot of (redundant) code from plrender?

Absolutely. After release I'm going to remove all the parsing code. I'm also 
going to add the capability to read from shared memory and over the network. 

> 
> I can also find no actual use of mf_outfile anywhere in the source
> tree.  So this appears to be a placeholder as well.

Yep, it will be the "tee" command in Unix. 

> 
> Since we are in deep freeze now, we should leave these placeholders in
> place for this release and not mess with plrender, but post-release
> (or on a topic branch now), you should remove these options or
> actually use them for something (with better documentation strings
> such as "Set an input plmetafile name" and "Set an output plmetafile
> name"), and you might also wish to call plreadmetafile from plrender
> (if my above interpretation of the purpose of plreadmetafile is
> correct).
> 
> 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
> __

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status: plmeta/plrender

[Alan W. Irwin]

Hi Jim:

Could you clarify the purpose of the -mfi and -mfo options
and the plreadmetafile routine?

It appears the options simply set metafile input and output file names without
doing anything else contrary to their self documentation in src/plargs.c
of "Read the specified PLplot metafile" and "Write the plot to the
specified PLplot metafile".

The only potential actual use of mf_infile I can find within the
source tree is in plreadmetafile.  That function appears to do
something similar to plrender, and it is only used in
examples/c/test_plbuf.c with an explicit name rather than NULL so the
result is mf_infile is just a placeholder (i.e., never actually used
in our current source tree).

By the way, if my interpretation of the purpose of plreadmetafile is
correct, can plrender simply call plreadmetafile (with an explicit
name for the plmeta file as read from the command line) to allow
removal of a lot of (redundant) code from plrender?

I can also find no actual use of mf_outfile anywhere in the source
tree.  So this appears to be a placeholder as well.

Since we are in deep freeze now, we should leave these placeholders in
place for this release and not mess with plrender, but post-release
(or on a topic branch now), you should remove these options or
actually use them for something (with better documentation strings
such as "Set an input plmetafile name" and "Set an output plmetafile
name"), and you might also wish to call plreadmetafile from plrender
(if my above interpretation of the purpose of plreadmetafile is
correct).

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: exposing plhrsh

[Alan W. Irwin]

On 2015-03-12 11:13-0700 Alan W. Irwin wrote:

> @Phil, Jim:
>
> The recent exposure of plhrsh is not complete and has visibility
> issues for the shared library case.  In all cases where a private
> function like this needs to be exposed, you need a declaration in
> include/plplotP.h using the PLDLLIMPEXP macro.  Please fix.

Never mind, I have dealt with this already (commit bcca4ae).  It turned
out that the PLDLLIMPEXP macro should not be used in this case
(since plhrsh should only be used within the plplot library and not
be some external application, library, or dll) so this change was
only a stylistic one (plhrsh declared only in one place to make sure
it is a consistent declaration).

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: plmetafile.c and plbuf.c compiler warnings

[Alan W. Irwin]

To Phil:

gcc is generating these warnings when building libplplot.  Would you
please take a look to see whether this is either a real uninitialized issue
that needs to be fixed or a false alarm?

/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
‘read_header’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:336:8: warning: ‘pdf_rc’ 
may be used uninitialized in this function [-Wuninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:301:9: note: ‘pdf_rc’ 
was declared here
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c: In function 
‘plreadmetafile’:
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:373:23: warning: ‘plm’ 
may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/software/plplot/HEAD/plplot.git/src/plmetafile.c:1112:14: note: ‘plm’ was 
declared here
[]
/home/software/plplot/HEAD/plplot.git/src/plbuf.c: In function ‘rdbuf_bop’:
/home/software/plplot/HEAD/plplot.git/src/plbuf.c:1309:11: warning: ‘cmd’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
/home/software/plplot/HEAD/plplot.git/src/plbuf.c:593:19: note: ‘cmd’ was 
declared here

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release status: plmeta/plrender

[Alan W. Irwin]

Hi Jim:

Here are the results of a simple test I tried with -DPLD_plmeta=ON

# Build what is relevant
make plrender
make plmeta
make x01c
make ps

# Test
examples/c/x01c -dev psc -o test1.psc
examples/c/x01c -dev plmeta -o test.plmeta
utils/plrender test.plmeta -dev psc -o test2.psc

There were no build issues and no run time issues.  However, test1.psc
was quite different (text size, etc.,) from test2.psc, and I was under
the impression that the effect of all your recent plmeta/plrender
changes was those two files should be identical (modulo the
possibility of some small rounding errors).

This issue is not release critical (since -DPLD_plmeta=OFF by
default), and I definitely don't plan to push any further
plmeta/plrender changes prior to the release (deep freeze and all
that) nor try -DPLD_plmeta=ON again until post-release.  However, I
did notice this issue so I thought I should bring it to your
attention, and I encourage you to follow up immediately on a topic
branch with the goal of pushing the plmeta/plrender fix for this issue
soon after 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); 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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Jim Dishaw]

On Mar 12, 2015, at 2:13 PM, "Alan W. Irwin"  wrote:

> On 2015-03-11 14:49-0700 Alan W. Irwin wrote:
> 
>> Hi Phil:
>> 
>> I just saw your one-line fix at
>> .
>> 
>> Does that really do the job?  For example, I noticed earlier in that code
>> a test of pls->device rather than pls->dev, but I am just looking at
>> patterns with no deep understanding of what is going on.
>> 
> 
> Hi Phil:
> 
> I haven't seen a response to the above question.
> 
> @Phil, Jim:
> 
> The recent exposure of plhrsh is not complete and has visibility
> issues for the shared library case.  In all cases where a private
> function like this needs to be exposed, you need a declaration in
> include/plplotP.h using the PLDLLIMPEXP macro.  Please fix.
> 

I defer to Phil because I would send the patch to him anyway.


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Alan W. Irwin]

On 2015-03-11 14:49-0700 Alan W. Irwin wrote:

> Hi Phil:
>
> I just saw your one-line fix at
> .
>
> Does that really do the job?  For example, I noticed earlier in that code
> a test of pls->device rather than pls->dev, but I am just looking at
> patterns with no deep understanding of what is going on.
>

Hi Phil:

I haven't seen a response to the above question.

@Phil, Jim:

The recent exposure of plhrsh is not complete and has visibility
issues for the shared library case.  In all cases where a private
function like this needs to be exposed, you need a declaration in
include/plplotP.h using the PLDLLIMPEXP macro.  Please fix.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Jim Dishaw]

> On Mar 12, 2015, at 7:06 AM, Phil Rosenberg  wrote:
> 
> This thread is becoming a bit unwieldy, but I will try to answer below
> 
> @Jim
> I had already written and tested a fix for the hatchings and have just
> committed it, sorry if you spent time on this.

No problem. It was only a 5 minute fix. 

> Regarding the plhrsh issue, my build is fine  - although it is a
> static build, so perhaps that is the difference. However I couldn't
> see any reference to plhersh in plmeta.c. I will commit your change
> though as exposing it should not affect anything else.
> 

It is in src/plmetafile.c not plmeta.c. 

> 
>> On 12 March 2015 at 04:03, Jim Dishaw  wrote:
>> I made a fix for double line fill bug.  Please see attached file
>> 
>> 
>> 
>> 
>> I noticed a different bug.  If you don't resize a plot, pressing enter 
>> advances to the next page.  After resizing a plot, it takes more than one 
>> key press to advance.  I'm not sure the cause, my suspicion is that there 
>> are some additional commands (perhaps EOPs) creeping in at the end of the 
>> plot buffer.  I will investigate further.
>> 
>> 
>>> On Mar 11, 2015, at 11:36 PM, Jim Dishaw  wrote:
>>> 
>>> 
 On Mar 11, 2015, at 4:59 PM, Phil Rosenberg  
 wrote:
 
 Hi Alan
 
 A quick bit of stepping through my code has confirmed my suspicion
 from below. In plfill_soft plP_draphy is called for each line of the
 pattern and these lines are saved in the buffer, so basically writing
 to buffer needs switching off in this function. the change is about 3
 lines of code, but I will save it for post release if you prefer.
>>> 
>>> That is essentially correct.  It appears that the issue is there is both a 
>>> PLESC_FILL in the buffer and then the lines that were generated by 
>>> plP_fill.  There should be only one and not both and the PLESC_FILL should 
>>> be the one to stay in the buffer.
>>> 
>>> The first solution that comes to my mind is to set plsc->plbuf_write = 0 
>>> after the plbuf_esc() call and restore the original value at the end of the 
>>> function.
>>> 
 Phil
 
> On 11 March 2015 at 18:31, Alan W. Irwin  
> wrote:
> On 2015-03-11 13:01- Phil Rosenberg wrote:
> 
>>> 
>>> * Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts
>>> of the pie chart, but the other slices are fine.
>> 
>> This isn't shown on Windows. Perhaps the cause is that both the lines
>> and the fill are being saved to the buffer meaning the lines get
>> rendered twice. This is just a guess though
>>> 
>>> 
>>> --
>>> Dive into the World of Parallel Programming The Go Parallel Website, 
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub for 
>>> all
>>> things parallel software development, from weekly thought leadership blogs 
>>> to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>> ___
>>> Plplot-devel mailing list
>>> Plplot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>> 
>> 

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Phil Rosenberg]

This thread is becoming a bit unwieldy, but I will try to answer below

@Jim
I had already written and tested a fix for the hatchings and have just
committed it, sorry if you spent time on this.
Regarding the plhrsh issue, my build is fine  - although it is a
static build, so perhaps that is the difference. However I couldn't
see any reference to plhersh in plmeta.c. I will commit your change
though as exposing it should not affect anything else.

@Alan, Andrew and Arjen
I followed the link you gave Andrew, then a link to a further page
http://wiki.tcl.tk/1831. The tests on this page give correct results
on my Centos machine, although it is of note that there is a post on
that page with someone reporting correct test result onCentos, but the
same issue. I will check my Ubuntu machine tonight, presumably there
is little point performing tests of x via ssh with x forwarding. My
tcl version is 8.6 on Ubuntu, but only 8.5 on Centos, so perhaps the
tcl version explains the Centos problems. Note my tests on Ubuntu have
all been via shh with x forwarding, maybe trying direct connection
would help.

Phil

On 12 March 2015 at 04:03, Jim Dishaw  wrote:
> I made a fix for double line fill bug.  Please see attached file
>
>
>
>
> I noticed a different bug.  If you don't resize a plot, pressing enter 
> advances to the next page.  After resizing a plot, it takes more than one key 
> press to advance.  I'm not sure the cause, my suspicion is that there are 
> some additional commands (perhaps EOPs) creeping in at the end of the plot 
> buffer.  I will investigate further.
>
>
> On Mar 11, 2015, at 11:36 PM, Jim Dishaw  wrote:
>
>>
>> On Mar 11, 2015, at 4:59 PM, Phil Rosenberg  wrote:
>>
>>> Hi Alan
>>>
>>> A quick bit of stepping through my code has confirmed my suspicion
>>> from below. In plfill_soft plP_draphy is called for each line of the
>>> pattern and these lines are saved in the buffer, so basically writing
>>> to buffer needs switching off in this function. the change is about 3
>>> lines of code, but I will save it for post release if you prefer.
>>>
>>
>> That is essentially correct.  It appears that the issue is there is both a 
>> PLESC_FILL in the buffer and then the lines that were generated by plP_fill. 
>>  There should be only one and not both and the PLESC_FILL should be the one 
>> to stay in the buffer.
>>
>> The first solution that comes to my mind is to set plsc->plbuf_write = 0 
>> after the plbuf_esc() call and restore the original value at the end of the 
>> function.
>>
>>> Phil
>>>
>>> On 11 March 2015 at 18:31, Alan W. Irwin  wrote:
 On 2015-03-11 13:01- Phil Rosenberg wrote:

>>
>> * Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts
>> of the pie chart, but the other slices are fine.
>
> This isn't shown on Windows. Perhaps the cause is that both the lines
> and the fill are being saved to the buffer meaning the lines get
> rendered twice. This is just a guess though

>>
>>
>> --
>> Dive into the World of Parallel Programming The Go Parallel Website, 
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for 
>> all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> ___
>> Plplot-devel mailing list
>> Plplot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Phil Rosenberg]

>
> * Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts
> of the pie chart, but the other slices are fine.
This isn't shown on Windows. Perhaps the cause is that both the lines
and the fill are being saved to the buffer meaning the lines get
rendered twice. This is just a guess though
>
> * Example 17 is extremely slow to display and the erases are not getting
> done when the plot is rescaled.  Attached mode?

I will add this to my to do list

>
> * Example 20 is extremely slow to display and does not have any
> interactive capability (the third page should allow you to select a
> region with the cursor).  Compare the cursor capability shown with
> this example for -dev xwin.
>
> Note -dev wxwidgets cursor capability is currently similar to
> that of -dev xcairo and -dev qtwidget.  All three devices print
> out cursor position results for example 1 with the -locate option,
> but all three devices fail to allow the user to select
> a region in example 3.03.  So all three have to be updated
> to have the same cursor capabilities as -dev xwin.
> In addition, I presume this capability would only work
> for the qtwidgets case in attached mode (see below).

Again I will add it to my list

>
> * Example 26.02 still has an issue with too large a legend for
> the Cyrillic version of the plot.
See my post to a different thread.
>
> * Example 28.04 has a strange colour change for certain ranges indicated
> below of the rendering of the
>
> "The future of our civilization depends on software freedom."
> ^^^

I don't see this on Windows wx3.0, Ubuntu wx3.0 or Centos wx3.0 so
you'll have to send me a screen shot.

>
> 3D string.  Those colour changes occur when the letters in the string
> are mostly reduced to the (expected) straight lines by the 3D affine
> transformation.  This may be due to some strange issue with my Debian
> stable wxwidgets software library and have nothing to do with PLplot.
> If you cannot reproduce those colour changes, I will send a screen
> shot.
>
> * Example 28.05 affine transformation issues.

Already known, but better than it was

>
> * Example 30.02 ugly looking gradient results are due to falling back
> to core software emulation of a linear gradient.  Instead, as
> discussed before a linear gradient based on the wxwidgets API should
> be used instead to get very nice results for this example (such as
> those from the cairo and qt devices).

Same as the old driver - I will add native gradient fill to my to do
list, but I would guess that shading with alpha is broken in general.
This is due to outlining as a workaround to the seaming problem for
solid colour shading. It will need some changes to the core code to
fix.

>
> * Example 34: the qtwidgets device does not support draw mode.
> However, if you want to implement this someday you should follow what
> is done for xcairo (which is the only device so far that has draw mode
> capability).

Again I'll add it to the list

>
> * To get proper interactive capability, must implement an
> attached driver option that does not launch a separate
> wxPLViewer instance.

This will not happen (well at least not from me). The whole point of
the changes was to detach the driver, because wxWidgets is not
designed to be attached.

>
> * There was also a the following warning being emitted by g++
>
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp: In
> function ‘void plD_init_wxwidgets(PLStream*)’:
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:186:23:
> warning: converting to non-pointer type ‘PLINT {aka int}’ from NULL
> [-Wconversion-null]
>
> Did you really want to set the device id (which is just an integer) to
> zero here?  If so, you should use 0 rather than NULL.  But I thought
> that device id integer was supposed to be fixed and unique to each
> device in which case it would generally not be a good idea to zero it.  But
> on
> the other hand, I so far have not detected any issues from this
> zeroing so I don't think there is any urgency here
> (i.e., you can deal with this post-release).

This is a bug, it was supposed to be pls->dev = NULL. This has
potential to cause segfaults as it leaves a dangling pointer if
initialisation fails. However I will leave this unless you say you are
happy for me to apply the appropriate fix.


Also you will have to let me know if you are still happy for me to
change the documentation.

Phil

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists

Re: [Plplot-devel] Release status

[Jim Dishaw]

I made a fix for double line fill bug.  Please see attached file



double-line-fill-fix.patch
Description: Binary data


I noticed a different bug.  If you don't resize a plot, pressing enter advances 
to the next page.  After resizing a plot, it takes more than one key press to 
advance.  I'm not sure the cause, my suspicion is that there are some 
additional commands (perhaps EOPs) creeping in at the end of the plot buffer.  
I will investigate further.

 
On Mar 11, 2015, at 11:36 PM, Jim Dishaw  wrote:

> 
> On Mar 11, 2015, at 4:59 PM, Phil Rosenberg  wrote:
> 
>> Hi Alan
>> 
>> A quick bit of stepping through my code has confirmed my suspicion
>> from below. In plfill_soft plP_draphy is called for each line of the
>> pattern and these lines are saved in the buffer, so basically writing
>> to buffer needs switching off in this function. the change is about 3
>> lines of code, but I will save it for post release if you prefer.
>> 
> 
> That is essentially correct.  It appears that the issue is there is both a 
> PLESC_FILL in the buffer and then the lines that were generated by plP_fill.  
> There should be only one and not both and the PLESC_FILL should be the one to 
> stay in the buffer.
> 
> The first solution that comes to my mind is to set plsc->plbuf_write = 0 
> after the plbuf_esc() call and restore the original value at the end of the 
> function. 
> 
>> Phil
>> 
>> On 11 March 2015 at 18:31, Alan W. Irwin  wrote:
>>> On 2015-03-11 13:01- Phil Rosenberg wrote:
>>> 
> 
> * Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts
> of the pie chart, but the other slices are fine.
 
 This isn't shown on Windows. Perhaps the cause is that both the lines
 and the fill are being saved to the buffer meaning the lines get
 rendered twice. This is just a guess though
>>> 
> 
> 
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Jim Dishaw]

On Mar 11, 2015, at 6:49 AM, "Alan W. Irwin"  wrote:

> On 2015-03-10 21:41- Phil Rosenberg wrote:
> 
>> Hi Alan and Jim
>> Right, well Jim's patch series is committed and I have just made one
>> more additional commit regarding the buffer which I think now gives us
>> a buffer which is (pretty close to, if not completely) bug free!!! Or
>> at the very least it is sufficient to allow the wxWidgets driver to
>> render as well as from direct commands.
> 
> Note, to everybody.  There is an official deep freeze notice near
> the end of this e-mail.
> 
> @ Andrew, Phil, and Jim:
> 
> Before getting to wxwidgets test results I regret to say that a recent
> plbuf change has nailed us again.  There is now a release showstopper
> where -dev tk produces really strange looking results.  I found this
> issue via checking -dev tk for the zoom regression where hitting the
> zoom button just produces a blank (black) plot.  I confirm that
> regression as well as a newly introduced regression for that device
> (two windows are displayed rather than one with one of them without a
> plot but with the plframe decorations and the other showing an
> xwin-like plot windows with no decorations). This new regression and
> the zoom regression are showstoppers for the current release so your
> confirmation and fix for these rendering regressions will be much
> appreciated.  You should also look carefully at -dev wingcc to see
> whether recent plbuf changes have introduced rendering regressions
> there as well (assuming you have looked in detail before at wingcc
> results for all examples, and therefore know what rendered nicely in
> the old days).
> 

I cannot replicate this problem.  I was able to zoom by pressing "z" and zoom 
out with "b" and nothing happened with "f".

> 
> @Everybody:
> 
> To make this decision official, this is notice from your release manager
> that we are now in deep freeze until release.  That is, only
> documentation changes and small and _very well tested_ fixes should be
> pushed to master during this deep freeze. In particular, because
> plbuf changes have such a wide impact, I ask everyone here to avoid
> commits to master that involve any plbuf changes at all during deep
> freeze unless such commit can be shown to fix a non-wxwidgets
> rendering regression caused by an earlier plbuf change in this release
> cycle.
> 
> Also, despite the extra effort we are going to need to deal with the
> rendering regressions, I do honestly want to thank both Phil and Jim
> for all their hard work on wxwidgets/plbuf that has finally gotten us
> to the point where we can declare a deep freeze.  That's a really
> important goal for late in a release cycle, and I am really glad we
> have finally achieved that goal!
> 
Attached is a patch series that reverses a change that Phil made to restore 
static to plhrsh.  I  recalled incorrectly on its use by plmetafile.c and it is 
needed to compile without error.  At this point there is no way around exposing 
plhrsh(). 

Sorry for the confusion.



fix-plhrsh-for-plmetafile.patch
Description: Binary data

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Alan W. Irwin]

On 2015-03-11 12:27-0700 Alan W. Irwin wrote:

> I will now do my own git bisects to find when the zoom issue was
> introduced and when the two-GUI issue was introduced.

My apologies, but it turns out the two-GUI issue was a false alarm.

The only explanation that seems reasonable is there must have been
some stale files hanging around in the build tree that caused this
issue because when I started with a fresh build of master tip as the first
step of git bisect, the issue was completely gone.  Furthermore,
the zoom issue was gone as well.  And I also get the same good results
(again starting with a fresh build) for commit afd37a9 (the one I used
for my series of wxwidgets tests).

I am virtually positive that unlike the two-GUI issue, the zoom issue
was not a false alarm because Andrew saw this zoom issue, and I
confirmed it as well several times using a fresh build, so I think
what happened there was one of the recent plbuf fixes prior to afd37a9
fixed it.  But I am not going to investigate further, and will happily
take this good master tip result!

So the current release status is we are still in deep freeze following
the rule of thumb I expressed to Phil (with the addition that all
documentation changes are still allowed), but master tip is
considerably higher quality than I thought with no known rendering
regressions.  Of course, there is still a lot of work to do to finish
this release, but I am happy with where we are at the moment.

So the only topic left in this subthread discussion that I am aware of
is the authorization issues discovered by Phil when attempting to
verify the (irreproducible) two-GUI issue, but I assume that is a
local platform issue for him that he will be able to straighten out.

@Phil:

On that topic, I have just noticed now that Debian has installable
packages for both Tcl/Tk 8.4 and 8.5 so I assume Ubuntu supplies those
as well. So if your cmake output shows cmake is finding Tcl/Tk 8.4,
that is probably the source of your authorization issue, and to solve
it you must install Tcl/Tk 8.5.  If that doesn't solve the issue, then
you should check what your current default version of tclsh is using
the following pattern of commands.

irwin@raven> ls -l /usr/bin/tclsh
lrwxrwxrwx 1 root root 23 Sep 29  2012 /usr/bin/tclsh -> 
/etc/alternatives/tclsh*
irwin@raven> ls -l /etc/alternatives/tclsh
lrwxrwxrwx 1 root root 22 Aug 10  2014 /etc/alternatives/tclsh -> 
/usr/bin/tclsh-default*
irwin@raven> ls -l /usr/bin/tclsh-default 
lrwxrwxrwx 1 root root 8 Mar 19  2013 /usr/bin/tclsh-default -> tclsh8.5*

If that symlink trail leads you to tclsh8.4, then you must run the
update-alternatives command appropriately to change that symlink trail
so that tclsh refers to tclsh8.5 and similarly for wish.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Jim Dishaw]

On Mar 11, 2015, at 4:59 PM, Phil Rosenberg  wrote:

> Hi Alan
> 
> A quick bit of stepping through my code has confirmed my suspicion
> from below. In plfill_soft plP_draphy is called for each line of the
> pattern and these lines are saved in the buffer, so basically writing
> to buffer needs switching off in this function. the change is about 3
> lines of code, but I will save it for post release if you prefer.
> 

That is essentially correct.  It appears that the issue is there is both a 
PLESC_FILL in the buffer and then the lines that were generated by plP_fill.  
There should be only one and not both and the PLESC_FILL should be the one to 
stay in the buffer.

The first solution that comes to my mind is to set plsc->plbuf_write = 0 after 
the plbuf_esc() call and restore the original value at the end of the function. 

> Phil
> 
> On 11 March 2015 at 18:31, Alan W. Irwin  wrote:
>> On 2015-03-11 13:01- Phil Rosenberg wrote:
>> 
 
 * Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts
 of the pie chart, but the other slices are fine.
>>> 
>>> This isn't shown on Windows. Perhaps the cause is that both the lines
>>> and the fill are being saved to the buffer meaning the lines get
>>> rendered twice. This is just a guess though
>> 


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Alan W. Irwin]

Hi Phil:

I just saw your one-line fix at
.

Does that really do the job?  For example, I noticed earlier in that code
a test of pls->device rather than pls->dev, but I am just looking at
patterns with no deep understanding of what is going on.

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Alan W. Irwin]

On 2015-03-11 20:59- Phil Rosenberg wrote:

> Hi Alan
>
> A quick bit of stepping through my code has confirmed my suspicion
> from below. In plfill_soft plP_draphy is called for each line of the
> pattern and these lines are saved in the buffer, so basically writing
> to buffer needs switching off in this function. the change is about 3
> lines of code, but I will save it for post release if you prefer.

Yes, please.  The rule of thumb I am using is that if the bug fix can
be implemented by changing just a few lines of unstyled code and the
impact is extremely limited (e.g., just confined to wxwidgets), then
that certainly qualifies for pushing to master.  But, of course, the
quicker the better for all these simple bug fixes so there is
sufficient time (typically a week) prior to release for everybody on
the PLplot devel list to comprehensively test your change.  Which
reminds me I have to implement a number of simple fixes also.  :-)

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
__

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

[Andrew Ross]

On Wed, Mar 11, 2015 at 02:30:04PM -0700, Alan Irwin wrote:
> Phil said:
> 
> > Hi Alan
> > Unfortunately you can probably ignore that email.
> 
> > On my work centos machine I tried running an example under the xwin
> device - thinking that a buffer problem would be likely to show up
> there as well as in the tk device. I then got just a black window and
> a hang. Moving back in time I found that the commit I listed gave the
> same black window and hang but the one before gave fine results.
> I've just looked at this from home and both on my Ubuntu PC and my
> Centos PC (both SSH'd in with x forwarding from Cygwin) ant the tip of
> master runs fin in both cases.
> 
> > So now I am utterly confused and have not got the tk driver running.
> 
> My guess is that SSH with X forwarding has figured out all the X
> authorization issues, while those may still occur whenever you try to
> use direct access.  So I would encourage you to test that hypothesis
> by trying -dev tk over an SSH X forwarded connection.  That may allow
> you to verify the two-GUI issue for -dev tk for master tip.
> 
> Assuming that hypothesis is correct, the change (for direct access for
> you) from working screen to black screen from 1e402417c1f^ to
> 1e402417c1f may not be a regression, but instead the result of
> (inadvertently) tightening up the X security model with that plbuf
> change.
> 
> @Andrew:
> I hope you respond to this by advising Phil the best way
> to have properly authorized X access when using Ubuntu
> directly, checking whether the above plbuf change makes a difference
> in your -dev xwin and -dev tk results on Ubuntu, etc.
> 
> For what it is worth, for the direct case I am just using the default
> X authorization for Debian that you get with the traditional "startx"
> method of starting my (KDE) desktop.  In other words, I don't use any
> of the xdm, kdm, or gdm3 display-manager methods of starting X for the
> direct case, but I am not sure whether that is relevant or not. But
> apparently, X is properly authorized by this method at least for
> Debian so the plbuf change referred to above has no effect on -dev tk
> results for me.

Actually, dredging my memories I vaguely remember problems in the past 
with this. Lo and behold I searched the list archive and found the
following thread from 2009

http://sourceforge.net/p/plplot/mailman/plplot-general/thread/1258412677.12670.12.camel%40dventimi-laptop/#msg23989000

which documents a lot of this. Phil - which version of Ubuntu / Tcl / Tk 
are you using? It seems this was fixed in the Ubuntu Tcl 8.5 packages a 
long time ago.

Andrew

 
~ 

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel