Re: [Plplot-devel] Error propagation

[Andrew Ross]

Hi all,

Sorry I have been silent for so long. Work and life have rather got in
the way of plplot development. This is something I have raised a couple
of times in the past and something I have thought about a fair bit.

Comments on Phil's proposals below.

Andrew

On Mon, 2017-01-30 at 11:00 +, Phil Rosenberg wrote:
> Hi all
> We have had this discussion in the past. But I would like to reopen
> it.
> 
> We really really need to get id of the exit() calls in PLplot. I
> don't
> think that we can really make any recommendation that our library is
> "industrial strength" while they are their and I would be very
> nervous
> about using PLplot in production software with them in - plus even
> using PLplot for science work I have been caught out be these calls
> in
> the past.
> 
> I think there are a few options we have got
> 
> Firstly with our internal propagation we can either do
> A1) Set up our functions so they return error codes and make sure we
> check these. I feel there is a tendency for this to be bad because I
> know that I am inherently lazy if I am frank (and I'm sure we all
> have
> our lazy moments) and tend to write code without these checks then
> (try to) go back and add them later. Missing checks are likely to
> cause segfaults or memory corruptions which are even worse than the
> exit calls().

Laziness is no excuse! The advantage of this proposal is that is allows
the library to clean things up as we unwind the stack and so (if done
properly) it will minimise any chance of problems down the line. Even
if this is a fatal error from plplot's perspective (e.g. memory
allocation failure), then we must return control to the calling
programme in a clean and controlled manner. 

> A2) Set up an error flag in PLStream which can be set on error and
> checked after every function call. This would avoid having to change
> functions that already return values, but still relies on manual
> checks which I think will be a big weak point.

I would agree that this is still subject to human laziness in checking
return codes. The advantage of explicitly returning values is that it
is at least more obvious you need to check them. On the other hand, if
functions already return values this gets tricky. We probably need to
do something of a code audit to see if this is likely to be an issue
before making final decisions.

> A3) Use setjmp/longjmp calls. In this case we call setjmp in the top
> level of every API call and on error we call longjmp which returns
> the
> execution point back to the point setjmp was called. There is some
> extra setup time here to avoid memory leaks and other resource leaks,
> but once that is done we can all write code with almost no worry
> regarding error propagation.

This has advantages in terms of not requiring explicit error code
checking. The bigger problem is making sure we tidy up properly to
avoid leaks. As Phil says, it requires some care thinking about how we
deal with non-C drivers as well. I can't say I'm too keen on
setjmp/longjmp. It can be a lazy solution to the problem rather than
writing better code in the first place, but given we have a fairly
large heritage codebase it might be an easier solution. 

> Once we decide on our internal method we need to decide how we can
> inform the user. We have a number of options again:
> 
> B1) An API change so that all our functions return an error code.

Quite a C-like approach. Requires quite a lot of changes to user code
to properly check for errors. Huge API change. Could cause problems for
the few plplot functions which already return a value. 

> B2) Make use of our current plabort call and let the user pass in a
> plabort handler.

This could get messy with some of the bindings. Calling an abort
handler also makes it hard for the programme to decide what to do. For
some uses for example you might want to shut down the plot, but
continue with the program. Harder with a handler. (I'm thinking about
things like the interactive octave bindings where I find it exceedingly
 annoying if plplot kills octave. In case of an error I might want to
return control to octave and proceed to save my work or whatever in an
orderly manner before choosing to exit or reinitialise plplot.) 

> B3) If we have an error, store an error code in PLStream and add an
> API function called plgeterr or similar which allows the user to
> check
> for error after any other function call.

Easier to implement in terms of API changes, but makes for ugly end
user code if the end user really does need to call an additional
function to check return codes every time. One plus of an internal
plstream error flag is that we could internally check it whenever a
function is called. This would prevent the user trying to continue
after an error (or just failing to check the error code). We could then
possible provide some mechanism for resetting the error flag and maybe
reinitialising plplot at the same time depending on the error? 

> B4) In the C++ binding

Re: [Plplot-devel] Would you be willing to test PLplot against Octave-3.8.2 or later in the 3.8 series?

[Andrew Ross]

I've built and run the non-interactive octave tests and they complete with
no errors using octave-3.8.2 on Ubuntu 15.04 (vivid). I did have some
build errors, but that was just related to the hdf5.h header being in a
new location. 

Regards

Andrew

On Fri, Jul 10, 2015 at 09:48:54PM +0100, Andrew Ross wrote:
> 
> Coincidentally I have just this week upgraded my Ubuntu install so I now
> have octave 3.8.2. I will run some tests and see what happens.
> 
> Andre
> 
> On Thu, Jul 09, 2015 at 03:01:53AM -0700, Alan Irwin wrote:
> > Hi Andrew:
> > 
> > In case you didn't have a chance to read it, the summary of the recent
> > part of my thread with Arjen is he now has a successful build on
> > Cygwin of our octave bindings against Octave-3.8.2.  However, he
> > discovered there were run-time errors when running our octave examples
> > for that version of Octave. I do not get those run-time errors for the
> > Octave-3.6.2 Linux case.
> > 
> > Would you be willing to test PLplot against Octave-3.8.2 or later
> > yourself to see if the issue Arjen is seeing is confined to
> > just 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
> > __
> 
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Would you be willing to test PLplot against Octave-3.8.2 or later in the 3.8 series?

[Andrew Ross]

Coincidentally I have just this week upgraded my Ubuntu install so I now
have octave 3.8.2. I will run some tests and see what happens.

Andre

On Thu, Jul 09, 2015 at 03:01:53AM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> In case you didn't have a chance to read it, the summary of the recent
> part of my thread with Arjen is he now has a successful build on
> Cygwin of our octave bindings against Octave-3.8.2.  However, he
> discovered there were run-time errors when running our octave examples
> for that version of Octave. I do not get those run-time errors for the
> Octave-3.6.2 Linux case.
> 
> Would you be willing to test PLplot against Octave-3.8.2 or later
> yourself to see if the issue Arjen is seeing is confined to
> just 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
> __

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Linking model review requested

[Andrew Ross]

On Wed, Jun 03, 2015 at 10:55:35PM +0100, Andrew Ross wrote:
> 
> Sorry for the delay in replying, but I've been away and busy with work.
> 
> I agree with your conclusion that it is probably not worth it. If you did
> want to implement this for g++ though, then the point about the multiple
> directories is that you should link against the correct version of stdc++
> for your gcc version. To find this the best way is probably to use the
> -print-file-name option. 
> 
> On my Ubuntu system 
> $ g++ -print-file-name=libstdc++.so
> /usr/lib/gcc/x86_64-linux-gnu/4.9/libstdc++.so
> 
> $ g++-4.4 -print-file-name=libstdc++.so
> /usr/lib/gcc/x86_64-linux-gnu/4.4.7/libstdc++.so
> 
> So this will always pick up the right version. This should work across
> multiple Linux distributions, and also, I hope, on cygwin etc.

I should finish reading my emails before replying. It seems you have found
a more elegant general solution anyway, so ignore this!

Andrew

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

Re: [Plplot-devel] Linking model review requested

[Andrew Ross]

On Thu, May 21, 2015 at 06:31:00PM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> I will respond to your two posts here.
> 
> On 2015-05-21 22:54+0100 Andrew Ross wrote:
> 
> >
> > Alan,
> >
> > I think your summary is probably correct
> 
> Good. That is a big relief to me that I wasn't missing
> anything obvious, and thanks for that review.
> 
> > [B]ut the solution of just
> > explicitly linking stdc++ is so simple, that it makes me think it must be
> > possible to work round this. A flag if there is any C++ code would be
> > sufficient to identify the need to link with stdc++?
> 
> More below on this after I quote your additional post.
> 
> On 2015-05-21 23:00+0100 Andrew Ross wrote:
> 
> >
> > I should probably add that this would for g++, but perhaps not other
> > compilers. This is a common enough case that it is perhaps worth
> > supporting as a special case nontheless?
> >
> > Or we could take the decision that cmake builds are the way to go,
> and we
> > can't support all non-standard cases for the traditional build.
> 
> Even if you restrict yourself to supporting only the g++ compiler
> for this corner case, the problem is that even if you restrict
> yourself still further to just Debian wheezy,
> there are 3 separate libstdc++.so symbolic links depending on
> g++ compiler version, i.e.,
> 
> /usr/lib/gcc/x86_64-linux-gnu/4.4/libstdc++.so
> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so
> /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so
> 
> As it happens they all link to the same version of the libstdc++.so.6
> symlink for Debian wheezy, but in general I don't think you can guarantee 
> that for all Linux
> platforms.  And in any case the CMake find_library command works only
> for the *.so version of library symlinks and not the *.so. version of
> library symlinks.  So you need a cross-platform way with whatever g++ version
> you are using to find the appropriate directory above in which to do
> the CMake find_library(stdc++).  And when I attempted to implement
> that a few months back it turned into a real mess with semicolon
> separation of library locations turning into colon separation for
> the latest g++ version on Fedora.  And I have no idea how the
> Cygwin version of g++ is going to cope with that "upgrade" since colon 
> separation
> is also intrinsically obfuscated by the drive letter question.

Alan,

Sorry for the delay in replying, but I've been away and busy with work.

I agree with your conclusion that it is probably not worth it. If you did
want to implement this for g++ though, then the point about the multiple
directories is that you should link against the correct version of stdc++
for your gcc version. To find this the best way is probably to use the
-print-file-name option. 

On my Ubuntu system 
$ g++ -print-file-name=libstdc++.so
/usr/lib/gcc/x86_64-linux-gnu/4.9/libstdc++.so

$ g++-4.4 -print-file-name=libstdc++.so
/usr/lib/gcc/x86_64-linux-gnu/4.4.7/libstdc++.so

So this will always pick up the right version. This should work across
multiple Linux distributions, and also, I hope, on cygwin etc.

Andrew
~   
 
~  

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

Re: [Plplot-devel] Linking model review requested

[Andrew Ross]

I should probably add that this would for g++, but perhaps not other
compilers. This is a common enough case that it is perhaps worth
supporting as a special case nontheless? 

Or we could take the decision that cmake builds are the way to go, and we
can't support all non-standard cases for the traditional build.

Andrew

On Thu, May 21, 2015 at 10:54:19PM +0100, Andrew Ross wrote:
> 
> Alan,
> 
> I think your summary is probably correct, but the solution of just
> explicitly linking stdc++ is so simple, that it makes me think it must be
> possible to work round this. A flag if there is any C++ code would be
> sufficient to identify the need to link with stdc++?
> 
> Andrew
> 
> On Wed, May 20, 2015 at 10:25:06PM -0700, Alan Irwin wrote:
> > Hi Andrew:
> > 
> > Would you please take a quick look at the commit message for a09dc18?
> > In that commit message I outline the linking model I used to draw the
> > conclusion that the ada, d, f95, java, and ocaml traditional examples
> > builds were going to _sometimes_ fail for a certain combination of
> > circumstances (static PLplot build with at least one of the C++ device
> > drivers enabled).
> > 
> > I am asking for that review because I hate to give up all those
> > components of the comprehensive test of the traditional build for the
> > given circumstances if I don't have to.  I am pretty sure your review
> > of the linking model I use will show I am right, but nevertheless that
> > review would be much appreciated since it would help to put my mind at
> > ease about this commit (which disables the relevant parts of the
> > comprehensive test for the given combination of circumstances).
> > 
> > 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
> > __
> 
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Linking model review requested

[Andrew Ross]

Alan,

I think your summary is probably correct, but the solution of just
explicitly linking stdc++ is so simple, that it makes me think it must be
possible to work round this. A flag if there is any C++ code would be
sufficient to identify the need to link with stdc++?

Andrew

On Wed, May 20, 2015 at 10:25:06PM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> Would you please take a quick look at the commit message for a09dc18?
> In that commit message I outline the linking model I used to draw the
> conclusion that the ada, d, f95, java, and ocaml traditional examples
> builds were going to _sometimes_ fail for a certain combination of
> circumstances (static PLplot build with at least one of the C++ device
> drivers enabled).
> 
> I am asking for that review because I hate to give up all those
> components of the comprehensive test of the traditional build for the
> given circumstances if I don't have to.  I am pretty sure your review
> of the linking model I use will show I am right, but nevertheless that
> review would be much appreciated since it would help to put my mind at
> ease about this commit (which disables the relevant parts of the
> comprehensive test for the given combination of circumstances).
> 
> 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
> __

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Version 6?

[Andrew Ross]

On Tue, May 12, 2015 at 02:51:12PM -0400, Hazen Babcock wrote:
> 
> This e-mail is to provide a summary of what we had discussed, please let 
> me know if I left anything out. I think we had a consensus that the 
> following change would be made as part of a possible version 6:
> 
> 1. All API functions return error codes.
> 
> 
> I think we also agreed on these items, which might not actually require 
> a major version bump as the actual change to the API is potentially 
> small / nil:
> 
> 2. Thread safety.
> 
> 3. Improved text handling between core and the drivers.
> 
> 
> And there was some discussion about whether this was a good idea:
> 
> 4. Core handles some text rendering.
> 
> 
> Now I think the question is if the effort and disruption involved in (1) 
> justifies making the change. I would say that I'm neutral about this. I 
> feel that it is the way a modern library should behave. However I'm not 
> sure that the fact that PLplot does not currently work this way is 
> actually causing a lot of problems for people.

Hazen, 

There are some cases where 1) does cause problems - notably for
interactive drivers like octave where you do not want errors to result in
the program being killed off. The library should report the error and let
the program deal with it.

It also causes lintian warnings on Debian as it is a Bad Thing (TM) for
libraries to do. (For those who don't know, lintian is a package checking
program which looks for a whole range of errors / breaches of policy / bad
practice when packaging software for Debian).

Andrew

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Commit id c44f636

[Andrew Ross]

Alan,

I'll add it to my list of things to look at.

Andrew

On Mon, Apr 20, 2015 at 05:48:09PM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> Commit id c44f636 makes a substantial hack to plparseopts so that the -debug
> option now works for any code (e.g., plInitDispatchTable) that is called
> by pllib_init.
> 
> The result passes substantial testing (valgrind, test_noninteractive,
> and test_interactive) on Linux, but you are much more familiar with
> the plparseopts code than I am so I would appreciate you looking at
> that hack to make sure I did not forget anything obvious.
> 
> 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] Comprehensive Testing: Ubuntu 14:10

[Andrew Ross]

On Sun, Apr 19, 2015 at 09:56:47AM +0100, Andrew Ross wrote:
> 
> I didn't want to comment on your code, but that was the impression I got!
> I am using g++-4.9, but I did the g++ --verbose --version test on Ubuntu
> versions back to 4.4 and all used the colon. I agree, dropping it is
> perhaps the best. Presumably the linkage with the CXX compiler should only
> be if the C++ bindings are enabled? This is almost always going to be the
> case these days, but someone might want to compile a minimal C only
> static library for embedded purposes?

OK. Looking at your commit, you've already dealt with corner case I see.

Andrew


--
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] Comprehensive Testing: Ubuntu 14:10

[Andrew Ross]

On Sat, Apr 18, 2015 at 05:00:52PM -0700, Alan Irwin wrote:
> On 2015-04-18 22:56+0100 Andrew Ross wrote:
> 
> >
> >Alan,
> >
> >I've finally got time to rerun my comnprehensive tests with Ubuntu 14.10
> >and try to debug the niggle issues I encountered with the static build
> >
> >(My only change from last time is that I've had to build cmake from source
> >to get a new enough version - I'm using 3.2.2)
> [...]
> >2) The code in src/CMakeFiles to find the stdc++ library doesn't work for
> >me. The comments suggest that g++ returns a semicolon delimited list of
> >paths, which is just like a cmake list so no manipulation is needed. At
> >least on my system it is actually colon separated. Replacing the colons
> >with semicolons fixes the problem and ensures the correct linkage options
> >for pkg-config, and hence the traditional examples build. I've not
> >commited this fix, since it might upset other people. In particularly on
> >windows the colon may be used for drive letters? Can others check
> >what g++ returns to check that a simple replacement of colons with
> >semicolons wouldn't break anything? Try g++ --verbose --version and look
> >at what LIBRARY_PATH is set to.
> 
> The problem is that libplplot is a mixed C and C++ library for the
> nondynamic or static case (because of including C++ drivers code in
> the library for those cases).  Therefore, for the traditional build
> system for the installed examples, when gcc is used to link a C
> example a specific link to libstdc++.so has to be provided.
> 
> The code in src/CMakeLists.txt to find that library is really ugly,
> works only for g++ and no other C++ compiler, and depends on g++
> internals which apparently have now changed.  And colon separation
> when there are drive letters is a real pain to deal with.  So I plan
> to abandon that code completely and simply solve the problem
> in a general way for the static and nondyamic cases by using the CXX
> compiler (which automatically links in libstdc++.so) for building
> the C examples using the traditional build system. Implementation
> to follow

I didn't want to comment on your code, but that was the impression I got!
I am using g++-4.9, but I did the g++ --verbose --version test on Ubuntu
versions back to 4.4 and all used the colon. I agree, dropping it is
perhaps the best. Presumably the linkage with the CXX compiler should only
be if the C++ bindings are enabled? This is almost always going to be the
case these days, but someone might want to compile a minimal C only
static library for embedded purposes?

> >3) I also get the following errors
> >
> >/usr/bin/ld: 
> >/home/andrew/software/plplot/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(wxwidgets_comms.cpp.o):
> > undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
> >/lib/x86_64-linux-gnu/librt.so.1: error adding symbols: DSO missing from 
> >command line
> >collect2: error: ld returned 1 exit status
> >Makefile:103: recipe for target 'x00c' failed
> >make[1]: *** [x00c] Error 1
> >
> >which I think are probably due to librt not being linked explicitly? Alan
> >- I'm not quite sure where this needs fixing. Can you reproduce this on
> >Debian?
> 
> I cannot reproduce that issue (my comprehensive tests sailed through without 
> issues
> for Debian stable).
> 
> There was an attempt to fix the rt issues prior to the 5.11.0 release,
> but it sounds like we missed something that matters on at least
> Ubuntu.
> 
> Here is where to look in our current source code for such fixes.
> 
> software@raven> find . -type f |grep -v .git |grep -v ChangeLog |xargs grep 
> RT_LIB
> ./drivers/CMakeLists.txt:   ${RT_LIB}
> ./src/CMakeLists.txt:  list(APPEND libplplot_LINK_LIBRARIES ${RT_LIB})
> ./cmake/modules/wxwidgets.cmake:# So only define RT_LIB for the Unix but 
> not Mac case.
> ./cmake/modules/wxwidgets.cmake:  find_library(RT_LIB rt)
> ./cmake/modules/wxwidgets.cmake:  if(RT_LIB)
> ./cmake/modules/wxwidgets.cmake:message(STATUS "RT_LIB = ${RT_LIB}")
> ./cmake/modules/wxwidgets.cmake:  else(RT_LIB)
> ./cmake/modules/wxwidgets.cmake:set(RT_LIB)
> ./cmake/modules/wxwidgets.cmake:  endif(RT_LIB)
> ./cmake/modules/wxwidgets.cmake:  set(RT_LIB)
> ./utils/CMakeLists.txt:  target_link_libraries(wxPLViewer plplotwxwidgets 
> plplotcxx ${wxwidgets_LINK_FLAGS} ${MATH_LIB} ${RT_LIB})
> 
> If that message result from cmake shows you are finding the rt library
> on Ubuntu without issues, then for the static case the code in
> src/CMakeListx.txt 

[Plplot-devel] Comprehensive Testing: Ubuntu 14:10

[Andrew Ross]

Alan,

I've finally got time to rerun my comnprehensive tests with Ubuntu 14.10
and try to debug the niggle issues I encountered with the static build

(My only change from last time is that I've had to build cmake from source
to get a new enough version - I'm using 3.2.2)

1) Warnings about conversion from string constant to char *. This is now
fixed by making pl_MenuStr and pl_DevName const char * not char *. These
variables are constant so the change should have no effect other than to
silence the warning.

2) The code in src/CMakeFiles to find the stdc++ library doesn't work for
me. The comments suggest that g++ returns a semicolon delimited list of
paths, which is just like a cmake list so no manipulation is needed. At
least on my system it is actually colon separated. Replacing the colons
with semicolons fixes the problem and ensures the correct linkage options
for pkg-config, and hence the traditional examples build. I've not
commited this fix, since it might upset other people. In particularly on
windows the colon may be used for drive letters? Can others check
what g++ returns to check that a simple replacement of colons with
semicolons wouldn't break anything? Try g++ --verbose --version and look
at what LIBRARY_PATH is set to. 

3) I also get the following errors

/usr/bin/ld: 
/home/andrew/software/plplot/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(wxwidgets_comms.cpp.o):
 undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/librt.so.1: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
Makefile:103: recipe for target 'x00c' failed
make[1]: *** [x00c] Error 1

which I think are probably due to librt not being linked explicitly? Alan
- I'm not quite sure where this needs fixing. Can you reproduce this on
Debian?

Regards

Andrew


--
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] bug 159

[Andrew Ross]

Alan,

I'll try and take a look. Just to confirm, I also see the issue with
example 27. I also tried different drivers, and they all segfault with
non-zero orientation. Exactly where the segfault occurs does depend on the
driver though so this will require a bit more digging.

Andrew

On Thu, Apr 16, 2015 at 10:35:53AM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> James Tappin reported a bug with using orientation and plfill with a
> large number of points in bug 159 for every device driver he looked
> at.  I didn't bother with his fortran example, but I did remember our standard
> example 27 uses a large number of points with plfill so tried the
> following valgrind experiments first without and then with a non-zero
> orientation.
> 
> ==3260== Memcheck, a memory error detector
> ==3260== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==3260== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==3260== Command: examples/c/x27c -dev svg -ori 0. -fam -o test.svg
> ==3260== 
> ==3260== 
> ==3260== HEAP SUMMARY:
> ==3260== in use at exit: 0 bytes in 0 blocks
> ==3260==   total heap usage: 1,121 allocs, 1,121 frees, 593,146 bytes 
> allocated
> ==3260== 
> ==3260== All heap blocks were freed -- no leaks are possible
> ==3260== 
> ==3260== For counts of detected and suppressed errors, rerun with: -v
> ==3260== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
> 
> So far so good.  But with non-zero -ori parameter we get a severe
> memory management error (invalid read) and segfault.
> 
> ==3263== Memcheck, a memory error detector
> ==3263== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==3263== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==3263== Command: examples/c/x27c -dev svg -ori 0.1 -fam -o test.svg
> ==3263== 
> plOpenFile: Opened test.svg.12
> ==3263== Invalid read of size 1
> ==3263==at 0x6E1E87C: svg_fill_background_color (svg.c:1122)
> ==3263==by 0x6E1C837: plD_bop_svg (svg.c:277)
> ==3263==by 0x4E5204C: plP_bop (plcore.c:211)
> ==3263==by 0x4E808E9: c_pladv (plpage.c:49)
> ==3263==by 0x400FBD: main (x27c.c:108)
> ==3263==  Address 0x12891295 is not stack'd, malloc'd or (recently) free'd
> ==3263== 
> ==3263== 
> ==3263== Process terminating with default action of signal 11 (SIGSEGV)
> ==3263==  Access not within mapped region at address 0x12891295
> ==3263==at 0x6E1E87C: svg_fill_background_color (svg.c:1122)
> ==3263==by 0x6E1C837: plD_bop_svg (svg.c:277)
> ==3263==by 0x4E5204C: plP_bop (plcore.c:211)
> ==3263==by 0x4E808E9: c_pladv (plpage.c:49)
> ==3263==by 0x400FBD: main (x27c.c:108)
> ==3263==  If you believe this happened as a result of a stack
> ==3263==  overflow in your program's main thread (unlikely but
> ==3263==  possible), you can try to increase the size of the
> ==3263==  main thread stack using the --main-stacksize= flag.
> ==3263==  The main thread stack size used in this run was 8388608.
> ==3263== 
> ==3263== HEAP SUMMARY:
> ==3263== in use at exit: 74,003 bytes in 286 blocks
> ==3263==   total heap usage: 1,135 allocs, 849 frees, 458,756 bytes allocated
> ==3263== 
> ==3263== LEAK SUMMARY:
> ==3263==definitely lost: 3,456 bytes in 2 blocks
> ==3263==indirectly lost: 0 bytes in 0 blocks
> ==3263==  possibly lost: 0 bytes in 0 blocks
> ==3263==still reachable: 70,547 bytes in 284 blocks
> ==3263== suppressed: 0 bytes in 0 blocks
> ==3263== Rerun with --leak-check=full to see details of leaked memory
> ==3263== 
> ==3263== For counts of detected and suppressed errors, rerun with: -v
> ==3263== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
> Segmentation fault
> 
> If I try the same experiments with example 25 (which also uses plfill
> but with just a small number of points) I get a valgrind clean result
> for both orientations.  A significant difference between the two
> examples is 27 uses a much larger number of points for the vertices of
> the filled area.  If you look at the plfill routine in src/plfill.c if
> the number of vertices are greater than PL_MAXPOLY - 1 (= 255) it
> allocates (and later frees) some memory to hold the vertices rather
> than using a static array for that purpose.  But I cannot figure out
> why a non-zero orientation parameter affects this logic at all.
> 
> James summary of the issue was that the fill was corrupted.  I am
> pretty sure that rendering issue was because of the severe memory
> management error, but by chance he did not get the segfault while I did.
> 
> In any case, it is clear from the above results that we have a severe
> memory management issue for the stated corner case (non-zero
> orientation, large number of points, and fill) for 5.11.0 (my test was
> for current master tip) and many prior versions (probably back to when
> we found example 27 was overflowing the static array and put in the
> logic to use a dynamic array to store the vertices for th

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

[Andrew Ross]

On Sat, Mar 28, 2015 at 05:41:12PM -0700, Alan Irwin wrote:
> On 2015-03-28 21:40-0000 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
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726069>.  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

[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

Re: [Plplot-devel] fixed memory leak plplot-5.10.0 (Andrew Ross)

[Andrew Ross]

Phil,

The same thought had also crossed my mind. This is a more modern way to
handle errors. You would need the C interface to catch the exceptions and
return an error code since not all of our languages would handle them.
This might require C++ -> C -> some thing else which is not pretty
either...

As you point out almost all plabort calls are memory management related
which does reduce the problem a bit.

Andrew

On Mon, Mar 23, 2015 at 04:51:44PM +, Phil Rosenberg wrote:
> Yeah it's something I've been thinking about too. But not a fun task.
> 
> To be honest I was starting to think that the least intrusive method
> would be to convert everything to C++, with a C frontend and use
> try-catch blocks with throw. Well I'm joking - sortof.
> 
> But yes this has caused me major pain in the past when using
> wxWidgets. Almost all abort calls are from memory allocation failures.
> so sorting resilience to these failures would be a major step in the
> right direction.
> 
> Phil
> 
> On 19 March 2015 at 21:25, Jim Dishaw  wrote:
> >
> > On Mar 19, 2015, at 4:03 PM, Andrew Ross  
> > wrote:
> >
> >> On Thu, Mar 19, 2015 at 03:30:21PM -0400, Hazen Babcock wrote:
> >>>> From: Andrew Ross 
> >>>>
> >>>>> The attached patch fixes the memory leak for me. Pressing the close 
> >>>>> button
> >>>>> should now behave the same as pressing 'Q', i.e. it will abort the
> >>>>> program and clean up correctly. It looks like this was changed at some
> >>>>> stage in the past, but I don't know why. I guess this would allow a
> >>>>> programme to continue, and to potentially reopen a new xwin window. If 
> >>>>> we
> >>>>> want to retain this functionality it will require a bit more thinking
> >>>>> about.
> >>>>
> >>>> Thinking some more about this, I seem to recall the change was made
> >>>> because of interactive bindings. For example, if you are using octave and
> >>>> pressed the close button then the call to plabort would kill your entire
> >>>> octave session which is clearly not desirable. We definitely don't want 
> >>>> to
> >>>> apply my patch as is. I need to work through all the tidy up code in
> >>>> xwin.c to check exactly the path that is being followed. The current code
> >>>> is doing the right thing in terms of closing the window and ignoring all
> >>>> further commands to the plplot stream, we just need to ensure that the
> >>>> tidy function is called at the end. A clean way of doing this would be to
> >>>> have multiple levels of stream_closed. 0 = open, 1 = closed, but still
> >>>> need to call tidy, 2 = closed and tidy already called.
> >>>>
> >>>> Only the xwin and cairo drivers set this flag, but it is checked in the
> >>>> core plplot code. I can simply implement this change Alan, but your call
> >>>> whether you want to commit it at this late stage. It should be trivial.
> >>>
> >>> Yes, it was implemented for exactly the reason that you state. I added
> >>> this in September of 2010 (v11159, v11160). I'd appreciate if we did not
> >>> revert to the old behavior which was, in my opinion, very unfriendly.
> >>
> >> I agree Hazen. My fix (which I'll wait until post-release to apply)
> >> doesn't revert to calling plabort.
> >>
> >> This strikes me as another reason why we need to bite the bullet and tidy
> >> up our error handling in plplot. We really need to get rid of plabort() and
> >> all the calls to exit(). Libraries shouldn't exit - they should return an
> >> error and let the calling program make the decision.
> >>
> >> We've known this for a long time, but it will be a pretty intrusive (and
> >> backwards incompatible) change to plplot. Maybe I should just take this on
> >> post-release if others are in agreement.
> >>
> >
> > I was planning on cleaning up error and warning handling post-release.  
> > While working on plbuf and metafiles, I kept grappling with how to best 
> > handle errors and warnings.
> >
> >
> > --
> > 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
> > t

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

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew Ross]

On Thu, Mar 19, 2015 at 09:09:27AM -0700, Alan Irwin wrote:
> On 2015-03-19 09:08-0000 Andrew Ross wrote:
> 
> >
> >>The attached patch fixes the memory leak for me. Pressing the close button
> >>should now behave the same as pressing 'Q', i.e. it will abort the
> >>program and clean up correctly. It looks like this was changed at some
> >>stage in the past, but I don't know why. I guess this would allow a
> >>programme to continue, and to potentially reopen a new xwin window. If we
> >>want to retain this functionality it will require a bit more thinking
> >>about.
> >
> >Thinking some more about this, I seem to recall the change was made
> >because of interactive bindings. For example, if you are using octave and
> >pressed the close button then the call to plabort would kill your entire
> >octave session which is clearly not desirable. We definitely don't want to
> >apply my patch as is. I need to work through all the tidy up code in
> >xwin.c to check exactly the path that is being followed. The current code
> >is doing the right thing in terms of closing the window and ignoring all
> >further commands to the plplot stream, we just need to ensure that the
> >tidy function is called at the end. A clean way of doing this would be to
> >have multiple levels of stream_closed. 0 = open, 1 = closed, but still
> >need to call tidy, 2 = closed and tidy already called.
> >
> >Only the xwin and cairo drivers set this flag, but it is checked in the
> >core plplot code. I can simply implement this change Alan, but your call
> >whether you want to commit it at this late stage. It should be trivial.
> 
> With regard to that fix you might also find -dev tk affected since
> that device driver uses parts of -dev xwin if I recall correctly.
> 
> But in any case, let's stick with the idea of regression fixes only
> since we are so near to release.  But by all means please implement it
> on a topic branch ready to be pushed post release.

It's possible -dev tk is also affected. Anyway, I'll hold the fix until
post-release. 

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] fixed memory leak plplot-5.10.0 (Andrew Ross)

[Andrew Ross]

On Thu, Mar 19, 2015 at 03:30:21PM -0400, Hazen Babcock wrote:
> > From: Andrew Ross 
> >
> >> The attached patch fixes the memory leak for me. Pressing the close button
> >> should now behave the same as pressing 'Q', i.e. it will abort the
> >> program and clean up correctly. It looks like this was changed at some
> >> stage in the past, but I don't know why. I guess this would allow a
> >> programme to continue, and to potentially reopen a new xwin window. If we
> >> want to retain this functionality it will require a bit more thinking
> >> about.
> >
> > Thinking some more about this, I seem to recall the change was made
> > because of interactive bindings. For example, if you are using octave and
> > pressed the close button then the call to plabort would kill your entire
> > octave session which is clearly not desirable. We definitely don't want to
> > apply my patch as is. I need to work through all the tidy up code in
> > xwin.c to check exactly the path that is being followed. The current code
> > is doing the right thing in terms of closing the window and ignoring all
> > further commands to the plplot stream, we just need to ensure that the
> > tidy function is called at the end. A clean way of doing this would be to
> > have multiple levels of stream_closed. 0 = open, 1 = closed, but still
> > need to call tidy, 2 = closed and tidy already called.
> >
> > Only the xwin and cairo drivers set this flag, but it is checked in the
> > core plplot code. I can simply implement this change Alan, but your call
> > whether you want to commit it at this late stage. It should be trivial.
> 
> Yes, it was implemented for exactly the reason that you state. I added 
> this in September of 2010 (v11159, v11160). I'd appreciate if we did not 
> revert to the old behavior which was, in my opinion, very unfriendly.

I agree Hazen. My fix (which I'll wait until post-release to apply)
doesn't revert to calling plabort.

This strikes me as another reason why we need to bite the bullet and tidy
up our error handling in plplot. We really need to get rid of plabort() and
all the calls to exit(). Libraries shouldn't exit - they should return an
error and let the calling program make the decision. 

We've known this for a long time, but it will be a pretty intrusive (and
backwards incompatible) change to plplot. Maybe I should just take this on
post-release if others are in agreement.

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] fixed memory leak plplot-5.10.0

[Andrew Ross]

On Thu, Mar 19, 2015 at 09:08:21AM +, Andrew Ross wrote:
> 
> > The attached patch fixes the memory leak for me. Pressing the close button
> > should now behave the same as pressing 'Q', i.e. it will abort the
> > program and clean up correctly. It looks like this was changed at some
> > stage in the past, but I don't know why. I guess this would allow a
> > programme to continue, and to potentially reopen a new xwin window. If we
> > want to retain this functionality it will require a bit more thinking
> > about. 
> 
> Thinking some more about this, I seem to recall the change was made
> because of interactive bindings. For example, if you are using octave and
> pressed the close button then the call to plabort would kill your entire
> octave session which is clearly not desirable. We definitely don't want to
> apply my patch as is. I need to work through all the tidy up code in
> xwin.c to check exactly the path that is being followed. The current code
> is doing the right thing in terms of closing the window and ignoring all
> further commands to the plplot stream, we just need to ensure that the
> tidy function is called at the end. A clean way of doing this would be to
> have multiple levels of stream_closed. 0 = open, 1 = closed, but still
> need to call tidy, 2 = closed and tidy already called.
> 
> Only the xwin and cairo drivers set this flag, but it is checked in the
> core plplot code. I can simply implement this change Alan, but your call
> whether you want to commit it at this late stage. It should be trivial.

Further thought showed the patch was even simpler. Since only the xwin and
xcairo drivers change stream_closed, and then only when the close button
is pressed, we don't need the check of if ( ! stream_closed ) around the
call to plD_tidy. This change now removes the extra valgrind leaks when
using the close button for xwin / xcairo drivers. There are still a good
number of other leaks to investigate, but I suspect these are library
related. I have tested this with and without dynamic drivers, and also
checked no adverse affects on our clear psc results. 

Alan - your call whether to apply this or not. I am pretty confident that
this will not have adverse effects, but I would like testing by others.

Andrew
>From 639ed78612c786589c0e5c2d302f8e3bd677c782 Mon Sep 17 00:00:00 2001
From: Andrew Ross 
Date: Thu, 19 Mar 2015 09:27:52 +
Subject: [PATCH] Fix bug where plD_tidy_* routine wasn't closed if the xwin /
 xcairo drivers were exited using the close button.

---
 src/plcore.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/plcore.c b/src/plcore.c
index 6f03420..4bcc24c 100644
--- a/src/plcore.c
+++ b/src/plcore.c
@@ -231,10 +231,7 @@ plP_tidy( void )
 }
 
 save_locale = plsave_set_locale();
-if ( !plsc->stream_closed )
-{
-( *plsc->dispatch_table->pl_tidy )( (struct PLStream_struct *) plsc );
-}
+( *plsc->dispatch_table->pl_tidy )( (struct PLStream_struct *) plsc );
 plrestore_locale( save_locale );
 
 if ( plsc->plbuf_write )
-- 
2.1.0

--
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] fixed memory leak plplot-5.10.0

[Andrew Ross]

Great! That confirms we are looking at exactly the same bug. Thanks for
the prompt response. I think I now know how to fix it. The same issue also
seems to occur with the xcairo driver.

Andrew

On Thu, Mar 19, 2015 at 02:08:38AM -0700, Norman Goldstein wrote:
> During my testing, I was using the close button (X) to close the window.
> 
> Just now, I reran the xwin test by hitting "return" to close the window,
> and this produced a core dump!
> 
> Thanks for looking into all this stuff.  Let me know if I can
> help.
> 
> Regards,
> Norm
> 
> 
> 
> 
> On 03/19/2015 01:56 AM, Andrew Ross wrote:
> > Norman,
> >
> > Thanks. This confirms that you are not using dynamic drivers. This
> > explains why your fix works for you and coincides with my experiments.
> > Just one further confirmation - were you closing the plplot window using
> > the close button (X) on the window, or by pressing return / 'Q'?
> >
> > Your testing is really useful here since there are lots of different build
> > options / paths through the code, even for simple examples. We have a
> > pretty comprehensive set of tests, but it is hard for us to cover
> > everything. For example, when running the interactive tests I always use
> > return to move on to the next page so I'd not spotted this bug before.
> > You've definitely highlighted one xwin driver bug - I just need to work
> > out the best way to fix it. I just want to be sure there is nothing else
> > lurking behind it.
> >
> > Thanks
> >
> > Andrew
> >
> > On Wed, Mar 18, 2015 at 09:20:29PM -0700, Norman Goldstein wrote:
> >> Sorry, I just got back in ...
> >> OK, I certainly bow to your more extensive insight to the plplot big
> >> picture.
> >> For the record, here is how I configured plolot:
> >>
> >> cmake -DENABLE_ocaml=OFF -DCMAKE_BUILD_TYPE=Debug. -DBUILD_TEST=ON  .
> >>
> >> Attached, is the cmake log.
> >> I see that the default isENABLE_DYNDRIVERS:OFF
> >>
> >> I disabled ocaml to avoid circular soft-linking that was breaking the 
> >> build.
> >>   I ran examples/c++/x00.cpp  to do my testing, for xw, psc and svg, for 
> >> the
> >> two cases of interactively typing in the device number, and of supplying
> >> the -dev swtich on the command line.
> >>
> >> When I was first running on the downloaded code, I set a breakpoint
> >> on plD_tidy_xw, and it was never hit.  That is what started me going
> >> down the path I took.  Here are the results of "make test", that I just
> >> ran on my patched branch:
> >>
> >> Running tests...
> >> Test project /home/transient/systems/PLPLOT/plplot.git
> >>Start  1: examples_c
> >>   1/18 Test  #1: examples_c ...   Passed 14.57 sec
> >>Start  2: examples_cxx
> >>   2/18 Test  #2: examples_cxx .   Passed 14.87 sec
> >>Start  3: examples_f95
> >>   3/18 Test  #3: examples_f95 .   Passed 5.13 sec
> >>Start  4: examples_octave
> >>   4/18 Test  #4: examples_octave ..   Passed 7.60 sec
> >>Start  5: examples_python
> >>   5/18 Test  #5: examples_python ..   Passed 19.39 sec
> >>Start  6: examples_svg
> >>   6/18 Test  #6: examples_svg .   Passed 16.68 sec
> >>Start  7: examples_pscairo
> >>   7/18 Test  #7: examples_pscairo .***Failed 0.20 sec
> >>Start  8: examples_pngcairo
> >>   8/18 Test  #8: examples_pngcairo ***Failed 0.09 sec
> >>Start  9: examples_xfig
> >> *** Error in `/home/transient/systems/PLPLOT/plplot.git/examples/c/x00c':
> >> double free or corruption (!prev): 0x01e0d500 **
> >> .. Lots of lines--
> >>   9/18 Test  #9: examples_xfig ***Failed 0.05 sec
> >>Start 10: examples_bmpqt
> >> 10/18 Test #10: examples_bmpqt ...***Failed 0.89 sec
> >>Start 11: examples_jpgqt
> >> 11/18 Test #11: examples_jpgqt ...***Failed 0.49 sec
> >>Start 12: examples_pngqt
> >> 12/18 Test #12: examples_pngqt ...***Failed 0.62 sec
> >>Start 13: examples_ppmqt
> >> 13/18 Test #13: examples_ppmqt ...***Failed 0.61 sec
> >>Start 14: examples_tiffqt
> >> 14/18 Test #14: examples_tif

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew Ross]

> The attached patch fixes the memory leak for me. Pressing the close button
> should now behave the same as pressing 'Q', i.e. it will abort the
> program and clean up correctly. It looks like this was changed at some
> stage in the past, but I don't know why. I guess this would allow a
> programme to continue, and to potentially reopen a new xwin window. If we
> want to retain this functionality it will require a bit more thinking
> about. 

Thinking some more about this, I seem to recall the change was made
because of interactive bindings. For example, if you are using octave and
pressed the close button then the call to plabort would kill your entire
octave session which is clearly not desirable. We definitely don't want to
apply my patch as is. I need to work through all the tidy up code in
xwin.c to check exactly the path that is being followed. The current code
is doing the right thing in terms of closing the window and ignoring all
further commands to the plplot stream, we just need to ensure that the
tidy function is called at the end. A clean way of doing this would be to
have multiple levels of stream_closed. 0 = open, 1 = closed, but still
need to call tidy, 2 = closed and tidy already called.

Only the xwin and cairo drivers set this flag, but it is checked in the
core plplot code. I can simply implement this change Alan, but your call
whether you want to commit it at this late stage. It should be trivial.

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] fixed memory leak plplot-5.10.0

[Andrew Ross]

Norman,

Thanks. This confirms that you are not using dynamic drivers. This
explains why your fix works for you and coincides with my experiments.
Just one further confirmation - were you closing the plplot window using
the close button (X) on the window, or by pressing return / 'Q'?

Your testing is really useful here since there are lots of different build
options / paths through the code, even for simple examples. We have a
pretty comprehensive set of tests, but it is hard for us to cover
everything. For example, when running the interactive tests I always use
return to move on to the next page so I'd not spotted this bug before.
You've definitely highlighted one xwin driver bug - I just need to work
out the best way to fix it. I just want to be sure there is nothing else
lurking behind it.

Thanks

Andrew

On Wed, Mar 18, 2015 at 09:20:29PM -0700, Norman Goldstein wrote:
> Sorry, I just got back in ...
> OK, I certainly bow to your more extensive insight to the plplot big
> picture.
> For the record, here is how I configured plolot:
> 
> cmake -DENABLE_ocaml=OFF -DCMAKE_BUILD_TYPE=Debug. -DBUILD_TEST=ON  .
> 
> Attached, is the cmake log.
> I see that the default isENABLE_DYNDRIVERS:OFF
> 
> I disabled ocaml to avoid circular soft-linking that was breaking the build.
>  I ran examples/c++/x00.cpp  to do my testing, for xw, psc and svg, for the
> two cases of interactively typing in the device number, and of supplying
> the -dev swtich on the command line.
> 
> When I was first running on the downloaded code, I set a breakpoint
> on plD_tidy_xw, and it was never hit.  That is what started me going
> down the path I took.  Here are the results of "make test", that I just
> ran on my patched branch:
> 
> Running tests...
> Test project /home/transient/systems/PLPLOT/plplot.git
>   Start  1: examples_c
>  1/18 Test  #1: examples_c ...   Passed 14.57 sec
>   Start  2: examples_cxx
>  2/18 Test  #2: examples_cxx .   Passed 14.87 sec
>   Start  3: examples_f95
>  3/18 Test  #3: examples_f95 .   Passed 5.13 sec
>   Start  4: examples_octave
>  4/18 Test  #4: examples_octave ..   Passed 7.60 sec
>   Start  5: examples_python
>  5/18 Test  #5: examples_python ..   Passed 19.39 sec
>   Start  6: examples_svg
>  6/18 Test  #6: examples_svg .   Passed 16.68 sec
>   Start  7: examples_pscairo
>  7/18 Test  #7: examples_pscairo .***Failed 0.20 sec
>   Start  8: examples_pngcairo
>  8/18 Test  #8: examples_pngcairo ***Failed 0.09 sec
>   Start  9: examples_xfig
> *** Error in `/home/transient/systems/PLPLOT/plplot.git/examples/c/x00c':
> double free or corruption (!prev): 0x01e0d500 **
> .. Lots of lines--
>  9/18 Test  #9: examples_xfig ***Failed 0.05 sec
>   Start 10: examples_bmpqt
> 10/18 Test #10: examples_bmpqt ...***Failed 0.89 sec
>   Start 11: examples_jpgqt
> 11/18 Test #11: examples_jpgqt ...***Failed 0.49 sec
>   Start 12: examples_pngqt
> 12/18 Test #12: examples_pngqt ...***Failed 0.62 sec
>   Start 13: examples_ppmqt
> 13/18 Test #13: examples_ppmqt ...***Failed 0.61 sec
>   Start 14: examples_tiffqt
> 14/18 Test #14: examples_tiffqt ..***Failed 0.51 sec
>   Start 15: examples_svgqt
> 15/18 Test #15: examples_svgqt ...***Failed 0.53 sec
>   Start 16: examples_epsqt
> 16/18 Test #16: examples_epsqt ...***Failed 0.62 sec
>   Start 17: examples_pdfqt
> 17/18 Test #17: examples_pdfqt ...***Failed 0.57 sec
>   Start 18: examples_compare
> 18/18 Test #18: examples_compare .   Passed 0.27 sec
> 
> 39% tests passed, 11 tests failed out of 18
> 
> Total Test time (real) =  83.71 sec
> The following tests FAILED:
>   7 - examples_pscairo (Failed)
>   8 - examples_pngcairo (Failed)
>   9 - examples_xfig (Failed)
>  10 - examples_bmpqt (Failed)
>  11 - examples_jpgqt (Failed)
>  12 - examples_pngqt (Failed)
>  13 - examples_ppmqt (Failed)
>      14 - examples_tiffqt (Failed)
>  15 - examples_svgqt (Failed)
>  16 - examples_epsqt (Failed)
>  17 - examples_pdfqt (Failed)
> 
> Cheers,
> Norm
> 
> On 03/18/2015 07:15 PM, Alan W. Irwin wrote:
> >On 2015-03-18 23:39- Andrew Ross wrote:
> >
> >>I'm a little uneasy about applying this patch so late in the release
> >>cycle
> >>in case there are any unforseen

Re: [Plplot-devel] fixed memory leak plplot-5.10.0

[Andrew Ross]

On Wed, Mar 18, 2015 at 11:10:20PM +, Andrew Ross wrote:
> On Wed, Mar 18, 2015 at 10:57:33PM +0000, Andrew Ross wrote:
> > On Wed, Mar 18, 2015 at 12:59:18AM -0700, Alan Irwin wrote:
> > > @Andrew: There are some really interesting release implications here,
> > > and if you feel Norman's fix (ideally in git am form as I have
> > > requested from him below) or some other variant of it you like is a
> > > no-brainer please go ahead and push it (see my further comment on the
> > > release delay implications at the end.).
> > 
> > Norman,
> > 
> > I'm not sure I agree with your patch here in general. I've tested it on
> > Linux and it makes no difference to my valgrind results. Further, adding
> > in some debugging statements shows that at the point you set plsc->tidy
> > the dispatch table entry is NULL anyway so your code makes no difference.
> > This is with dynamic drivers. Are you using static drivers? In that case
> > things may be different and we need to investigate more closely.
> > 
> > Also, looking at the code in plP_tidy, the tidy function
> > dispatch_table[dev - 1]->pl_tidy should already be called. Again debugging
> > statements show this is the case, so I can well see why you end up with a
> > double call for the psc driver if your change was having an effect. 
> > 
> > Can you confirm the build options you are using for plplot, and also the
> > precise way you ran valgrind to generate this feedback. Since I'm unable
> > to reproduce your results I'm a bit confused at precisely what the memory
> > issue is.
> > 
> 
> OK. To follow up my own post I think I now know what is going wrong. You
> fix is definitely wrong, because if you do compile without dynamic drivers
> then your code results in a double call to the tidy function. I was
> exiting the examples using return or 'Q', which results in stream_closed
> being set to 0 so the tidy function is called. If you exit by pressing the
> close button at the top of the xwin window however, then stream_closed = 1
> and so the tidy function is not called. This results in an additional memory 
> leak. I'll have a look how to fix that.
> 
> Norman, can you confirm that my interpretation of what you are doing is
> correct?

The attached patch fixes the memory leak for me. Pressing the close button
should now behave the same as pressing 'Q', i.e. it will abort the
program and clean up correctly. It looks like this was changed at some
stage in the past, but I don't know why. I guess this would allow a
programme to continue, and to potentially reopen a new xwin window. If we
want to retain this functionality it will require a bit more thinking
about. 

The relevant commit is

commit 9961465cb7b90c07c216f1a708b67d7a65753e11
Author: Hazen Babcock 
Date:   Mon May 31 00:46:56 2010 +

Change xwin driver to not call plexit() when the window is closed by
clicking on the close box. Instead all subsequent plotting commands sent
to the stream are ignored.

svn path=/trunk/; revision=11041

I'm a little uneasy about applying this patch so late in the release cycle
in case there are any unforseen consequences. The current situation will
result in a memory leak when closing the window with the button, but since
this is on exit anyway it should not be too serious. 

Andrew
>From 131ba88d300d311600dbd187fa4e04b9ebd5f57d Mon Sep 17 00:00:00 2001
From: Andrew Ross 
Date: Wed, 18 Mar 2015 23:24:38 +
Subject: [PATCH] Fix up closing of xwin driver when pressing the close window
 button to ensure the tidy function is called.

---
 drivers/xwin.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xwin.c b/drivers/xwin.c
index 982d28f..9b2e018 100644
--- a/drivers/xwin.c
+++ b/drivers/xwin.c
@@ -1523,9 +1523,9 @@ ClientEH( PLStream *pls, XEvent *event )
 if ( (Atom) event->xclient.data.l[0] == XInternAtom( xwd->display, "WM_DELETE_WINDOW", False ) )
 {
 pls->nopause= TRUE;
-pls->stream_closed  = TRUE;
+//pls->stream_closed  = TRUE;
 dev->exit_eventloop = TRUE;
-// plexit( "" );
+plexit( "" );
 }
 }
 
-- 
2.1.0

--
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] fixed memory leak plplot-5.10.0

[Andrew Ross]

On Wed, Mar 18, 2015 at 10:57:33PM +, Andrew Ross wrote:
> On Wed, Mar 18, 2015 at 12:59:18AM -0700, Alan Irwin wrote:
> > @Andrew: There are some really interesting release implications here,
> > and if you feel Norman's fix (ideally in git am form as I have
> > requested from him below) or some other variant of it you like is a
> > no-brainer please go ahead and push it (see my further comment on the
> > release delay implications at the end.).
> 
> Norman,
> 
> I'm not sure I agree with your patch here in general. I've tested it on
> Linux and it makes no difference to my valgrind results. Further, adding
> in some debugging statements shows that at the point you set plsc->tidy
> the dispatch table entry is NULL anyway so your code makes no difference.
> This is with dynamic drivers. Are you using static drivers? In that case
> things may be different and we need to investigate more closely.
> 
> Also, looking at the code in plP_tidy, the tidy function
> dispatch_table[dev - 1]->pl_tidy should already be called. Again debugging
> statements show this is the case, so I can well see why you end up with a
> double call for the psc driver if your change was having an effect. 
> 
> Can you confirm the build options you are using for plplot, and also the
> precise way you ran valgrind to generate this feedback. Since I'm unable
> to reproduce your results I'm a bit confused at precisely what the memory
> issue is.
> 

OK. To follow up my own post I think I now know what is going wrong. You
fix is definitely wrong, because if you do compile without dynamic drivers
then your code results in a double call to the tidy function. I was
exiting the examples using return or 'Q', which results in stream_closed
being set to 0 so the tidy function is called. If you exit by pressing the
close button at the top of the xwin window however, then stream_closed = 1
and so the tidy function is not called. This results in an additional memory 
leak. I'll have a look how to fix that.

Norman, can you confirm that my interpretation of what you are doing is
correct?

Thanks

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] fixed memory leak plplot-5.10.0

[Andrew Ross]

On Wed, Mar 18, 2015 at 12:59:18AM -0700, Alan Irwin wrote:
> @Andrew: There are some really interesting release implications here,
> and if you feel Norman's fix (ideally in git am form as I have
> requested from him below) or some other variant of it you like is a
> no-brainer please go ahead and push it (see my further comment on the
> release delay implications at the end.).

Norman,

I'm not sure I agree with your patch here in general. I've tested it on
Linux and it makes no difference to my valgrind results. Further, adding
in some debugging statements shows that at the point you set plsc->tidy
the dispatch table entry is NULL anyway so your code makes no difference.
This is with dynamic drivers. Are you using static drivers? In that case
things may be different and we need to investigate more closely.

Also, looking at the code in plP_tidy, the tidy function
dispatch_table[dev - 1]->pl_tidy should already be called. Again debugging
statements show this is the case, so I can well see why you end up with a
double call for the psc driver if your change was having an effect. 

Can you confirm the build options you are using for plplot, and also the
precise way you ran valgrind to generate this feedback. Since I'm unable
to reproduce your results I'm a bit confused at precisely what the memory
issue is.

Thanks

Andrew

> 
> On 2015-03-17 20:28-0700 Norman Goldstein wrote:
> 
> > I noticed that at the end of plSelectDev(), in plcore.c,
> > a couple more fields of the PLStream
> > needed to be filled in (feedback from valgrind :-)),
> > so I added these two lines at line 3230:
> >
> > plsc->tidy = (void*) dispatch_table[dev - 1]->pl_tidy;
> > plsc->tidy_data = (void*) plsc;
> >
> > I expect the first line is correct for all devices.
> > I think the 2nd line is OK, too (I checked it is correct for
> > XWindows, the only device I am using)
> >
> 
> Hi Norm:
> 
> As you are probably already aware, I plan to release a new version of
> PLplot soon based on the git master tip version so your test of that
> version (see access directions for master tip at
> https://sourceforge.net/p/plplot/plplot/ci/master/tree/) would be much
> appreciated.
> 
> Just to make sure we are on the same page, here is what I get for
> master tip for dev psc
> (using the CMake option -DBUILD_TEST=ON and following up with "make
> all" to build all the necessary prerequisites first.
> 
> software@raven> valgrind examples/c/x00c -dev psc -o test.psc
> ==9610== Memcheck, a memory error detector
> ==9610== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==9610== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==9610== Command: examples/c/x00c -dev psc -o test.psc
> ==9610== 
> ==9610== 
> ==9610== HEAP SUMMARY:
> ==9610== in use at exit: 0 bytes in 0 blocks
> ==9610==   total heap usage: 470 allocs, 470 frees, 132,943 bytes allocated
> ==9610== 
> ==9610== All heap blocks were freed -- no leaks are possible
> ==9610== 
> ==9610== For counts of detected and suppressed errors, rerun with: -v
> ==9610== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
> 
> i.e., perfect valgrind results.
> 
> And I also get perfect valgrind results for
> software@raven> valgrind examples/c/x00c -dev svg -o test.svg
> 
> Note that both psc and svg are non-interactive devices that have no
> external library dependencies.
> 
> In contrast, here are the -dev xwin results for the same (simple) example.
> 
> ==9758== Memcheck, a memory error detector
> ==9758== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==9758== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==9758== Command: examples/c/x00c -dev xwin
> ==9758== 
> ==9758== 
> ==9758== HEAP SUMMARY:
> ==9758== in use at exit: 42,535 bytes in 444 blocks
> ==9758==   total heap usage: 1,442 allocs, 998 frees, 434,710 bytes allocated
> ==9758== 
> ==9758== LEAK SUMMARY:
> ==9758==definitely lost: 88 bytes in 1 blocks
> ==9758==indirectly lost: 58 bytes in 2 blocks
> ==9758==  possibly lost: 0 bytes in 0 blocks
> ==9758==still reachable: 42,389 bytes in 441 blocks
> ==9758== suppressed: 0 bytes in 0 blocks
> ==9758== Rerun with --leak-check=full to see details of leaked memory
> ==9758== 
> ==9758== For counts of detected and suppressed errors, rerun with: -v
> ==9758== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
> 
> Do you also confirm this -dev xwin leak issue for master tip?
> 
> Assuming your answer is yes, does your above fix turn this into a
> perfect valgrind result (again for master tip) without compromising
> the perfect -dev svg and -dev psc results?
> 
> Also, if you have what you feel is a definitive fix, and you also have
> some git knowledge could you send it here using the "git am" command
> so we know exactly the change you want to make and so we can give you
> proper credit for your work?
> 
> On the other hand, If you don't have a lot of git exper

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-0000 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 <https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html>.
> 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-0000 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
> <https://sourceforge.net/p/plplot/bugs/155/>.  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

Re: [Plplot-devel] I would appreciate some help tracking down the cause of a -DPLPLOT_USE_QT5=ON segfault

[Andrew Ross]

On Fri, Mar 13, 2015 at 10:26:12AM -0700, Alan Irwin wrote:
> On 2015-03-13 10:19-0000 Andrew Ross wrote:
> 
> >[] I've been running into further problems even after
> >fixing the dependencies as you suggested.
> >
> >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/)
> >
> >2) The libharu build succeeds, but the hpdf_pdfa.h include file is not
> >installed so the plplot build of the pdf driver fails. I don't have
> >time to investigate further. Just installing the debian packages is a
> >workaround.
> 
> Hi Andrew:
> 
> I will take a quick look at (1) and (2) above to see if there is
> anything simple I can do today to fix these other epa_build issues
> that you have found, but if they are difficult I will leave
> them to post-release.
> 
> >
> >I did get Qt5 to build under epa (this is before your latest commit)
> >and so I did a separate build, put pointing cmake to this epa version.
> >This worked and the valgrind test results are below. I did not see any
> >invalid read errors. I did get a warning about xbd though, and return
> >did not seem to work to exit the plot page. I had to use the right
> >mouse button instead. This may well be related to my pbuilder
> >environment, though I didn't get the message with the debian package.
> 
> Hmm. That means there is a real difference between the epa_built
> Qt5.3.2 and Debian unstable Qt5.3.2 libraries which is presumably
> caused by the Debian patches to Qt 5.3.2 or the compiler optimization
> difference (the only real differences between the two results that I
> am aware of). Also, I just double-checked, and I get the invalid read
> for the epa_built Qt5.3.2 on Debian stable regardless of whether I use
> return or right click to exit the plot. And if that invalid read
> manages (by chance) not to trigger a segfault, both those actions exit
> the plot page fine. When you combine these variety of
> platform-dependent symptoms for 5.3.2 with previous terrible 5.3.0
> results reported by one of our users, and the on-going character
> offset issues (which are mostly compensated by an empirical vertical
> adjustment we apply for the Qt5 case), I think the inevitable
> conclusion is that Qt5.3.x is still flaky/immature. Thus, I am going
> to mention in the release notes that PLplot users should use the
> -DPLPLOT_USE_QT5=ON option with a lot of caution and if they run into
> any difficulties because of Qt5 flakiness, they should stick with Qt4
> instead.
> 
> >
> >Anyway, the key message is that even with an epa_build of Qt5 I do
> >not see the error so it is not an intrinsic Qt5 / plplot problem,
> >but something different between our setups is causing problems.
> 
> Thanks very much for all your hard work to arrive at this important
> conclusion (since memory management issues are a fundamental bane to
> run-time repeatibility/stability) that the invalid read for Qt5
> appears to be limited to Debian stable and thus has nothing to do with
> epa_build or PLplot issues.

Alan,

If I have time (may be post release) I will repeat my tests with Debian 
stable to see whether it is the Debian stable / unstable that is the 
difference, or whether it is something about our specific hardware / 
build environment. 

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] I would appreciate some help tracking down the cause of a -DPLPLOT_USE_QT5=ON segfault

[Andrew Ross]

On Fri, Mar 13, 2015 at 12:12:19AM -0700, Alan Irwin wrote:
> On 2015-03-12 01:46-0700 Alan W. Irwin wrote:
> 
> > For Debian stable, I got most of the required Qt5 build-depends by
> > installing the build-depends of the Qt4 source package, then following
> > up by iterating epa_builds to get the extra ones needed for the
> > epa_build of Qt5.  But I think the whole deal could be completed by
> > just one "apt-get build-dep" command for you with no further
> > iterations required since the Debian unstable version of Qt5 is
> > virtually identical to what is used by epa_build.
> 
> Hi Andrew:
> 
> The configuration changes for the epa_build of Qt5 that I pushed
> (commit id = cfc6e135) on Tuesday made sure virtually all components
> of Qt5 were built, but those extra components did not solve the memory
> management issue (in fact introduced some extra warnings related to
> dbus, etc.,) so now I have experimentally gone the other way (commit
> id = fd4ef4a) and reduced the epa_build of Qt5 to the absolute minimum
> components needed by PLplot. (For example, dbus is excluded.) As a
> result of these changes, the time required here to epa_build Qt5 has
> been reduced from 2 hours to 13.5 minutes!  As expected from previous
> experience with the insensitivity of the memory management issue to
> Qt5 build configuration, the valgrind results are essentially the same
> as before; relatively clean for all Qt file devices that I sampled,
> and a single invalid read error on plend for -dev qtwidget.
> 
> To access that dramatic speedup in the epa_build of Qt5 (and many
> fewer library dependencies of that build) use the latest master tip
> version of PLplot.

Thanks. Actually I've been running into further problems even after
fixing the dependencies as you suggested.

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/)

2) The libharu build succeeds, but the hpdf_pdfa.h include file is not
installed so the plplot build of the pdf driver fails. I don't have
time to investigate further. Just installing the debian packages is a 
workaround.

I did get Qt5 to build under epa (this is before your latest commit) 
and so I did a separate build, put pointing cmake to this epa version.
This worked and the valgrind test results are below. I did not see any 
invalid read errors. I did get a warning about xbd though, and return 
did not seem to work to exit the plot page. I had to use the right 
mouse button instead. This may well be related to my pbuilder 
environment, though I didn't get the message with the debian package.

Anyway, the key message is that even with an epa_build of Qt5 I do 
not see the error so it is not an intrinsic Qt5 / plplot problem,
but something different between our setups is causing problems.

Andrew

root@andrew-laptop:~/software/plplot/build_test# valgrind examples/c/x01c -dev 
qtwidget
==5793== Memcheck, a memory error detector
==5793== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==5793== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==5793== Command: examples/c/x01c -dev qtwidget
==5793== 
PLplot library version: 5.10.0
xkbcommon: ERROR: failed to add default include path auto
Qt: Failed to create XKB context!
Use QT_XKB_CONFIG_ROOT environmental variable to provide an additional search 
path, add ':' as separator to provide several search paths and/or make sure 
that XKB configuration data directory contains recent enough contents, to 
update please see http://cgit.freedesktop.org/xkeyboard-config/ .
==5799== Warning: invalid file descriptor 1024 in syscall close()
==5799== Warning: invalid file descriptor 1025 in syscall close()
==5799== Warning: invalid file descriptor 1026 in syscall close()
==5799== Warning: invalid file descriptor 1027 in syscall close()
==5799==Use --log-fd= to select an alternative log fd.
==5799== Warning: invalid file descriptor 1028 in syscall close()
==5799== Warning: invalid file descriptor 1029 in syscall close()
==5799== 
==5799== HEAP SUMMARY:
==5799== in use at exit: 240,274 bytes in 974 blocks
==5799==   total heap usage: 5,483 allocs, 4,509 frees, 854,919 bytes allocated
==5799== 
==5799== LEAK SUMMARY:
==5799==definitely lost: 2,476 bytes in 10 blocks
==5799==indirectly lost: 24 bytes in 1 blocks
==5799==  possibly lost: 0 bytes in 0 blocks
==5799==still reachable: 237,774 bytes in 963 blocks
==5799== suppressed: 0 bytes in 0 blocks
==5799== Rerun with --leak-check=full to see details of leaked memory
==5799== 
==5799== For counts of detected and suppressed errors, rerun with: -v
==5799== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==5793== 
==5793== HEAP SUMMARY:
==5793== in use at exit: 40,997 bytes in 166 blocks
==5793==   total heap usage: 39,484 allocs, 39,318 frees, 12,951,762 bytes 
allocated
==5793== 
==5793== LEAK SUMMARY:
==5793==definitely lost: 2,254 byte

Re: [Plplot-devel] I would appreciate some help tracking down the cause of a -DPLPLOT_USE_QT5=ON segfault

[Andrew Ross]

On Wed, Mar 11, 2015 at 05:38:47PM -0700, Alan Irwin wrote:
> On 2015-03-11 22:32-0000 Andrew Ross wrote:
> 
> > On Wed, Mar 11, 2015 at 02:55:16PM -0700, Alan Irwin wrote:
> >> On 2015-03-11 21:29- Andrew Ross wrote:
> >>
> >>> A minimal C / C++ / qt5 build of plplot on debian unstable produces the
> >>> output below. No invalid reads though. I suspect the DRM warnings are
> >>> because I'm building in a chrooted pbuilder environment. So unless the
> >>> problem lies in the DRM support, it looks like the issue is not present
> >>> in debian unstable with 5.3.2 (the current package is 5.3.2+dfsg-4+b1).
> >>
> >> That's an extremely encouraging result.
> >>
> >> Is this test for the system version of Qt5?  If so, could you also do
> >> the equivalent epa_build test on Debian unstable to finally put this
> >> issue to rest?
> >
> > I can. It will just be exceedingly slow.
> 
> I look forward to those results.
> 
> > Incidentally, when I tried I discovered that the epa_build of lasi still
> > points to a local copy on your machine not a download. This will cause
> > epa_build to fail and is likely to confuse any non-expert users.
> 
> Gack.  Thanks for drawing my attention to this issue which I could not
> see for myself because it was an archetypal bad case of "works for
> me". I have just fixed it (commit id = daf1072), and I also checked
> that there were no other file URL issues like it in epa_build.

Turned out to be a slow business. On a base Debian install there are a 
lot of required packages not installed as I discovered one by one. I've
now hit a build failure which I need to investigate. No time today, but 
I'll try and look tomorrow / the weekend.

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] I would appreciate some help tracking down the cause of a -DPLPLOT_USE_QT5=ON segfault

[Andrew Ross]

On Wed, Mar 11, 2015 at 02:55:16PM -0700, Alan Irwin wrote:
> On 2015-03-11 21:29-0000 Andrew Ross wrote:
> 
> > A minimal C / C++ / qt5 build of plplot on debian unstable produces the
> > output below. No invalid reads though. I suspect the DRM warnings are
> > because I'm building in a chrooted pbuilder environment. So unless the
> > problem lies in the DRM support, it looks like the issue is not present
> > in debian unstable with 5.3.2 (the current package is 5.3.2+dfsg-4+b1).
> 
> That's an extremely encouraging result.
> 
> Is this test for the system version of Qt5?  If so, could you also do
> the equivalent epa_build test on Debian unstable to finally put this
> issue to rest?

I can. It will just be exceedingly slow. 

I don't think it quite puts the issue to rest. It _could_ be a opengl / 
drm related issue which is not getting triggered in my pbuilder setup, 
but is in your real install. At least we'll know it is not a plplot
problem I suppose which is a relief.

Incidentally, when I tried I discovered that the epa_build of lasi still 
points to a local copy on your machine not a download. This will cause 
epa_build to fail and is likely to confuse any non-expert users. 

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

[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

Re: [Plplot-devel] Release status

[Andrew Ross]

Phil,

Try reading http://wiki.tcl.tk/1829 for the tk problem. It suggests an 
issue with your X security which you probably want to investigate anyway.

For me things "just work" with Ubuntu. Though I should perhaps be more
precise that it is Kubuntu (with KDE as the window manager) that I use 
rather than vanilla Ubuntu. I'd be very surprised if X was not set up 
securely by default though.

Andrew

On Wed, Mar 11, 2015 at 08:35:50PM +, Phil Rosenberg wrote:
> 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.
> 
> Phil
> 
> On 11 March 2015 at 19:27, Alan W. Irwin  wrote:
> > On 2015-03-11 12:32- Arjen Markus wrote:
> >
> >> Hi Phil,
> >
> >
> >> The message is due to a security problem in the X server if you use
> >
> > the default security settings. I know of it but I do not have a handy
> > receipe to solve it. Tk's send command allows you to send any command
> > to the X host, which is why this message pops up.
> >
> > Hi Phil:
> >
> > I think Arjen is right.  Hopefully Andrew (who uses Ubuntu a lot for
> > testing) will know the recipe to properly authorize -dev tk on Ubuntu.  For
> > some reason I have never run into this authorization issue on Debian
> > stable, but that is probably because (by design) Debian default
> > security settings are quite weak.
> >
> > I also noticed in another message that you presumably had solved that
> > authorization issue and found a commit (id = 1e402417c1f) that your
> > tests showed introduced a -dev tk rendering regression, but I cannot
> > figure out what that regression might be so could you describe it?
> >
> > The issue is that both 1e402417c1f^ and 1e402417c1f give single GUI
> > -dev tk results here that both look fine to me (other than the zoom
> > issue) for example 1 while for master tip I get two GUI's (one with
> > the Tk decorations and no plot, and the other an undecorated xwin-like
> > plot).  I have attached a screenshot of that master tip result so you will
> > know exactly what I am referring too.
> >
> > I will now do my own git bisects to find when the zoom issue was
> > introduced and when the two-GUI issue was introduced.
> >
> >
> > 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] I would appreciate some help tracking down the cause of a -DPLPLOT_USE_QT5=ON segfault

[Andrew Ross]

On Wed, Mar 11, 2015 at 08:24:17PM +, Andrew Ross wrote:
> On Tue, Mar 10, 2015 at 06:36:42PM -0700, Alan Irwin wrote:
> > On 2015-03-03 17:09-0800 Alan W. Irwin wrote:
> > 
> > >I think valgrind would report a serious issue like invalid read
> > >regardless of command-line options so I think the best summary of the
> > >situation is valgrind reports invalid reads with epa_built Qt 5.3.1
> > >and 5.3.2 and does not report such issues with Ubuntu-built (and
> > >patched) Qt5 5.3.0.
> > >
> > >So thanks to your report my working hypothesis now is that the
> > >configuration of the epa_built Qt5 is somehow to blame here even
> > >though there are no warnings about the configuration options that I
> > >use in the Qt5 build log.
> > >
> > >My next step is I am going to download the Qt5 build configuration
> > >used by Debian testing and/or Ubuntu to see if I can spot some key
> > >configuration option that epa_build is missing for Qt5.3.x.
> > 
> > Hi Andrew:
> > 
> > The short story is that step did not work.
> > 
> > Here is the longer version of the story with a request for two
> > additional tests (one short one long) by you at the end.
> > 
> > If you have access to Debian testing, it would be great if you
> > repeated the valgrind test with their binary version of Qt5 (5.3.2)
> > which is very much closer to my epa_built version.  And if you have a
> > spare couple of hours of cpu on a Debian testing platform, it would
> > also be extremely interesting to see if the epa_built version of Qt5
> > did not have any memory management issues on Debian testing since if
> > that proved to be the case I could write this off to Debian stable
> > issues (i.e., the current working hypothesis) and sleep better at
> > night.  :-)
> > 
> > Meanwhile, if you can think of anything else I should try with the
> > epa_built version of Qt5 on Debian stable, please let me know.
> 
> I'm also stumped! I'll try building in my Debian unstable pbuilder 
> environment and report back. This is as close as I can get and should
> (hopefully) help isolate the problem.

A minimal C / C++ / qt5 build of plplot on debian unstable produces the 
output below. No invalid reads though. I suspect the DRM warnings are 
because I'm building in a chrooted pbuilder environment. So unless the 
problem lies in the DRM support, it looks like the issue is not present 
in debian unstable with 5.3.2 (the current package is 5.3.2+dfsg-4+b1).

Andrew

root@andrew-laptop:~/software/plplot/build_sid# valgrind examples/c/x01c -dev 
qtwidget
==14430== Memcheck, a memory error detector
==14430== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==14430== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==14430== Command: examples/c/x01c -dev qtwidget
==14430== 
PLplot library version: 5.10.0
libGL error: failed to open drm device: No such file or directory
libGL error: failed to load driver: i965
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
process 14430: D-Bus library appears to be incorrectly set up; failed to read 
machine uuid: Failed to open "/etc/machine-id": No such file or directory
See the manual page for dbus-uuidgen to correct this issue.
==14438== Warning: invalid file descriptor 1024 in syscall close()
==14438== Warning: invalid file descriptor 1025 in syscall close()
==14438== Warning: invalid file descriptor 1026 in syscall close()
==14438== Warning: invalid file descriptor 1027 in syscall close()
==14438==Use --log-fd= to select an alternative log fd.
==14438== Warning: invalid file descriptor 1028 in syscall close()
==14438== Warning: invalid file descriptor 1029 in syscall close()
==14438== 
==14438== HEAP SUMMARY:
==14438== in use at exit: 371,780 bytes in 3,118 blocks
==14438==   total heap usage: 8,976 allocs, 5,858 frees, 1,241,797 bytes 
allocated
==14438== 
==14438== LEAK SUMMARY:
==14438==definitely lost: 2,476 bytes in 10 blocks
==14438==indirectly lost: 24 bytes in 1 blocks
==14438==  possibly lost: 4,676 bytes in 83 blocks
==14438==still reachable: 364,604 bytes in 3,024 blocks
==14438== suppressed: 0 bytes in 0 blocks
==14438== Rerun with --leak-check=full to see details of leaked memory
==14438== 
==14438== For counts of detected and suppressed errors, rerun with: -v
==14438== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14430== 
==14430== HEAP SUMMARY:
==14430== in use at exit: 198,976 bytes in 3,013 blocks
==14430==   total heap usage: 31,133 allocs, 28,120 frees, 7,033,974 bytes 
allocated
==14430== 
==14430== LEAK SUMMARY:
==14430==definitely lost: 3,064 bytes in 41 blocks
==14430==i

Re: [Plplot-devel] I would appreciate some help tracking down the cause of a -DPLPLOT_USE_QT5=ON segfault

[Andrew Ross]

On Tue, Mar 10, 2015 at 06:36:42PM -0700, Alan Irwin wrote:
> On 2015-03-03 17:09-0800 Alan W. Irwin wrote:
> 
> >I think valgrind would report a serious issue like invalid read
> >regardless of command-line options so I think the best summary of the
> >situation is valgrind reports invalid reads with epa_built Qt 5.3.1
> >and 5.3.2 and does not report such issues with Ubuntu-built (and
> >patched) Qt5 5.3.0.
> >
> >So thanks to your report my working hypothesis now is that the
> >configuration of the epa_built Qt5 is somehow to blame here even
> >though there are no warnings about the configuration options that I
> >use in the Qt5 build log.
> >
> >My next step is I am going to download the Qt5 build configuration
> >used by Debian testing and/or Ubuntu to see if I can spot some key
> >configuration option that epa_build is missing for Qt5.3.x.
> 
> Hi Andrew:
> 
> The short story is that step did not work.
> 
> Here is the longer version of the story with a request for two
> additional tests (one short one long) by you at the end.
> 
> If you have access to Debian testing, it would be great if you
> repeated the valgrind test with their binary version of Qt5 (5.3.2)
> which is very much closer to my epa_built version.  And if you have a
> spare couple of hours of cpu on a Debian testing platform, it would
> also be extremely interesting to see if the epa_built version of Qt5
> did not have any memory management issues on Debian testing since if
> that proved to be the case I could write this off to Debian stable
> issues (i.e., the current working hypothesis) and sleep better at
> night.  :-)
> 
> Meanwhile, if you can think of anything else I should try with the
> epa_built version of Qt5 on Debian stable, please let me know.

I'm also stumped! I'll try building in my Debian unstable pbuilder 
environment and report back. This is as close as I can get and should
(hopefully) help isolate the problem.

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] I would appreciate some help tracking down the cause of a -DPLPLOT_USE_QT5=ON segfault

[Andrew Ross]

OK. Here's my results for your precise tests - completely clean.

andrew@andrew-laptop:~/software/plplot/build_qt5$ ldd -r drivers/qt.so |& grep 
-i qt
libQt5Svg.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Svg.so.5 
(0x7f09fff34000)
libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 
(0x7f09ff801000)
libplplot.so.12 => 
/home/andrew/software/plplot/build_qt5/src/libplplot.so.12 (0x7f09ff56f000)
libplplotqt.so.1 => 
/home/andrew/software/plplot/build_qt5/bindings/qt_gui/libplplotqt.so.1 
(0x7f09ff34c000)
libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 
(0x7f09feafc000)
libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 
(0x7f09fe3c5000)
libcsirocsa.so.0 => 
/home/andrew/software/plplot/build_qt5/lib/csa/libcsirocsa.so.0 
(0x7f09fc5d7000)
libcsironn.so.0 => 
/home/andrew/software/plplot/build_qt5/lib/nn/libcsironn.so.0 
(0x7f09fc3cc000)
libqsastime.so.0 => 
/home/andrew/software/plplot/build_qt5/lib/qsastime/libqsastime.so.0 
(0x7f09fc1c3000)
libQt5PrintSupport.so.5 => 
/usr/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5 (0x7f09fbf53000)

andrew@andrew-laptop:~/software/plplot/build_qt5$ ldd -r 
examples/c++/qt_example |& grep -i qt
libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 
(0x7f5cc7904000)
libplplotqt.so.1 => 
/home/andrew/software/plplot/build_qt5/bindings/qt_gui/libplplotqt.so.1 
(0x7f5cc76e)
libplplot.so.12 => 
/home/andrew/software/plplot/build_qt5/src/libplplot.so.12 (0x7f5cc744e000)
libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 
(0x7f5cc6bff000)
libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 
(0x7f5cc64c7000)
libQt5Svg.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Svg.so.5 
(0x7f5cc4d58000)
libQt5PrintSupport.so.5 => 
/usr/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5 (0x7f5cc4ae8000)
libcsirocsa.so.0 => 
/home/andrew/software/plplot/build_qt5/lib/csa/libcsirocsa.so.0 
(0x7f5cc421c000)
libcsironn.so.0 => 
/home/andrew/software/plplot/build_qt5/lib/nn/libcsironn.so.0 
(0x7f5cc4011000)
libqsastime.so.0 => 
/home/andrew/software/plplot/build_qt5/lib/qsastime/libqsastime.so.0 
(0x7f5cc3e09000)

andrew@andrew-laptop:~/software/plplot/build_qt5$ valgrind examples/c/x01c -dev 
qtwidget
==26547== Memcheck, a memory error detector
==26547== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26547== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==26547== Command: examples/c/x01c -dev qtwidget
==26547== 
PLplot library version: 5.10.0
==26547== 
==26547== HEAP SUMMARY:
==26547== in use at exit: 1,170,008 bytes in 8,191 blocks
==26547==   total heap usage: 85,719 allocs, 77,528 frees, 14,358,512 bytes 
allocated
==26547== 
==26547== LEAK SUMMARY:
==26547==definitely lost: 10,006 bytes in 77 blocks
==26547==indirectly lost: 1,005,606 bytes in 7,311 blocks
==26547==  possibly lost: 4,676 bytes in 83 blocks
==26547==still reachable: 149,720 bytes in 720 blocks
==26547== suppressed: 0 bytes in 0 blocks
==26547== Rerun with --leak-check=full to see details of leaked memory
==26547== 
==26547== For counts of detected and suppressed errors, rerun with: -v
==26547== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)

iandrew@andrew-laptop:~/software/plplot/build_qt5$ valgrind 
examples/c++/qt_example 
==26675== Memcheck, a memory error detector
==26675== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26675== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==26675== Command: examples/c++/qt_example
==26675== 
==26675== 
==26675== HEAP SUMMARY:
==26675== in use at exit: 1,202,784 bytes in 8,319 blocks
==26675==   total heap usage: 99,582 allocs, 91,263 frees, 18,785,515 bytes 
allocated
==26675== 
==26675== LEAK SUMMARY:
==26675==definitely lost: 10,220 bytes in 113 blocks
==26675==indirectly lost: 510,106 bytes in 7,345 blocks
==26675==  possibly lost: 507,536 bytes in 84 blocks
==26675==still reachable: 174,922 bytes in 777 blocks
==26675== suppressed: 0 bytes in 0 blocks
==26675== Rerun with --leak-check=full to see details of leaked memory
==26675== 
==26675== For counts of detected and suppressed errors, rerun with: -v
==26675== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 1)






On Tue, Mar 03, 2015 at 05:09:25PM -0800, Alan Irwin wrote:
> Hi Andrew:
> 
> Thanks for helping out.  More below in context:
> 
> On 2015-03-03 22:03- Andrew Ross wrote:
> 
> >
> >Alan,
> >
> >As a further reference point, I've tried with Qt5 on Ubuntu 14.10 (this is
> >5.3.0) and I get lots of lost / still reachable memory issues,

Re: [Plplot-devel] I would appreciate some help tracking down the cause of a -DPLPLOT_USE_QT5=ON segfault

[Andrew Ross]

Alan,

As a further reference point, I've tried with Qt5 on Ubuntu 14.10 (this is 
5.3.0) and I get lots of lost / still reachable memory issues, but no 
invalid reads (which I think was your concern). Just to be absolutely 
clear, I've tested

valgrind --leak-check=full --log-file=log --trace-children=yes ./x01c -dev 
qtwidget

and also the c++ qt_example.

Does this correspond to your test?

Andrew

On Mon, Mar 02, 2015 at 01:14:09PM -0800, Alan Irwin wrote:
> See  for the details of what I
> know about this memory management bug for -DPLPLOT_USE_QT5=ON so far.
> 
> One limitation of my testing is it is for epa_built versions of Qt5
> (both 5.3.1 and 5.3.2), and it is conceivable there is some
> misconfiguration of the Qt5 epa_build (although there were no
> warnings about that in the build logs.)
> 
> So to help eliminate that possibility could someone here with access
> to a Linux installation of Qt5 try (for -DPLPLOT_USE_QT5=ON) running
> valgrind for both the -dev wxwidgets and qt_example cases to see if
> you can replicate the memory management issues I am seeing for the
> epa_built case?  For example, from
> 
> and 
> 
> I notice qt5 is in Debian testing (Jessie) and Ubuntu trusty and
> later, and I assume Qt5 has also made it into the latest Fedora
> versions as well.  So if you have access to one of those Linux
> distros, I would appreciate some verification of these valgrind issues
> I see for the epa_built cases.
> 
> Of course, if we do get that verification, then it is still not clear
> whether these memory management issues are due to some incompatibility
> between qt and Qt5 (i.e., the pattern of Qt library calls that work so
> well in the Qt4 case might not be correct usage in the Qt5 case) or
> some issue with Qt5 alone.
> 
> 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

Re: [Plplot-devel] Redesigned wxWidgets Driver

[Andrew Ross]

t;>> I have hit a bit of a snag with the wxWidgets driver and would like some
> >>>> advice.
> >>>>
> >>>> At some point the driver has to make a decision as to whether the user
> >>>> is going to pass the driver a wxDC to draw on, or whether the driver
> >>>> has to execute wxPLViewer to do the drawing.
> >>>>
> >>>> An ideal point to do that would be the first call to plP_bop(). It
> >>>> feels right that at this point when the first rendering begins to
> >>>> clear the page that by this point the decision should be made and
> >>>> technically if we leave it until after this point then we have to
> >>>> somehow replay the begin of page call, which it turns out can't be
> >>>> done by simply replaying the buffer.
> >>>>
> >>>> However plP_bop() is called from c_plinit, so there is no opportunity
> >>>> for the user to actually pass in the wxDC.
> >>>>
> >>>> To me it would make sense to call plP_bop when pladv() is first
> >>>> called, i.e. at the point at which the user decides to begin the first
> >>>> page. This is also symmetric with other calls to plP_bop which happen
> >>>> at page advances. However I don't know if this is would it totally
> >>>> mess up other devices? I have looked as carefully as I can and there
> >>>> doesn't appear to be any requirement within c_plinit for plP_bop() to
> >>>> be called.
> >>>>
> >>>> Any thoughts anyone?
> >>>>
> >>>>
> >>>> On 25 February 2015 at 23:06, Andrew Ross
> >>>>  wrote:
> >>>>> On Wed, Feb 25, 2015 at 12:16:02PM +, Phil Rosenberg wrote:
> >>>>>> Hi Alan
> >>>>>>>
> >>>>>>> It appears there are two remaining release-critical issues.
> >>>>>>>
> >>>>>>> 1. You should do one last check of Ubuntu and CentOS to make sure my
> >>>>>>> recent drop of explicit linking to the rt library does not cause
> >>>>>>> problems on those platforms.  (And if it does, a one-line change
> >>>>>>> should fix it).
> >>>>>>
> >>>>>> I have checked this on Centos and it works fine. I can check on Ubuntu
> >>>>>> this evening.
> >>>>>
> >>>>> I've checked on my Ubuntu machine and your latest patch fixes things
> >>>>> again for me.
> >>>>>
> >>>>>>>
> >>>>>>> 2. I haven't experienced xwin crashes myself. Could you give me an
> >>>>>>> explicit test that fails for you so I can verify this regression?
> >>>>>>
> >>>>>> I rebuilt in a new build tree on Centos and I still get this. Sorry I
> >>>>>> hadn't looked at the error in detail before as I was in the middle of
> >>>>>> something else. In both case the error is a double free or corruption.
> >>>>>> In x13c I get a gdb backtrace, which points me to plP_fill, in x15c I
> >>>>>> just get a segmentation fault message. In x13 and x15 (c++) I get a
> >>>>>> backtrace which again points to plP_fill.
> >>>>>>
> >>>>>> By the looks of it plP_fill has no free calls, so I expect this is
> >>>>>> some memory overflow or bad pointer issue. As I am using the intel
> >>>>>> compiler it probably arranges things in memory differently to gcc, so
> >>>>>> perhaps that is why you aren't seeing this.
> >>>>>
> >>>>> As another data point, I do not see this behaviour on Ubuntu 14.10.
> >>>>>
> >>>>> 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
> 
> --
> 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] Redesigned wxWidgets Driver

[Andrew Ross]

On Wed, Feb 25, 2015 at 12:16:02PM +, Phil Rosenberg wrote:
> Hi Alan
> >
> > It appears there are two remaining release-critical issues.
> >
> > 1. You should do one last check of Ubuntu and CentOS to make sure my
> > recent drop of explicit linking to the rt library does not cause
> > problems on those platforms.  (And if it does, a one-line change
> > should fix it).
> 
> I have checked this on Centos and it works fine. I can check on Ubuntu
> this evening.

I've checked on my Ubuntu machine and your latest patch fixes things 
again for me.

> >
> > 2. I haven't experienced xwin crashes myself. Could you give me an
> > explicit test that fails for you so I can verify this regression?
> 
> I rebuilt in a new build tree on Centos and I still get this. Sorry I
> hadn't looked at the error in detail before as I was in the middle of
> something else. In both case the error is a double free or corruption.
> In x13c I get a gdb backtrace, which points me to plP_fill, in x15c I
> just get a segmentation fault message. In x13 and x15 (c++) I get a
> backtrace which again points to plP_fill.
> 
> By the looks of it plP_fill has no free calls, so I expect this is
> some memory overflow or bad pointer issue. As I am using the intel
> compiler it probably arranges things in memory differently to gcc, so
> perhaps that is why you aren't seeing this.

As another data point, I do not see this behaviour on Ubuntu 14.10. 

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] Mail delivery delays by SF

[Andrew Ross]

Alan,

I think it was a transient problem. I've had a load of delayed messages 
come through this evening after a long delay. At least one was only to 
plplot-devel, with no other recipients. 

Andrew

On Wed, Feb 25, 2015 at 12:05:06PM -0800, Alan Irwin wrote:
> On 2015-02-25 11:28-0800 Alan W. Irwin wrote:
> 
> > On 2015-02-25 11:24-0800 Alan W. Irwin wrote:
> >
> >> I am doing an additional test with this e-mail where I am sending it
> >> to several principal addresses (including plplot-devel) to see if that
> >> method (avoiding CC's but with multiple recipients) works instantly.
> >
> > This also was delivered instantly by SF to me.
> >
> > One more test with this e-mail where plplot-devel is in the To: list
> > but everyone else in the Cc: list.
> 
> For this case, mail delivery was delayed by ~10 minutes or so, but it
> did get through.  So it appears the only problematic pattern (where
> delivery is delayed by at least several days and may be dropped)
> is when plplot-devel is on the Cc list.
> 
> So from now on when I want to copy information to plplot-devel I will
> always do that using the To list rather than the Cc list, and I
> suggest others here might want to do the same.
> 
> In fact, unless I forget I will probably just quit using the Cc list
> altogether for PLplot related e-mails since it is clear that SF (or
> perhaps my ISP) delays delivery in that case (if only for 10 minutes or
> so).
> 
> 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

Re: [Plplot-devel] Soft freeze declared now + release preparation plans

[Andrew Ross]

On Tue, Feb 24, 2015 at 10:18:52PM +, Andrew Ross wrote:
> On Mon, Feb 23, 2015 at 08:14:02PM -0800, Alan Irwin wrote:
> > On 2015-02-24 00:27-0000 Andrew Ross wrote:
> > 
> > >I also noticed that while most devices (svg, cairo) left align
> > >multi-line text, the qt devices seem to centre align it. This needs further
> > >investigation, but is probably not a show-stopper.
> > 
> > Could you write this up on the bugtracker, please?  Also, please state
> > there for which example you noticed this issue so I can try to confirm
> > the issue here.
> 
> Have done.
> 
> One more for the list:
> 
> Example 2, page 2. The characters are all too large and extend beyond 
> the boxes. This is (I think) a fairly recent regression as I've not
> noticed it before. It seems to occur for all devices.

I've tracked this one down to a recent change as part of the plbuf 
updates. Now fixed. It's the first time I've tried git bisect. 
Exceedingly useful!

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] Soft freeze declared now + release preparation plans

[Andrew Ross]

On Mon, Feb 23, 2015 at 08:14:02PM -0800, Alan Irwin wrote:
> On 2015-02-24 00:27-0000 Andrew Ross wrote:
> 
> >I also noticed that while most devices (svg, cairo) left align
> >multi-line text, the qt devices seem to centre align it. This needs further
> >investigation, but is probably not a show-stopper.
> 
> Could you write this up on the bugtracker, please?  Also, please state
> there for which example you noticed this issue so I can try to confirm
> the issue here.

Have done.

One more for the list:

Example 2, page 2. The characters are all too large and extend beyond 
the boxes. This is (I think) a fairly recent regression as I've not
noticed it before. It seems to occur for all devices.

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] [plplot:plplot] [91d567] - Alan W. Irwin: wxPLViewer: drop explicit link to the rt library

[Andrew Ross]

On Tue, Feb 24, 2015 at 07:13:24PM +, Repository PLplot plplot.git wrote:
> master: wxPLViewer: drop explicit link to the rt library
> 
> That explicit link causes trouble on Mac OS X (which does not
> support the rt library even though that is a POSIX standard)
> and is not required on Debian stable.  Testing of additional
> Linux systems like Ubuntu and CentOS may show rt has to
> be explicitly linked in one/both of those cases in which
> case the fix is to uncomment one statement.

Alan - this "fix" breaks linkage on Ubuntu 14.10 with the error

Linking CXX executable wxPLViewer
/usr/bin/ld: CMakeFiles/wxPLViewer.dir/__/drivers/wxwidgets_comms.cpp.o: 
undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/librt.so.1: error adding symbols: DSO missing from 
command line

Uncommenting line 88 in utils/CMakeLists.txt to explicitly link in the rt 
library fixes this. o

I'm surprised this is a difference between Ubuntu and Debian since they 
are usually similar. I would suggest we leave this uncommented since it
seems to treat the problematic MacOSX case separately anyway.

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] Soft freeze declared now + release preparation plans

[Andrew Ross]

On Mon, Feb 23, 2015 at 08:14:02PM -0800, Alan Irwin wrote:
> On 2015-02-24 00:27-0000 Andrew Ross wrote:
> 
> >[]P.S. Make test_noninteractive also works successfully. I've sampled a 
> >few
> >images and only noticed a couple of issues.
> >
> >The psc driver does not handle the \n in the calls to plmaptex in example
> >19, page 5. I only spotted this having been looking at the svg output to
> >fix the f95 regression.
> 
> Confirmed.
> 
> >
> >The pdf driver also does not handle the \n on that page.
> 
> Confirmed.
> >
> >The pdf driver also has a problem with ludicrously small text it is
> >unreadable without a large zoom on some plots. The really small text is
> >noticeable in examples 19, 23, 28 at least. It seems to be anything
> >plotted with plptex, plmaptex is too small. Other text is fine.
> 
> Confirmed.
> 
> I would be happy to be surprised otherwise, but I doubt any of these
> issues that we have jointly confirmed will be dealt with before the
> release.  Therefore, I have written up all of them on the bugtracker
> so we won't forget about them.
> 
> >
> >I also noticed that while most devices (svg, cairo) left align
> >multi-line text, the qt devices seem to centre align it. This needs further
> >investigation, but is probably not a show-stopper.
> 
> Could you write this up on the bugtracker, please?  Also, please state
> there for which example you noticed this issue so I can try to confirm
> the issue here.

Example 19, page 5. This is the only place multi-line text is used. This 
is a feature we've just never used before until Phil introduced it with
his new map page. It has clearly highlighted a number of issues. Is
this a feature we want to officially support? If so I suggest a plmtex / 
plptex example to test it as well. I know for a start this won't work
for fortran since Arjen had to implement a new string conversion 
routine for plmaptex.

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] Soft freeze declared now + release preparation plans

[Andrew Ross]

On Mon, Feb 23, 2015 at 03:55:50PM -0800, Alan Irwin wrote:
> On 2015-02-23 22:33-0000 Andrew Ross wrote:
> 
> >
> > Alan,
> >
> > I've done some preliminary testing on Ubuntu 14.10 (Utopic), including
> > running test_diff_psc as documented the other day, and test_interactive /
> > test_c_wxwidgets.
> >
> > All builds fine. test_diff_psc differences are as expected. Some slight
> > variations when testing with svg rather than psc device. I will probably
> > leave this to post-release to investigate once the tests are properly
> > implemented in cmake.
> 
> Thanks very much for this preliminary testing.
> 

P.S. Make test_noninteractive also works successfully. I've sampled a few
images and only noticed a couple of issues. 

The psc driver does not handle the \n in the calls to plmaptex in example 
19, page 5. I only spotted this having been looking at the svg output to 
fix the f95 regression. 

The pdf driver also does not handle the \n on that page.

The pdf driver also has a problem with ludicrously small text it is 
unreadable without a large zoom on some plots. The really small text is 
noticeable in examples 19, 23, 28 at least. It seems to be anything 
plotted with plptex, plmaptex is too small. Other text is fine.

I also noticed that while most devices (svg, cairo) left align
multi-line text, the qt devices seem to centre align it. This needs further 
investigation, but is probably not a show-stopper.

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] Soft freeze declared now + release preparation plans

[Andrew Ross]

On Mon, Feb 23, 2015 at 03:55:50PM -0800, Alan Irwin wrote:
> On 2015-02-23 22:33-0000 Andrew Ross wrote:
> 
> >
> > Alan,
> >
> > I've done some preliminary testing on Ubuntu 14.10 (Utopic), including
> > running test_diff_psc as documented the other day, and test_interactive /
> > test_c_wxwidgets.
> >
> > All builds fine. test_diff_psc differences are as expected. Some slight
> > variations when testing with svg rather than psc device. I will probably
> > leave this to post-release to investigate once the tests are properly
> > implemented in cmake.
> 
> Thanks very much for this preliminary testing.
> 
> I agree those different language consistency results for psc and svg
> are really intriguing (and surprising!), and I also agree they should
> be pursued post-release.

I've solved the fortran example 19 issue (it was with the way \n was being 
handled in the fortran string conversion routines). A good example where
there was a unicode issue not being picked up by the psc tests. The issue 
with the extraneous colour change commands and ocaml I've not looked into.

> > 1) Wxwidgets: I've reproduced most (but not all) of the snags in the
> > plplot bug. 
> > I did notice one or two extra issues which I've documented in the bug
> > report.
> 
> Thanks!
> 
> > 2) test_interactive runs fine. I noticed some issues with the test_tk_plgrid
> > test. The plot looks fine, but the zoom and setup page menu options don't
> > seem to work. In both cases nothing is plotted when the settings are
> > changed. This may have been broken for a long time. Can anyone reproduce
> > this?
> 
> For the "red spider web" example (test_tk_plgrid), I find that hitting
> enter no longer works to exit the example and instead you have to use
> the GUI to exit.  This is a regression from tests I have run
> in the last year.
> 
> For
> 
> examples/c/x01c -dev tk
> 
> hitting enter works fine to exit the example.
> 
> For both examples, Page/setup/reset seems to work here, but after zoom
> accepts page limits it just produces a black plot which is a
> regression from when I tested this in the last year.
> 
> Since -dev tk depends on xwin functionality and xwin depends on 
> plbuf, it is possible the above regressions have been caused by recent
> plbuf changes.  But if that is the case, I think it is likely we are
> going to have to sort out plbuf problems post-release when some
> excellent comprehensive testing of plbuf should become available to us
> with Jim's promised new plmeta/plrender functionality.

Your regressions seem to match exactly with mine. I get a black screen 
after trying any zoom. The page/setup menu works, but it makes absolutely 
no difference to the plot whatever values I set.
 

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] Soft freeze declared now + release preparation plans

[Andrew Ross]

On Mon, Feb 23, 2015 at 11:35:47PM +, Andrew Ross wrote:
> On Mon, Feb 23, 2015 at 03:14:48PM -0800, Alan Irwin wrote:
> > On 2015-02-23 22:33-0000 Andrew Ross wrote:
> > 
> > >3) The cmake based build of the examples in the install tree does not work
> > >if installed in a non-standard location (i.e. not /usr/local/). Setting
> > >CMAKE_INSTALL_PREFIX as suggested in the cmake error message makes it work,
> > >but not sure whether this should be done by default. Alan, do you have
> > >any ideas? (I mentioned this previously but got no response).
> > 
> > Hi Andrew:
> > 
> > I just double-checked, and I sent off the following reply to you (at
> > your SF mail address) concerning this question on Friday (so there may
> > be some issue in the mailing path between us or that previous reply might 
> > just be lost
> > somewhere in your INBOX):
> 
> Hi Alan,
> 
> Thanks - I don't think I got that. I thought it was unlike you not to 
> reply. Put it down to the mail gremlins.
>  
> > ===
> > I encountered something like what you have described for te_gen tests,
> > and the answer there was to simply put CMAKE_INSTALL_PREFIX/bin
> > (regardless of whether it has its default value of /usr/local/bin or
> > whether you have set CMAKE_INSTALL_PREFIX to something else on the
> > PATH.  I automatically do that PATH adjustment for all my PLplot tests
> > so I have never encountered this error for that context.
> > 
> > I am virtually positive the the above PATH change will solve the issue
> > for you, but please confirm that.
> > 
> > Note, that CMake looks at all PATH entities to determine possible
> > installation prefixes and then searches in those prefixes in the
> > standard places for PLplot configuration files that it needs which is
> > why the above PATH manipulation works.
> > ===
> > 
> > I will comment on your other questions/results separately, but I hope
> > this reply gets through to you this time.
> 
> This makes sense, but given that we know the install location, I think 
> we should have the examples CMakeLists.txt set up so that it can find
> the plplot configuration files without the user having to interfere. 
> Reading the documentation I think we need to add the plplot install 
> path to CMAKE_PREFIX_PATH. Meddling with CMAKE_INSTALL_PATH is probably
> not the right thing to do since that would also determine where the 
> examples were installed, which we don't want to do. I'll try this and see.

That works nicely. Setting CMAKE_PREFIX_PATH in 
examples/plplot_configure.cmake_installed_examples.in ensures things 
"just work" without having to manually set any extra paths.

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] Soft freeze declared now + release preparation plans

[Andrew Ross]

On Mon, Feb 23, 2015 at 03:14:48PM -0800, Alan Irwin wrote:
> On 2015-02-23 22:33-0000 Andrew Ross wrote:
> 
> >3) The cmake based build of the examples in the install tree does not work
> >if installed in a non-standard location (i.e. not /usr/local/). Setting
> >CMAKE_INSTALL_PREFIX as suggested in the cmake error message makes it work,
> >but not sure whether this should be done by default. Alan, do you have
> >any ideas? (I mentioned this previously but got no response).
> 
> Hi Andrew:
> 
> I just double-checked, and I sent off the following reply to you (at
> your SF mail address) concerning this question on Friday (so there may
> be some issue in the mailing path between us or that previous reply might 
> just be lost
> somewhere in your INBOX):

Hi Alan,

Thanks - I don't think I got that. I thought it was unlike you not to 
reply. Put it down to the mail gremlins.
 
> ===
> I encountered something like what you have described for te_gen tests,
> and the answer there was to simply put CMAKE_INSTALL_PREFIX/bin
> (regardless of whether it has its default value of /usr/local/bin or
> whether you have set CMAKE_INSTALL_PREFIX to something else on the
> PATH.  I automatically do that PATH adjustment for all my PLplot tests
> so I have never encountered this error for that context.
> 
> I am virtually positive the the above PATH change will solve the issue
> for you, but please confirm that.
> 
> Note, that CMake looks at all PATH entities to determine possible
> installation prefixes and then searches in those prefixes in the
> standard places for PLplot configuration files that it needs which is
> why the above PATH manipulation works.
> ===
> 
> I will comment on your other questions/results separately, but I hope
> this reply gets through to you this time.

This makes sense, but given that we know the install location, I think 
we should have the examples CMakeLists.txt set up so that it can find
the plplot configuration files without the user having to interfere. 
Reading the documentation I think we need to add the plplot install 
path to CMAKE_PREFIX_PATH. Meddling with CMAKE_INSTALL_PATH is probably
not the right thing to do since that would also determine where the 
examples were installed, which we don't want to do. I'll try this and see.

Andrew

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Soft freeze declared now + release preparation plans

[Andrew Ross]

Alan,

I've done some preliminary testing on Ubuntu 14.10 (Utopic), including 
running test_diff_psc as documented the other day, and test_interactive / 
test_c_wxwidgets.

All builds fine. test_diff_psc differences are as expected. Some slight 
variations when testing with svg rather than psc device. I will probably 
leave this to post-release to investigate once the tests are properly 
implemented in cmake.

1) Wxwidgets: I've reproduced most (but not all) of the snags in the plplot 
bug. 
I did notice one or two extra issues which I've documented in the bug report.

2) test_interactive runs fine. I noticed some issues with the test_tk_plgrid 
test. The plot looks fine, but the zoom and setup page menu options don't 
seem to work. In both cases nothing is plotted when the settings are 
changed. This may have been broken for a long time. Can anyone reproduce 
this?

3) The cmake based build of the examples in the install tree does not work 
if installed in a non-standard location (i.e. not /usr/local/). Setting
CMAKE_INSTALL_PREFIX as suggested in the cmake error message makes it work, 
but not sure whether this should be done by default. Alan, do you have
any ideas? (I mentioned this previously but got no response).

Andrew

On Sun, Feb 22, 2015 at 02:05:52PM -0800, Alan Irwin wrote:
> To all PLplot developers:
> 
> In my role as PLplot release manager, I am now declaring a soft freeze
> for pushes to origin master which will continue until the release is
> completed next Saturday (Febrary 28th). So please continue your
> development on your own personal PLplot topic branches, but only push
> to origin master those commits that are a simple bug fix, an update of
> release scripts, or a documentation update.
> 
> Note, if Jim comes through with a patch series containing
> plmeta/plrender functionality (but not new plbuf functionality), I
> might be tempted to push that to origin master as discussed previously
> if it passes superficial build tests. (Since the new plmeta/plrender
> will be disabled by default and declared as experimental in the
> release notes such commits will not affect most users of the new
> release and will also not affect our testing which typically is only
> for the default version of everything).
> 
> What I plan to do for the rest of this week is continue to test and
> help with the fixes for wxwidgets and plbuf that Phil and Jim are
> working on, do all the preliminary release work mentioned in
> README.Release_Manager_Cookbook including updating our release scripts
> to handle the git case, and also do the following:
> 
> 1. Do a comprehensive test on Linux following what is documented in
> .  I also
> strongly urge everyone else here with access to a suitable test
> platform (modern Linux distros, ancient "enterprise class" Linux
> distros if you use epa_build, all modern Mac OS X versions, and all 
> Cygwin, MingGW/MSYS, and MinGW-w64/MSYS2 versions of Windows) to
> follow those same wiki directions.
> 
> 2. Sort out any regressions all our joint tests reveal.
> 
> 3. Initiate a MinGW/MSYS/Wine comprehensive test (and then wait three days for
> those results to complete if all continues to be well on that
> platform).
> 
> 4. Sort out any regressions that test reveals.
> 
> 5. On Saturday (the 28th) finish the release process.
> 
> 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
> __
> 
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dolla

[Plplot-devel] Updates to test_diff.sh script

[Andrew Ross]

I've made some updates to the test_diff.sh script so you can now call it 
with the --device= option to specify a device other than psc you want to
compare. I've not (yet) incorporated all this more generalised logic in
the cmake tests, but you can run it in the examples directory. I've done
this using 
  plplot-test.sh --device=svg 
followed by 
  test_diff.sh --device=svg.
This has highlighted a few minor bugs which I've fixed. The end results 
are slightly different from the psc ones. Only the non-clean results are
included below. The f95 result is an additional difference, but the ocaml 
example 16 is clean, unlike the psc version. The ocaml result has some 
spurious colour changes in the psc version which seem to be dropped in
svg.

f95
  Missing examples: 
  Differing graphical output  :  19
  Missing stdout  : 
  Differing stdout: 
ada
  Missing examples: 
  Differing graphical output  :  08 19
  Missing stdout  : 
  Differing stdout: 
adathick
  Missing examples: 
  Differing graphical output  :  08 19
  Missing stdout  : 
  Differing stdout: 
ocaml
  Missing examples: 
  Differing graphical output  :  08 19 33
  Missing stdout  : 
  Differing stdout: 

All in all this shows it is a worthwhile exercise, even if it is not a 
"standard" test.

Andrew

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Propagation status for release

[Andrew Ross]

On Fri, Feb 13, 2015 at 10:37:01AM -0800, Alan Irwin wrote:
> On 2015-02-13 14:45-0000 Andrew Ross wrote:
> 
> >
> >In my latest commit I've updated the test suite so that there is now a
> >plrender front-end for plplot-test.sh. This will run all the C examples
> >with the plmeta driver, then run plrender to re-render the files using
> >the specified driver. This test is also incorporated in with the
> >test_diff_psc target to compare with the straight C psc output.
> >
> >Of course, by default plmeta is disabled so this commit should change
> >nothing for most users.
> >
> >Before Phil and Jim's changes examples 19 and 27 segfault with plrender.
> >The others render, but all show lots of differences. Will be
> >interesting to see what happens with the new patches!
> 
> Thanks for this.  Once the new plmeta and plrender functionality is
> finished by Jim, some adjustments will obviously have to be made to
> use the new plmeta output file option, but I am very much looking
> forward to using what you have just implemented (with that small
> modification) as a powerful test of all of the new plbuf, plmeta, and
> plrender capabilities.

Hopefully this thorough testing will highlight any new issues more 
promptly and prevent a future repeat of the current bit-rot in the 
plmeta code.

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] Propagation status for release

[Andrew Ross]

In my latest commit I've updated the test suite so that there is now a 
plrender front-end for plplot-test.sh. This will run all the C examples 
with the plmeta driver, then run plrender to re-render the files using 
the specified driver. This test is also incorporated in with the 
test_diff_psc target to compare with the straight C psc output. 

Of course, by default plmeta is disabled so this commit should change 
nothing for most users.

Before Phil and Jim's changes examples 19 and 27 segfault with plrender. 
The others render, but all show lots of differences. Will be
interesting to see what happens with the new patches!

My next plan is to change test_diff.sh.in so that it will work with 
any specified driver rather than just psc, so we could implememt
a svg comparison. As Alan said previously this is likely to test a fuller
set of functionality than the psc driver.

Cheers

Andrew

On Fri, Feb 06, 2015 at 10:26:00PM +, Phil Rosenberg wrote:
> Hi Jim
> Is it possible to call plscol, or whichever function is needed rather than 
> directly adding it to the buffer? Something like this should keep all devices 
> and the buffer consistent.
> I think that you don't even need to wait for full initialization. I know the 
> wxWidgets driver remembers state changes that occur before the driver is 
> initialised.
> 
> Phil
> 
> 
> -Original Message-
> From: "Jim Dishaw" 
> Sent: ‎06/‎02/‎2015 20:16
> To: "Alan W. Irwin" 
> Cc: "PLplot development list" 
> Subject: Re: [Plplot-devel] Propagation status for release
> 
> On Feb 6, 2015, at 2:40 PM, "Alan W. Irwin"  wrote:
> 
> > On 2015-02-06 08:36-0500 Jim Dishaw wrote:
> > 
> >> I was able to get nearly identical outputs using psc with a replot
> > of the plot buffer. The only differences were the time stamp in the
> > header and an additional pen color command that doesn't affect
> > anything.
> > 
> > Hi Jim:
> > 
> > That sounds like an extremely encouraging result. Did you test that
> > for all of our standard examples or just a few of them?  I also suggest
> > you do the equivalent test with -dev svg since that device has
> > essentially full PLplot capability while -dev psc is missing a lot
> > and therefore does not provide as stringent a test.
> > 
> I implemented one test derived from example 1 because it exercised a good set 
> of features.  I would need to create modified versions of each example, which 
> I am not sure is a good use of time nor necessary.  I would rather have one 
> (or maybe two) program that exercises the set of commands and tests for 
> identified bugs that have been fixed (to prevent regressions).
> 
> >> I'm trying to figure out how to eliminate the extra pen color
> > command, but I'm not sure if I will be able.
> > 
> > Eliminating this extra pen color noise from the diff is really
> > important since it allows you to use cmp (with the first few bytes
> > ignored to remove the time stamp from the comparison of PostScript
> > results) as a diagnostic tool.  Therefore, I hope you find the
> > solution for this issue since that will allow us to check the plmeta
> > capability on all standard examples as part of the test_diff_psc
> > target (and the test_diff_svg target once we get to implementing that
> > post release).  
> I know where the extra plot color is coming from, I'm not sure of the best 
> way to fix it.  I put the current pen color into the buffer when the buffer 
> is initialized to ensure the redraw has the correct colors.  The underlying 
> issue is that the initial color is never set via a plplot command, it happens 
> internally.  For example, in pl_bop_ps() the initial pen color is set via: 
> 
> {
> r = ( (PLFLT) pls->cmap0[0].r ) / 255.;
> g = ( (PLFLT) pls->cmap0[0].g ) / 255.;
> b = ( (PLFLT) pls->cmap0[0].b ) / 255.;
> 
> fprintf( OF, "B %.4f %.4f %.4f C F\n", r, g, b );
> }
> 
> I have not checked every driver to see how the initial color is handled.  
> Depending on what I find, there are a couple of fixes.  The fix might be as 
> simple as removing the initial color from plbuf.  A more serious fix is to 
> move setting the initial color from the device specific bop function to the 
> plcore bop function plP_bop().
> 
> I am using psc for now because I can actually read it to find the problems.  
> Having it use the svg driver is a trivial change.
> 
> > 
> > Anyhow, I do hope to see such a patch series (including at least one
> > plbuf test) from you in time (i.e., before the soft freeze date two
> > weeks from now on February 21st) so that we can incorporate it into
> > this forthcoming release.
> > 
> 
> My plan is to have a set of patches by next friday.
> 
> 
> --
> 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

Re: [Plplot-devel] What is the minimum C standard for PLplot?

[Andrew Ross]

If you check the README.developers you will see our recommended coding 
style. Currently for C this is ISO C99 standards with POSIX.1-2001 base 
specification (required for a number of functions). The README file also 
gives the gcc flags to check compliance with the standards.

Cheers

Andrew

On Tue, Feb 10, 2015 at 01:14:33PM -0500, Jim Dishaw wrote:
> Is the minimum supported compiler the C89 specification?  I would like to use 
> the offsetof() macro in the implementation of the revised metafile I/O 
> routines.  My goal is to define the data file format in a variable and to 
> support multiple versions for backwards compatibility.
> --
> 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] plGetCursor

[Andrew Ross]

On Wed, Jan 28, 2015 at 10:59:04AM -0800, Alan Irwin wrote:
> On 2015-01-28 13:39- Phil Rosenberg wrote:
> 
> > Hi All
> > I am trying to add the plGetCursor functionality into the wxWidgets
> > driver. It will need to be implemented rather differently to before
> > because of the separation between the gui process and the calling
> > process. However, looking at the old implementation, the documentation
> > and the examples last night I am not really clear on what the aim or
> > the behaviour of this function should be.
> >
> > Is the intention that when you call this function it returns the last
> > user input that occurred with the gui, or is the intention that
> > calling this function blocks until the user interacts with the plot
> > and then returns the nature of this input?
> 
> The latter.
> 
> >
> > Presumably the input it is looking for is key presses and the location
> > of mouse button presses, not just mouse cursor movements without a
> > mouse press?
> 
> As Arjen said the xwin driver should be the model here.
> 
> Operationally, the way this works for that driver is a cursor is
> displayed on the screen which the user can move around with the mouse
> using drag & drop.  Once the user is satisfied with that cursor
> position, then he strikes some key or some mouse button, and 
> the position of the cursor and the identity of the key
> or mouse button that was struck is returned.
> 
> Such fundamental interactive capability can be used as a basis of
> quite sophisticated interactive applications that use the identity of
> the key struck as a one-letter menu for a whole host of different
> interactive operations that depend on the cursor position when the key
> was struck.  As far as I know, nobody is currently using PLplot this
> way (perhaps because we don't strongly advertise this cursor
> capability).  However, I do remember using one such application in the
> 80's that was based on some plotting package (obviously not PLplot)
> that was available then, and that application was quite powerful
> because it used both key and mouse button identities for control
> rather than just limiting itself to the latter.

It always struck me that this was a somewhat quirky aspect of our API. It
is useful for the xwin driver, but if you are using Qt or Wxwidgets, 
this is probably not the way you would handle cursor / mouse events 
since it doesn't fit with the underlying toolkit model. That being said,
it is relatively simple, will work with multiple devices, and gives you
a cursor position in useful plplot coordinates, so it is probably
worth implementing properly.

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] Do we want to move plAlloc2dGrid(), plFree2dGrid, and plMinMax2dGrid

[Andrew Ross]

On Tue, Jan 27, 2015 at 12:17:22PM -0800, Alan Irwin wrote:
> For reference the question was
> 
> > Would you be willing to give your official permission to adapt your
> > new approach for the needs of ephcom under the LGPL?
> 
> On 2015-01-27 09:12-0500 Jim Dishaw wrote:
> 
> > You have my permission though it probably is not really needed
> because the algorithm is generic and you are going to be rewriting the
> code.
> 
> I agree it is a debatable point whether to ask permission in this
> case, but I always like to be clear about such issues so thanks for
> your permission.
> 
> > If you make a generic allocator, then you will need to tweak the
> pointer arithmetic to get the layout correct.  I rely on the (float
> **) and (float *) types to get the arithmetic correct.  A generic
> allocator would need a (UCHAR *) or something similar and if the base
> type was not a byte, you need to adjust accordingly.
> 
> Yes.
> 
> I also think alignment issues must be considered.
> >From the malloc man page:
> 
> "The malloc() and calloc() functions return a pointer to the allocated
> memory that is suitably aligned for any kind of variable."
> 
> So that part is OK by definition with regard to alignment, i.e.,
> whatever is placed first in the memory area is guaranteed to
> be aligned properly regardless of the size of the object.
> 
> However, your code mallocs the combination of two different kinds of
> objects so to guarantee correct alignment for the longer objects,
> those have to be placed first in the memory area.  So, for example, on
> a 32-bit machine pointers typically (but not always) have a size of 4
> bytes which is obviously shorter than the 8 bytes used for doubles. So
> your code would have had misalignment issues for that case (unless the
> relevant dimension happened to be even), and to avoid such issues your
> original code and my generalization of it need a test on the size of
> objects to decide which to place first in the memory area.
> 
> When I get these issues sorted out, I will follow up here with a reference
> to the updated ephcom code in case someone here wants to use that
> same approach for the PLplot 2D arrays.

The sane way round this is make two allocations, one for the array of 
pointers and one for all the data. This is still a lot more efficient 
than the current multiple allocation approach, but still always 
guarantees correct alignment etc.

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] [plplot:plplot] [c15793] - Alan W. Irwin: Build system. Revert recent change to the Tk configuration

[Andrew Ross]

Just to point out that if you need to configure plplot on a machine without
any physical X display then you can always use the xvfb X server which 
provides a dumb framebuffer using virtual memory. This is what the Debian 
build does on the build machines precisely to get round this tk problem.

Andrew

On Tue, Jan 20, 2015 at 01:16:26AM +, Repository PLplot plplot.git wrote:
> master: Build system.  Revert recent change to the Tk configuration
> 
> It turns out that recent change (to use "package provide" rather than
> "package require" for one CMake test to find the Tk version in
> tcl-related.cmake) never works on Linux.  So that change was a
> roundabout way to insure that Tk was always disabled which is not the
> desired result.
> 
> I have done extensive command-line tests, and "package provide" only
> appears to work with Tcl (presumably because tclsh loaded Tcl before
> that package command was executed), but not Itcl, Tk, Itk, or Iwidgets
> under either tclsh or wish.  So the conclusion is we must always stick
> with "package require" in tcl-related.cmake and accept that a working
> X will be required to configure Tk, Itk, or Iwidgets.  The logic in
> tcl-related.cmake does look for the case where either wish or tclsh
> error out.  However, if X is hanging rather than erroring out, (the
> issue which was "solved" by the commit that this commit reverts), I
> don't know a test for that issue that would not also hang.  Instead,
> it appears to me the only recourse for a user if X hangs is to specify
> -DENABLE_tk=OFF (which automatically turns off searching for or using
> Itk and Iwidgets as well).
>  
> http://sourceforge.net/p/plplot/plplot/ci/c1579387c0720b41891ece361453cb7d394ab999/
> 
> 
> ---
> 
> Sent from sourceforge.net because you indicated interest in 
> 
> 
> To unsubscribe from further messages, please visit 
> 


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] metafiles

[Andrew Ross]

On Tue, Jan 13, 2015 at 10:00:41PM -0800, Alan Irwin wrote:
> On 2015-01-13 22:52-0500 Jim Dishaw wrote:
> 
> >That [very simple plrender] would be my supposition.
> >
> >I looked at the changes required to switch from short to PLINTERNAL and I 
> >have a few questions:
> >
> >1) Do we want to keep the PLINTERNAL type private to plplot?
> >2) Where do we want to define the type (the location depends on the answer 
> >to #1)?
> 
> I am not sure.  Andrew might have a good answer here.

As the name suggests, I think PLINTERNAL should be internal, unless anyone
 can think of a good reason that it should be externally visible.

If it internal, then I guess it should live in include/plplotP.h

Andrew

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: metafiles

[Andrew Ross]

Can I suggest a script which runs all the standard examples, saves as 
plmeta files, then re-renders using the psc driver. It would be 
illuminating to compare with the direct psc driver and should also
highlight any missing API elements in the buffering. 

I'll see if I can knock something together.

Andrew

Note Maurice's comments about not completely reproducing the original 
device, but again it would be good to quantify that.

On Tue, Jan 13, 2015 at 03:48:52PM +, Phil Rosenberg wrote:
> Jim and others
> A gotcha that I just found doing unrelated stuff (actual work!) is that
> calls to plscmap0and plscmap0n are not saved to the buffer, but calls to
> plcol0 are saved to the buffer using the index it is called by. I found the
> bug because I was changing the colour map part way through plotting and
> getting odd colours on redraws. I guess plcolmap1 is probably similar.
> 
> I have a feeling that we might find a number of these type of problems
> along the way.
> 
> Phil
> 
> On 13 January 2015 at 05:42, Maurice LeBrun  wrote:
> 
> > On Saturday, January 10, 2015 at 13:57:16 (-0600) Maurice LeBrun writes:
> >  > Design issues include:
> >  >  - The physical device coordinate space was a limiting factor, say for
> > later
> >  > zooms.
> >  >  - Ditto for the physical device API.  A metafile/renderer built at a
> > higher
> >  > level would've had more versatility.
> >
> > Given all the recent discussion, I wanted to underscore the latter as
> > perhaps
> > the most irksome feature of the original plmeta/plrender paradigm.  Saving
> > the
> > plot data at the device level means that you can only recover the original
> > plot device output if it matches exactly the resolution of the metafile
> > "device".  So using the plot buffer, with perhaps limited extensions to
> > change
> > the things you can do to modify the output (e.g. affecting color palette),
> > sounds reasonable.  The ability to take a .plm file and render it after the
> > fact to any device was hugely useful but the fact that it was not
> > guaranteed
> > to match the output of the original device repeatedly caused us to pull our
> > hair out.
> >
> > --
> > Maurice LeBrun
> >

> --
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet

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


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Fwd: metafiles

[Andrew Ross]

Phil,

The problem was that we updated the API and added new functionality that 
was never included in the metafiles since no-one was supporting it. In 
the end we took the decision to disable it by default rather than 
distribute something that didn't work fully. The plrender code is still 
there in utils/ if you want to take a look. It would be possible to 
resurrect this is someone was enthusiastic enough. 

I always had it in the back of my mind to do a complete rewrite to 
make an object oriented structure storing all the plot information. 
This would allow complete recreation of a figure, and also allow
editing of labels, data, colours etc. My vision was to implement 
something that would allow creation of proper matlab style graphics
in octave, but it would be useful for other things too. Of course 
other things got in the way and I never had time for this project.
It's still out there as an idea though...

Andrew

On Fri, Jan 09, 2015 at 03:55:27PM +, Phil Rosenberg wrote:
> Hi Jim
> Thanks for that info.
> 
> I have done a bit of googling and it seems that there also used to be a
> tool called plrender which read in metafiles - however I found an email
> from Alan in 2007 (
> https://www.mail-archive.com/plplot-general@lists.sourceforge.net/msg00177.html)
> saying that the metafile device had fallen into disrepair. Presumably if
> that never got fixed then plrender stopped being useful also and was
> eventually removed.
> 
> As you say it should be relatively easy to reinstate the two to some
> degree, however I can't remember how things like fonts get buffered - i.e.
> is the decision about Hershey fonts made before buffering or does it make
> no difference? The easiest way would just be to introduce something like a
> plsavebuffer and plloadbuffer or plgetbuffercontents and
> plsetbuffercontents into the public API, but that then requires propagation
> through all the other languages.
> 
> However, I imagine that I will suffer the same slowdown you experienced so
> maybe there is a better way - unfortunately all the better ways I can think
> of (transport via a network port, or shared memory) are either much more
> difficult or not very platform independent or both. For now don't worry
> about it. I will mull things over and see what I can think of as the best
> way to do this.
> 
> Phil
> 
> On 9 January 2015 at 14:42, Jim Dishaw  wrote:
> 
> > I believe those BUFFERED_FILE blocks are from the patches I submitted
> > years ago that implemented the memory buffer.
> >
> > Prior to that patch, Plplot used a temporary file to buffer plot commands
> > (using a plplot internal command set). Those temporary files would often
> > get left behind on abnormal termination. I implemented a memory only buffer
> > (which also sped up my code) but I wanted to leave the original temporary
> > file buffers in case someone was using plplot on a low memory machine.
> >
> > The contents of the memory buffer is (or at least was) identical to what
> > was in the temporary file. It would be relatively easy to implement two
> > routines that read and write the memory buffer.  If you want I can do that
> > and send you a patch.
> >
> >
> >
> > On Jan 9, 2015, at 4:58 AM, Phil Rosenberg 
> > wrote:
> >
> > Hi all
> >
> > Does anyone know if the metafile driver still exists and if so what CMAKE
> > parameters are needed to enable it - I currently don't get it for my builds.
> >
> > Also is there an easy way to read a plplot metafile in again? I see quite
> > a few #ifdef BUFFERED_FILE comments in plbuf.c, which look like they do
> > exactly that, however it looks like a build can only either use a memory
> > buffer or a file buffer, not both.
> >
> > Just for background I'm trying to deal with the wxWidget driver segfault
> > bug, which requires the wxWidgets app to run in a separate thread or as a
> > separate process. As plplot isn't threadsafe I am looking into the latter,
> > but I need a way to send commands from the console app to this separate
> > process - I was thinking that the easiest way to do this would be to write
> > out the buffer, then read it back in again. Thoughts welcome.
> >
> >
> > 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.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >
> >

> --
> Dive into the World of Parallel Programming! The Go Parallel Websi

Re: [Plplot-devel] new map api documentation

[Andrew Ross]

Agreed. Changing the variable names now is relatively straightforward and 
it is much better to have a clear API.

Andrew

On Sun, Nov 09, 2014 at 09:39:37AM -0800, Alan Irwin wrote:
> On 2014-11-09 11:08- phil rosenberg wrote:
> 
> > HiI am just writing the documentation for the new map API. I wonder if some 
> > of the variable names are now misleading. For example type can either be 
> > one of the plplot built in map types or the filename of a shapefile, so 
> > perhaps name or file might be better. Perhaps more importantly in a 
> > shapefile the coordinates may not be lat/lon (this is true for the ones 
> > used in the new example) so the variables minlong etc are misleading, they 
> > should perhaps be minx etc instead.
> > I realize however that people have been implementing the new functions in 
> > other bindings so this would have been better flagged a few weeks ago, so 
> > I'm sorry if this generates extra unnecessary work. Should we change them 
> > or leave them the same?
> 
> Hi Phil:
> 
> I am all for explanatory argument names.  So please go ahead and
> choose what you think are the best plmap* argument names for C, C++,
> and the DocBook documentation.  I will take responsibility for making
> the corresponding changes in the 4 languages I have 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
> __
> 
> --
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

Re: [Plplot-devel] Results for ps and psttf device drivers when -geometry is specified

[Andrew Ross]

On Sat, Oct 25, 2014 at 10:18:23PM -0700, Alan Irwin wrote:
> On 2014-10-25 15:36-0700 Alan W. Irwin wrote:
> 
> > Therefore, my guess is these misalignment issues for the ps device
> > driver [for example 14] are due to some long-standing multistream issue for 
> > that driver
> > rather than something introduced recently by dropping the emission of
> > isolated M commands for every state change.  But further investigation
> > (which I have no time for now) will be required to sort that out, and
> > meanwhile the good results for all non-multistream cases that I found
> > above are quite reassuring.
> 
> Hi Andrew:
> 
> The example 14 "misalignment issues" turned out to have nothing to do
> with multistream issues or extra M commands.  Instead, I could
> reproduce the same issues with example 1 by specifying the same
> geometry externally for example 1 that is specified internally 
> (500x410+100+2 for "master" and 500x410+650+20 for slave) in the
> example 14 case.
> 
> Will you take a look at the following results for various geometry
> offsets for example 1, and let me know what you think?
> 
> examples/c/x01c -dev psc -geometry 500x410 -o test1.psc
> examples/c/x01c -dev psc -geometry 500x410+100+20 -o test2.psc
> examples/c/x01c -dev psc -geometry 500x410+650+20 -o test3.psc
> 
> I would like your take on the above results because of your knowledge
> of our ps and psttf device drivers, PostScript, and bounding box
> calculations.  I suspect gv is having trouble displaying test2.psc and
> test3.psc because of bounding-box miscalculations by our ps and psttf
> device drivers when offsets are applied. If you agree, I hope you will
> be able to come up with a fix for both device drivers.

Alan,

A quick diff of the offending files above (thanks for the simple test 
example!) shows that there are two issues. Firstly the bounding box is
set wrong. Secondly the black rectange which fills the background is plotted
too big. I think I've fixed both issues now, at least for the test case you 
presented. The changes should have no impact for cases where there is no
offset. I've checked example 14 and the bounding boxes are correct in this
case, although the image for the second plot looks rather squashed so
there may be further issues.

Like everyone else this has very much been by trial and error. I think
that's the fundamental problem with all this bounding box code.

Oh, and I've not actually tested the psttf changes (don't currently have
all the dependencies installed), but it's identical code to the ps driver
so should be ok.

Andrew



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

Re: [Plplot-devel] Why is the set_stream() call commented outforplstream::fill, etc.

[Andrew Ross]

Well Phil,

If you feel strongly about it then go for c). As I said, it would mirror 
what we do for callbacks for some of the other OO languages we support.

Andrew

On Wed, Oct 22, 2014 at 10:19:17AM +0100, Phil Rosenberg wrote:
> Okay, well, that works then. Although option c is probably only a couple of 
> dozen lines of code.
> 
> Actally having  two plstream::fill methods might work as one will be const. I 
> will test it and see. I'm not sure it is the "right" option. I probably feel 
> the same about that as Andrew does about use the c function.
> 
> Phil
> 
> -----Original Message-
> From: "Andrew Ross" 
> Sent: ‎22/‎10/‎2014 09:07
> To: "phil rosenberg" 
> Cc: "Alan W. Irwin" ; "PLplot development list" 
> 
> Subject: Re: [Plplot-devel] Why is the set_stream() call commented 
> outforplstream::fill, etc.
> 
> On Wed, Oct 22, 2014 at 07:40:34AM +, phil rosenberg wrote:
> > Hi Andrew and AlanI still think that a public plstream::plfill function is 
> > bad C++ style. One af the big ideas in C++ is data hiding and doing this 
> > exposes a method that we never want a user to call. I personally don't see 
> > any problem with using C-Style functions in C++ - for example the only way 
> > that is permitted to extend usage of std containers is with C-style 
> > function as you are not permitted to inherit from them.
> > So in my opinion these are the options that are good C++ style
> > a) Just use the C plfill option - but obviously Andrew doesn't like this 
> > and I do see why.b) Create a C-Style function in the C++ header with a 
> > slightly different name - perhaps in a namespace to avoid clashes which 
> > calls plfill. This is only really a very thin wrapper, but it does 
> > distinguish the C++ API from the C APIc) If we want to go to town an do it 
> > in an object oriented way then here is the method I would propose: We 
> > create a plfiller class which accepts a function pointer in its 
> > constructor. This has a private method getfillfunction() and declares 
> > plstream as a friend. Instead of passing a function pointer to plshade, we 
> > pass a plfiller. We also declare a public const static plfiller in plstream 
> > called defaultfiller or something which uses plfill.Now the user can do a 
> > number of things. They can call plstream::shade with 
> > plstream::defaultfiller, they can call it with plfill, which will 
> > implicitly construct a plfiller, they can call it with their own function 
> > pointer which will again implicitly create a filler object or they can 
> > create their own plfiller which will return a different function pointer of 
> > their own design.
> > 
> > Option c is rather more complicated than the other 2, but is ensures all 
> > the data hiding requiresments of good C++ style and to me is the much 
> > better option style wise than just having a static plstream::plfill method.
> > Phil
> 
> I agree with Phil that c) is probably the "correct" C++ way to do this, but I 
> also agree it seems like overkill. This is the kind of thing I did for the 
> Java classes, but there using the C API is not an option so it was more 
> enforced, b) seems like unnecessary work without any real benefit. I could 
> live with a) I guess despite my reservations. We have the C++ version for the 
> direct calls, and just use the C version for the callback.
> 
> Alan - if we went for my suggestion of have a static and non-static version 
> they would need different names. I'm pretty sure you couldn't overload the 
> function that way if both versions had exactly the same arguments.
> 
> Andrew

> --
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho

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


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

Re: [Plplot-devel] Why is the set_stream() call commentedoutforplstream::fill, etc.

[Andrew Ross]

I agree that's the best option to keep linkage simple and solve the 
problem. I'd not thought about the linkage implications either...

Andrew

On Wed, Oct 22, 2014 at 10:09:21PM +0100, Phil Rosenberg wrote:
> I agree, so in the absence of any input from Andrew I will go ahead with that 
> tomorrow afternoon.
> 
> Phil
> 
> -Original Message-
> From: "Alan W. Irwin" 
> Sent: ‎22/‎10/‎2014 20:34
> To: "Phil Rosenberg" 
> Cc: "Andrew Ross" ; "PLplot development 
> list" 
> Subject: RE: [Plplot-devel] Why is the set_stream() call 
> commentedoutforplstream::fill, etc.
> 
> On 2014-10-22 19:57+0100 Phil Rosenberg wrote:
> 
> > Hi Alan
> > I didn't think of that either. It built on my system as I use static builds 
> > so the C library gets directly linked anyway.
> > Andrew, do you have any preference. Presumably the option b or c from 
> > before are required?
> 
> My own (somewhat inexpert) opinion is (c) is gross overkill, but (b)
> now has the advantage since it doesn't require user's applications and
> libraries be linked to both the plplotcxx and plplot libraries. (which
> is the requirement for the current (a) option that has been
> implemented).
> 
> If Andrew is willing to go along with (b), then please go for
> distinctive names for those C++ callbacks such as fill_callback and
> tr[0-2]_callback.
> 
> 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


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

Re: [Plplot-devel] Why is the set_stream() call commented out forplstream::fill, etc.

[Andrew Ross]

On Wed, Oct 22, 2014 at 07:40:34AM +, phil rosenberg wrote:
> Hi Andrew and AlanI still think that a public plstream::plfill function is 
> bad C++ style. One af the big ideas in C++ is data hiding and doing this 
> exposes a method that we never want a user to call. I personally don't see 
> any problem with using C-Style functions in C++ - for example the only way 
> that is permitted to extend usage of std containers is with C-style function 
> as you are not permitted to inherit from them.
> So in my opinion these are the options that are good C++ style
> a) Just use the C plfill option - but obviously Andrew doesn't like this and 
> I do see why.b) Create a C-Style function in the C++ header with a slightly 
> different name - perhaps in a namespace to avoid clashes which calls plfill. 
> This is only really a very thin wrapper, but it does distinguish the C++ API 
> from the C APIc) If we want to go to town an do it in an object oriented way 
> then here is the method I would propose: We create a plfiller class which 
> accepts a function pointer in its constructor. This has a private method 
> getfillfunction() and declares plstream as a friend. Instead of passing a 
> function pointer to plshade, we pass a plfiller. We also declare a public 
> const static plfiller in plstream called defaultfiller or something which 
> uses plfill.Now the user can do a number of things. They can call 
> plstream::shade with plstream::defaultfiller, they can call it with plfill, 
> which will implicitly construct a plfiller, they can call it with their own 
> function pointer which will again implicitly create a filler object or they 
> can create their own plfiller which will return a different function pointer 
> of their own design.
> 
> Option c is rather more complicated than the other 2, but is ensures all the 
> data hiding requiresments of good C++ style and to me is the much better 
> option style wise than just having a static plstream::plfill method.
> Phil

I agree with Phil that c) is probably the "correct" C++ way to do this, but I 
also agree it seems like overkill. This is the kind of thing I did for the Java 
classes, but there using the C API is not an option so it was more enforced, b) 
seems like unnecessary work without any real benefit. I could live with a) I 
guess despite my reservations. We have the C++ version for the direct calls, 
and just use the C version for the callback.

Alan - if we went for my suggestion of have a static and non-static version 
they would need different names. I'm pretty sure you couldn't overload the 
function that way if both versions had exactly the same arguments.

Andrew

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Why is the set_stream() call commented out forplstream::fill, etc.

[Andrew Ross]

On Tue, Oct 21, 2014 at 03:07:31AM -0700, Alan Irwin wrote:
> On 2014-10-21 09:18+0100 Phil Rosenberg wrote:
> 
> > Hi Alan
> 
> > That option works for me - if that feature might be in use then we can 
> > retain it.
> 
> > However I disagree with wrapping plfill in a plstream::plfill
> method. This is poor object oriented division of responsibility. The
> plfill method has nothing really to do with plstream and if we create
> that method, then someone somewhere will use it incorrectly and create
> a hard to find bug.
> 
> > If you really wanted to go object oriented then
> you would create a plfiller class, which would have a fill virtual
> method which for the standard class would call plfill. Then you would
> pass this into plstream::shade. However, I think all that is
> unnecessary. Just using plfill for the callback is simple, effective,
> transparent and also conforms to the existing plplot documentation.
> 
> Hi Phil:
> 
> I was basing my idea for the plstream::fill_callback on the
> plstream::tr[0-2] callbacks which are C++ wrappers for the C
> callbacks, pltr[0-2]. That is, I was just following an existing
> pattern without a lot of C++ knowledge to back it up.  However, your
> arguments for simply using unwrapped C callbacks seems compelling to
> me so long as we are consistent about how we apply that idea.
> Therefore, I suggest (unless Andrew weighs in with a contrary opinion)
> that you go ahead and commit the exact change you proposed for your
> option 1 as well as (this is the consistency part I think is
> important) officially deprecating plstream::tr[0-2] in README.release
> and replacing all uses of those C++ callbacks in our C++ examples with
> the C callbacks pltr[0-2].

Well I (re)wrote the current C++ classes in plplot.  The original
intention was to completely hide the C API from the user. Mixing C and C++
APIs is generally a bad idea (though I can see some argument in this
special case Phil, but it is the thin end of the wedge). Hiding the calls
to set_stream was an attempt to make plplot more object orientated, but as
Phil pointed out, it is not thread safe anyway so we are hiding some of
the dangers.

Personally I like the idea of removing the function pointer altogether
or replacing with a enumeration since it only causes problems with all our
language bindings. This however is a pretty major API change since plshade
must be one of our more heavily used functions. I really can't see any
users writing their own versions of plfill, but you never know

My other option was to provide a static version of plfill for use as a
callback function (without the set_stream call) and a non-static version
with the call to set_stream for use elsewhere. This would make the two
different usages clear.

Andrew

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Why is the set_stream() call commented out for plstream::fill, etc.

[Andrew Ross]

On Thu, Oct 16, 2014 at 04:34:53PM -0700, Alan Irwin wrote:
> On 2014-10-16 20:39+0100 Andrew Ross wrote:
> 
> >
> > Alan,
> >
> > It's because these three functions are callback functions which are
> > called from another plplot function. They do not operate directly on
> > a stream.
> 
> Hi Andrew:
> 
> I may be misinterpreting what you are saying above, but I noticed many
> direct as well as more limited callback uses of these three functions
> in our examples, see below.
> 
> >
> > The C++ class maintains a stream variable for each instance of the
> > PLStream class. This means you can have multiple streams (i.e. windows
> > / files) and not have to worry which one plplot is currently using.
> > It's all hidden in the object orientation by calling set_stream
> > each time a plplot API function is called for a particular object.
> >
> > The callback functions don't need to do this since they are being
> > called from another plplot function. If you look in plstream.h
> > you will see these functions are marked static which means there
> > is a single copy of the function shared across all instances which
> > does not have access to the local variables in the class. This
> > means that calling set_stream wouldn't actually work anyway,
> > enforcing this distinction. Uncommenting would generate a compiler
> > error.
> 
> You lost me a bit because of my lack of knowledge concerning C++.
> Nevertheless, let me ask a supplementary question.  Your explanation
> indicates these are specially treated because they are callback
> functions, but that is not the full story.  For example, those
> functions are used directly and not as callbacks in many examples; if
> you look for "fill" in the C++ examples, there are many references to
> pls->fill rather than plstream::fill.  I checked a number of those,
> and the pls->fill ones are mostly direct although in example 21 it
> appears that the pls->fill form may also be used as a callback.  I
> have no idea whether that example 21 difference in pattern matters,
> but I do wonder whether if one of our users attempted to use fill,
> fill3, or gradient directly in a multistream application similar to
> example 14, would they run into an error because of the lack of
> set_plstream call in the C++ binding?  Note our current set of
> examples does not test this case because fill, fill3, and gradient are
> all missing from example 14.
> 
> I emphasize again my concerns boil down to questions concerning
> pattern inconsistencies.  Thus, you may well have a good C++ answer
> for the pattern inconsistency I noted above for example 21 when it
> appears that fill in direct form (pls->plfill) may be used as a
> callback, and also C++ answers for when fill, fill3, and gradient are
> used directly throughout our examples and also potentially in a
> multistream environment like example 14.

Alan,

OK. On closer examination I think you may be right. Looking at the 
plfill code it does seem there is a potential problem. I'll look into 
this. Casting my mind back I seem to remember problems with the 
callbacks if they weren't static functions, so I may need to think 
about how this will work.

Thanks for spotting the problem anyway!

Andrew

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Why is the set_stream() call commented out for plstream::fill, etc.

[Andrew Ross]

Alan,

It's because these three functions are callback functions which are 
called from another plplot function. They do not operate directly on
a stream.

The C++ class maintains a stream variable for each instance of the 
PLStream class. This means you can have multiple streams (i.e. windows 
/ files) and not have to worry which one plplot is currently using. 
It's all hidden in the object orientation by calling set_stream 
each time a plplot API function is called for a particular object.

The callback functions don't need to do this since they are being 
called from another plplot function. If you look in plstream.h 
you will see these functions are marked static which means there 
is a single copy of the function shared across all instances which
does not have access to the local variables in the class. This
means that calling set_stream wouldn't actually work anyway, 
enforcing this distinction. Uncommenting would generate a compiler
error.

Andrew

On Thu, Oct 16, 2014 at 10:54:43AM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> I just noticed that the set_stream() call was commented out in
> bindings/c++/plstream.cc for plstream::fill, plstream::fill3, and
> plstream::gradient while it appears in all (as far as I can tell) other
> calls.  Why are those 3 functions exceptions, or is this a minor bug
> that has progated from plstream::fill to the rest?
> 
> Note, I don't have any deep understanding of what set_stream does
> (other than what its name implies), but the above seemed a peculiar
> pattern to me which should be brought to your attention.
> 
> 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
> __
> 
> --
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Our next release

[Andrew Ross]

Alan,

That sounds like a good idea. There have been a number of useful 
improvements / fixes since then. We definitely want to try and
get the various language bindings and examples back into sync
before then. I've now done the C++ examples to get the process 
started. 

Andrew

On Tue, Oct 14, 2014 at 02:50:16PM -0700, Alan Irwin wrote:
> Our last release was way back in February of this year so I think it
> would be a good idea to get out another release fairly soon, say 6
> weeks from now near the beginning of December.  That is about the
> latest time in a year I would like to make a release so as not to
> conflict with Christmas holiday plans for anybody here.
> 
> Would that sort of time frame for the release be acceptable to everyone?
> 
> Currently, I have one more item on my PLplot ToDo list which is to
> update all necessary scripts I use in the release process (e.g.,
> scripts/make_tarball.sh used to create the release tarball) to replace
> svn commands by their git counterparts.  But I am going to wait until
> the actual release process to deal with those issues.  Also, assuming
> Phil decides to work during this release cycle on an idea he told me
> about off list to finally make -dev wxwidgets much more reliable, I
> plan to help him with the build-system changes required by his idea.
> 
> I also plan to help with propagation efforts.  Here is the current
> status of those:
> 
> c++
>Missing examples:
>Differing postscript output :  08
>Missing stdout  :
>Differing stdout: 
> f95
>Missing examples:
>Differing postscript output :  08 19
>Missing stdout  :
>Differing stdout: 
> java
>Missing examples:
>Differing postscript output :  08 19
>Missing stdout  :
>Differing stdout: 
> octave
>Missing examples:
>Differing postscript output :  07 08 19
>Missing stdout  :
>Differing stdout: 
> python
>Missing examples:
>Differing postscript output :  08 19
>Missing stdout  :
>Differing stdout: 
> tcl
>Missing examples:
>Differing postscript output :  08 19
>Missing stdout  :
>Differing stdout: 
> ada
>Missing examples:
>Differing postscript output :  08 19
>Missing stdout  :
>Differing stdout: 
> adathick
>Missing examples:
>Differing postscript output :  08 19
>Missing stdout  :
>Differing stdout: 
> ocaml
>Missing examples:
>Differing postscript output :  08 16 19 33
>Missing stdout  :
>Differing stdout: 
> lua
>Missing examples:
>Differing postscript output :  08 19
>Missing stdout  :
>Differing stdout: 
> d
>Missing examples:
>Differing postscript output :  08 19
>Missing stdout  :
>Differing stdout:
> 
> It would be good to get all of these issues cleaned up for the release
> so I hope everyone helps out with these propagation issues for the
> languages where they have expertise.
> 
> The vast majority of these issues are due to changes made in example 8
> and 19.
> 
> The example 8 change is
> 
> "Add a 4th (and 8th) page that demonstrates plsurf3dl results for
> Y index ranges that follow an ellipse (subject to integer
> quantization)."
> 
> So to propagate this change for a given language you need to add the
> plsurf3dl API to the language binding (if it hasn't been implemented
> already) and then modify example 8 for the language.
> 
> The example 19 differences are due to Phil's recent addition of the
> new functions plmapline, plmapstring, plmaptex, and plmapfill
> functions to our API, and adding calls to those functions in example
> 19 to implement a really nice looking Exmoor map page.  So to
> propagate this change for a given language you need to add those new
> functions to the language binding, and modify example 19 for the
> language.
> 
> For this release, I also hope Arjen and Phil adjust the build system
> (either by fixing non-working tests for simple issues or removing
> non-working tests from the list of what is tested for tougher issues)
> so that scripts/comprehensive_test.sh runs without errors for the
> various Windows platforms accessible to them (Cygwin, MSYS, MSVC).
> This is important because it finally establishes comprehensive test
> benchmarks for those platforms that we can use as a basis of future
> tests for regressions in our support of various Windows platforms.
> Also as I have already mentioned off-list to them, it is easy to
> implement a CMake warning message for each test that is skipped to
> motivate fixing the non-working tests they discover. Note, this script
> already works for the one Windo

Re: [Plplot-devel] Exit calls and memory management

[Andrew Ross]

Phil,

This is a laudible plan, however fundamentally it won't remove the exit 
calls from plplot. The reason is that memory allocation can fail. We 
always need to check this and fail graceful, returning an error to the 
calling program and letting it decide how to procede. However we do the 
memory management, this is still true. The fundamental problem is that we 
have no mechanism for doing this at the moment since none of our functions 
return values. To change this is a massive API change. Another 
alternative would to have some global variable (like the errno variable 
used in the C library) and require calling programs to check this. This
is not strictly an API change, but if we made it the default then it 
would be a big change in behaviour and would require user code changes 
to make the code safe. We could have it as an option though. More of a
problem would be making sure this worked for all language bindings. A
new function return the error flag would be one safe way. 

Actually have a separate function which returns the error flag probably 
is a clean way of doing it. We can use the global variable internally 
as well for higher level function to check that lower level functions
which may cause memory errors have exectuted without problems.

I've thought about this a lot in the past and we've had threads on list 
and not come up with a good way of changing past design mistakes (or 
features?) in a painless way.

Happy to be proved wrong of course and I'm not saying we shouldn't do 
something dramatic. We need to think it through careful though to
make sure it is the right design decision and try to make it as simple 
as possible for users.

In the meantime tidying up the code as you suggest will help minimise
the places changes are required.

Andrew

On Mon, Sep 22, 2014 at 03:17:36PM +0100, Phil Rosenberg wrote:
> This one is mostly directed at Alan but probably others will be interested 
> and may have comments. Git might also be a big help here, but I'm not sure 
> how it will work so advice from all appreciated.
> 
> I have been trying to improve memory management in plplot as part of my 
> attempt to try to remove exit calls. To do this I am removing raw pointer 
> arrays and replacing them with a struct which will give us more object 
> oriented access to memory allocation. I think this will be a generally good 
> thing as the struct can have function pointers which will allow trivial 
> resizing and adding elements. It will also be extendible, to allow further 
> functionality similar to std::vector if we want. Arrays will also know their 
> own size.
> 
> However the cost is that arrays in the plstream will all become structs so 
> will need accessing by somearray.mem[index] or maybe 
> somearray.getMem()[index] rather than somearray[index]. This has the 
> potential to break some or all the drivers. Although the fixes might be 
> trivial, I don't have easy access to all the drivers on my windows machine.
> 
> I'm therefore looking for a suggestion of how to proceed. I can transfer 
> stuff to my Linux machine, but I'm not sure how best to do that with git. I 
> could create a fork on github so other developers can contribute, but if I 
> create a public fork then we should merge that into the master branch rather 
> than rebase it which I think is not compliant with our current workflow.
> 
> Any suggestions greatly appreciated.
> 
> Phil

> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

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


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Debian bug 761057

[Andrew Ross]

On Thu, Sep 18, 2014 at 09:02:39AM -0700, Alan Irwin wrote:
> On 2014-09-18 14:13+0100 Andrew Ross wrote:
> 
> >
> >I've completely reformatted the debian copyright file (using the new
> >machine readable format) and done some grepping for rogue files. I've
> >attached a copy and I think this identified all the non-LGPL files (
> >parts of files) apart from the additional libraries shipped in lib
> >(which I also need to deal with and have an outstanding bug report).
> >
> >This list might be useful more generally. It would be great if we
> >could tidy up the odd license files for consistency. In particular
> >whether examples are GPL or LGPL is a bit random.
> 
> Because PLplot has always been advertised as LGPL with a few minor
> exceptions, I suspect a large fraction of the GPL licensing was not
> deliberate, but simply an oversight.  Getting all those instances
> changed to LGPL would be an excellent goal just to improve our
> licensing consistency, but it does require contacting all the
> copyright holders and getting their permission for the change.
> 
> To get that process started, would all active developers here agree to
> changing the licensing to LGPL2+, i.e., the exactly licensing
> conditions that appear in COPYING.LIB for all PLplot files where they
> hold copyright and which are currently licensed under some form of
> LGPL that is not LGPL2+ or licensed under some form of GPL?
> 
> I certainly give my own permission for such licensing changes
> (assuming all other copyright holders for the files in question
> agree), and my hope (to improve our licensing consistency) is that all
> other core developers here will explicitly state the same in a reply
> to this e-mail.

You have my permission too.

Andrew

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Debian bug 761057

[Andrew Ross]

On Thu, Sep 18, 2014 at 09:31:21AM -0700, Alan Irwin wrote:
> On 2014-09-18 14:13+0100 Andrew Ross wrote:
> 
> >
> > I've completely reformatted the debian copyright file (using the new
> > machine readable format) and done some grepping for rogue files. I've
> > attached a copy and I think this identified all the non-LGPL files (
> > parts of files) apart from the additional libraries shipped in lib
> > (which I also need to deal with and have an outstanding bug report).
> 
> I have not looked at the list in general, but I 
> notice you missed some files, e.g., src/mt19937ar.[ch] and
> cmake/epa_build/ExternalProject.cmake which are clearly licensed under
> a non-LGPL license.  Note those files are found by the find command I
> suggested,
> 
> find . -type f |grep -v .git \
> |xargs grep -li copyright| xargs grep -Li "public license"
> 
> so I am a bit puzzled why they are missing from your list.  Of
> course, the above command does not discriminate between GPL
> and LGPL, but I guess you have that covered with a slight variation
> of the above command.

I was searching in a different way and clearly missed these. I'll double
check.

mt19937ar.[ch] are distributed under the standard BSD 3 clause license.

cmake/epa_build/ExternalProject.cmake is also distributed under the BSD 
license, as are some of the other cmake derived files.

I'll include these too. Incidentally, ExternalProject.cmake does not
contain the full license, but has a comment saying that if the file
is distributed outside cmake then the full license should be pasted
into the file. We don't do this and we probably should, or at least 
include the BSD license in our Copyright file.

Andrew

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Debian bug 761057

[Andrew Ross]

On Thu, Sep 18, 2014 at 07:03:05PM -0700, Alan Irwin wrote:
> On 2014-09-18 21:18+0100 Phil Rosenberg wrote:
> 
> > Hi Alan and Andrew
> 
> > The shapelib files from Ordnance Survey are my doing. You are right
> Alan that they are under licence rather than in the public domain,
> however, I used them specifically because they were available under an
> open type licence.
> 
> I agree this license seems fine.

Fine. The debian copyright notice is for the packages of the current 
release (5.10.0) which does not contain these files. The copyright 
notice came from data/README.shapefiles, which relates to the original
shapefiles used for the plmap, not the extra ones Phil has recently 
added for the Exmoor example. We should clarify the wording of 
data/README.shapefiles.

> > I did look hard and ordnance survey was the best
> source of files under any kind of open licence. I didn't find anything
> with a LGPL licence, so unless someone wants to generate maps of their
> own then we will almost certainly have to live with different licences
> here.
> 
> Agreed.
> 
> > I would have thought that the details I put in the folder with
> the files would suffice for the credit required by the licence. In
> fact this was the licence info provided to me. However I can see you
> might want to add details to the copyright file. I can do this, but
> don't want to cause a clash with Andrew's work.
> 
> Yes, I think Andrew should probably do the adjustment of the Copyright
> file since he is the one having to deal with bug reports about
> licensing.

I will - for the next release.
 
> @Andrew:
> The next paragraph is all my opinion, but I don't feel strongly about
> it.  Therefore, if you decide to deal with this license another way,
> that is fine with me.
> 
> The function of the Copyright file is ideally to collect all
> information for all licenses in one place.  However, this license for
> the Exmoor shapefile data is a fairly long license in PDF format
> rather than text so it should probably suffice to state in the
> Copyright file that the files in data/ss are subject to the licensing
> terms at
> http://www.ordnancesurvey.co.uk/oswebsite/opendata/docs/os-opendata-licence.pdf.
> This is almost exactly redundant with what Phil states in
> data/ss/os_open_conditions.txt, but such redundancy is fine, and that
> file explaining the licensing should remain with the data.

I agree - unless it proves to be controversial. You never can tell, particularly
when it comes to free / non-free licensing and Debian.

Andrew 

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Debian bug 761057

[Andrew Ross]

I've completely reformatted the debian copyright file (using the new 
machine readable format) and done some grepping for rogue files. I've
attached a copy and I think this identified all the non-LGPL files (
parts of files) apart from the additional libraries shipped in lib 
(which I also need to deal with and have an outstanding bug report).

This list might be useful more generally. It would be great if we 
could tidy up the odd license files for consistency. In particular
whether examples are GPL or LGPL is a bit random. 

Andrew

On Wed, Sep 17, 2014 at 11:47:30PM -0700, Alan Irwin wrote:
> On 2014-09-17 23:57+0100 Andrew Ross wrote:
> 
> >
> > Alan,
> >
> > My reading of the bug report was different to yours. There are a
> > number of files (e.g. examples which contain licenses different to
> > the LGPL. The debian/copyright file is supposed to contain mention
> > of ALL licenses which are applied to any part of the software. Some
> > (but not all) of the examples are GPL rather than LGPL.
> 
> Hmm.  That is true but that issue should be easy to fix, by using
> the following find command:
> 
> software@raven> find . -type f |grep -v .git \
> |xargs grep -li copyright| xargs grep -Li "public license" |wc -l
> 109
> 
> So there are 109 such files but presumably some of them are
> false positives, and when you replace "wc -l" by
> "xargs grep -i copyright -A20" (or whatever command seems reasonable
> to you), you will be able to figure out which of those 109 should be
> mentioned in Copyright.
> 
> However, I think you should also on general grounds include wording in
> Copyright specifically stating all files in the source code have the
> exact LGPL license terms in that file except for a list of exceptions
> that you (in the ~109 above) and I (assuming I switch from the current
> default LGPL to the specific openBSD documentation license for the
> doxygen-generated files) do need to refine.
> 
> His report did specifically mentioned some doxygen-generated files
> that had some non-lgpl copyright info in them .  But this is strong
> evidence of his complete misunderstanding of doxygen-generated files.
> Roughly a third of those are source listings in html form, and they
> necessarily include all the source text (i.e., from some of the 109
> above) and therefore mention all the copyright notices for that source
> code.  But that obviously has nothing to do with the actual generated
> file copyright which is a completely different matter!
> 
> Look up the list of his bug reports.  There are all similar to the one
> for PLplot so I think he has put together a script that blindly looks
> for all source code files that have the copyright word in them, and
> then files rather unintelligent reports (at least in the
> doxygen-generated case) about copyright inconsistencies he finds for
> those files.  So my semi-facetious guess is he will claim when I use
> the openBSD copyright text for doxygen-generated files even more
> copyright "inconsistencies" because those files (when reporting
> source) will have LGPL text in them as well as that openBSD
> documentation text.  At which point, he will have convincingly
> demonstrated he does not know the difference between documentation
> license and the license for the code quoted by that documentation.  At
> which point, his "bug report" for PLplot should be declared spam. :-)
> 
> 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
> __
> 
> --
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: plplot
Source: http://sf.net/plplot/
 Ups

Re: [Plplot-devel] Debian bug 761057

[Andrew Ross]

Alan,

My reading of the bug report was different to yours. There are a 
number of files (e.g. examples which contain licenses different to 
the LGPL. The debian/copyright file is supposed to contain mention
of ALL licenses which are applied to any part of the software. Some 
(but not all) of the examples are GPL rather than LGPL. 

The issue with the copyright of the doxygen .js files will be 
avoided as I am repackaging the plplot source for debian without
this pre-generated code. The reason is that Debian won't allow
shipping of obfuscated source code as it is in breach of the 
Debian free software guidelines. I don't currently include
them in the binary packages as I'm not quite sure they are
ready for prime time. When I do I can just regenerate it all 
anyway, which is fine.

Andrew

On Wed, Sep 17, 2014 at 02:59:48PM -0700, Alan Irwin wrote:
> As I have made clear in a response at
> , I think
> this Debian packaging bug concerning a very minor PLplot licensing
> issue is trivially easy to answer with a non-controversial change to
> our Copyright file that all files in the source tree which are not
> explicitly mentioned as having non-LGPL licensing in the Copyright
> file have the LGPL copyright terms that are explicitly mentioned in
> that file.) (Yeah, I know it is obvious, but some tweak to the wording
> like that is probably necessary to prevent more "licensing police"
> style bug reports that PLplot packagers have to put up with.) Anyhow,
> I have asked Andrew to deal with that wording tweak since he probably
> is most aware of the correct LGPL-style wording to use to deal with
> this default case.
> 
> It likely has nothing to do with the bug report, but the bug reporter
> did have some plausible points about missing explicit licensing terms
> for the man pages and generated doxgyen files which is definitely not
> an ideal situation.  The former are Rafael Laboissiere's business
> since he wrote those man pages, (which is why I CC'd him in that bug
> report), but the latter are our business since a number of you are
> helping out with the doxygen effort by adding appropriate
> doxygen-style comments in our source code.  Those doxygen-style
> comments will continue to be licenced under the LGPL, of course,
> because they are part of LGPL-licensed source code.
> 
> However, because we include the doxygen-generated results in our
> source tree (and also display them on our website) a decision is
> needed about what licensing terms we should adopt for those
> doxygen-generated (html) documentation files and associated display
> results (e.g., licensing terms inside an HTML comment and the same
> licensing terms written in HTML that an HTML-browser will render.)
> 
> I strongly lean (for documentation result consistency) toward using
> the exact licensing wording (i.e., freeBSD documentation licensing
> terms modified for PLplot) in those doxygen-generated HTML files that
> we currently use for all our docbook files and results generated from
> those docbook files.  Does anybody here who has been working on our
> doxygen-based documentation have any strong objections to that
> doxygen-generated file licensing approach?  If not, and assuming I can
> find the time to deal with this, I hope to make this change some time
> this week.
> 
> 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
> __
> 
> --
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [PATCH] QColor warning when Qt PlPlot widget is created

[Andrew Ross]

On Thu, Jul 17, 2014 at 10:09:03AM -0700, Alan Irwin wrote:
> On 2014-07-17 11:21-0400 Hazen Babcock wrote:
> 
> > On 7/11/2014 2:38 PM, Alan W. Irwin wrote:
> >> On 2014-07-03 12:33+0930 Jonathan Woithe wrote:
> >> 
> >>> Hi all
> >>> 
> >>> I have a relatively simple Qt program which utilises the PlPlot Qt widget
> >>> (QtExtWidget).  QtExtWidget is a component of the main application window
> >>> and as such is constructed during program startup, prior to the
> >>> calling of
> >>> QApplication::exec() and before any GUI elements have been made
> >>> visible with
> >>> show().  I have noticed that during program startup I will sometimes
> >>> get the
> >>> following warnings:
> >>>
> >>>  QColor::setRgb: RGB parameters out of range
> >>> 
> >>> This doesn't appear all the time and seems to be fairly sensitive to
> >>> timing,
> >>> making it difficult to debug.  However, after much trial and error I have
> >>> determined that the warning is triggered from the QtExtWidget
> >>> constructor.
> >>> Further exploration showed it was coming from QtPLWidget's constructor
> >>> (from which QtExtWidget is derived).
> >>> 
> >>> Looking at the source of QtPLWidget::QtPLWidget() in plqt.cpp, I
> >>> noticed a
> >>> call to QApplication::processEvents() which didn't seem right to me.
> >>> Commenting this out resolves the warning.  Importantly, the warning
> >>> remains
> >>> when any of the other Qt functions (such as resize(), QPen()) are
> >>> commented
> >>> out.
> >>> 
> >>> The reason I'm suspicious of this call is that there is no guarantee that
> >>> any event loop has even been initialised at the time the constructors are
> >>> called.  Certainly in my case the event loop isn't running because
> >>> QApplication::exec() has not yet been called at the time of construction.
> >>> Similarly, the widget tree is not visible at event creation time, so it
> >>> seems reasonable that some parts of the GUI environment (such as QColor
> >>> objects) might not have been allocated yet.  At a fundamental level, I
> >>> expect that the processEvents() call could be triggering a draw of the as
> >>> yet incompletely constructed widget.  I also recall reading in the
> >>> past that
> >>> draw actions cannot be triggered in constructors due to the incomplete
> >>> nature of the widget being built.
> >>> 
> >>> Regardless, I can't think of any reason for calling
> >>> QApplication::processEvents() in the constructor of a Qt widget.  Does
> >>> anyone know why this call is being made in QtPLWidget's constructor?
> >>> Based
> >>> on tests here and the reasons given above I think it should be
> >>> removed.  The
> >>> trivial patch to do this is included at the end of this email.
> >>> 
> >>> What do others think?
> >> 
> >> I don't understand Qt that well.  However, my own tests with the
> >> test_interactive target indicate your change is fine so I have
> >> committed it (revision 13137) with appropriate commentary to the svn
> >> trunk version (which will end up as our next release).
> >> 
> >> @Hazen: I thought I better commit this before it got lost.
> >> However, as our Qt expert feel free to revert this change, if you
> >> prefer some different solution.
> >
> > I'm not sure. If it doesn't break anything I guess it is probably ok. It 
> > looks like this was added by Andrew Ross in commit #10306 for Alban Rochel.
> 
> Thanks for digging out the relevant commit.  Since you are not
> completely sure, I followed up further with
> 
> svn diff --revision 10305:10306 bindings/qt_gui/plqt.cpp |less
> 
> to confirm that the above call to QApplication::processEvents() was
> part of a much more substantial change which probably nobody but Alban
> understood completely, and which may well have been trying that call
> experimentally (since Alban, who is no longer contributing code to
> PLplot, was an extremely fast developer who
> generally relied on us to test his changes).
> 
> Here is the relevant commit message:
> 
> 
> ANR for Alban Rochel - fixes for qt driver to support
> 
> - command line arguments for the qtext driver
> - flushing (as used in

Re: [Plplot-devel] Is Qt5 supported?

[Andrew Ross]

On Sat, Mar 15, 2014 at 08:21:46PM +, Andrew Ross wrote:
> Yes, that is all with 5.2.0. I've run make test_all_qt and all the 
> targets work except test_qt_example. Note you need the QtImageFormats 
> module for the tiff format. The other bitmap formats are available by 
> default. If you don't install the module then plplot just generates 
> empty files with no warning, as I discovered the hard way.

Changes to get qt_example working are pretty small. Now works in the 
build tree. Just need to fix the install tree case too.

Andrew

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is Qt5 supported?

[Andrew Ross]

On Fri, Mar 14, 2014 at 07:12:30PM -0700, Alan Irwin wrote:
> On 2014-03-15 00:28-0000 Andrew Ross wrote:
> 
> > OK. So the file not found error is a slight read herring. Following some
> > googling I tried
> >
> > LD_DEBUG=all test-drv-info qt
> >
> > and came up with the following error
> >
> >31836: 
> > /home/andrew/software/plplot/build_qt5/bindings/qt_gui/libplplotqtd.so.1: 
> > error: symbol lookup error: undefined symbol: _ZTV11QtExtWidget (fatal)
> >
> > so it is actually a problem with linking to libplplotqtd.
> 
> I had never heard of LD_DEBUG before, but when I googled for it, it
> does seem to be a powerful way to figure out linking issues on Linux.  So 
> thanks
> for drawing that weapon in the arsenal to my attention.

Neither had I until I stumbled across it in another post about debugging 
issues with dynamic loading of libraries. Definitely a useful thing
to remember.
 
> >
> > Looking further this turns out to be because moc is not being run on
> > include/qt.h.  There is a new automoc facility in CMake (which I assume
> > is what Alan's comment in include/CMakeLists.txt was referring to as the
> > "different method in Qt5". Our file usage doesn't appear to meet the
> > conditions for this though, and also we weren't actually setting the
> > automoc property! Anyway, you can still use the old method, but the cmake
> > is now qt5_wrap_cpp. I've changed back to using this and all works fine.
> 
> The impression I got from reading the (somewhat terse) information in
> http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html is
> that for 2.8.9 (our minimum CMake version) or later versions of CMake,
> that the qt5_use_modules macro is all that needs to be called.  For
> example, qt5_wrap_cpp is only mentioned for the case of CMake version
> 2.8.3 (or above).  So the impression left is that it will work, as you
> have found, but it is old-fashioned if you can guarantee your users
> are using 2.8.9 or above (as in our case).  However, the only other
> mention of automoc in that document is for 2.8.11 (which we cannot
> guarantee for our users) or above where automoc target properties and
> the CMAKE_AUTOMOC variable which controls are apparently first
> available for CMake in a way that supports Qt5.  (The corresponding
> cmake documentation for 2.8.9 does mention CMAKE_AUTOMOC, but goes out
> of its way to mention only Qt4 for that case.) So I now suspect you
> have found the only possibility that will work for all our users until
> we bump our minimum CMake version from 2.8.9 to at least 2.8.11.
> 
> In sum I suspect your changes were the only way to go for now.  I also
> (revision 13059) made an additional change for didactic reasons, but
> this additional change should have no practical consequences.

Sounds a good idea. It might be worth experimenting with the new support, 
but for now the approach works on both Qt4 and Qt5.

> > With this final change I can now compile and run plplot and the examples
> > with qt5.
> 
> Were all your good test results for Qt-5.2.0?  If so, please commit
> the approprate change to cmake/modules/qt.cmake to lower the current minimum
> version of Qt5 that we support from 5.2.1 to 5.2.0.

Yes, that is all with 5.2.0. I've run make test_all_qt and all the 
targets work except test_qt_example. Note you need the QtImageFormats 
module for the tiff format. The other bitmap formats are available by 
default. If you don't install the module then plplot just generates 
empty files with no warning, as I discovered the hard way.

I've lowered the minimum requirements to 5.2.0.
 
Andrew

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is Qt5 supported?

[Andrew Ross]

On Fri, Mar 14, 2014 at 11:10:10PM +, Andrew Ross wrote:
> On Thu, Mar 13, 2014 at 07:15:07PM -0700, Alan Irwin wrote:
> > On 2014-03-13 16:24-0700 Alan W. Irwin wrote:
> > 
> > > On 2014-03-13 22:30- Andrew Ross wrote:
> > >> [...]Commenting
> > >> out the call to this function for QT5 leads to the build failing since it
> > >> can't find the Qt5 header files.
> > >
> > > I don't understand that result (which for the Qt5 case is equivalent
> > > to my fix) since RM got a lot further, but he apparently used the
> > > default dynamic devices while you have specifically requested static
> > > devices for some reason with -DENABLE_DYNDRIVERS=OFF which triggered
> > > the bad call to set_qt_target_properties for the Qt5 case which has
> > > now been fixed. Since static devices are always a bit tricky, could
> > > you use the dynamic devices to start with at least? Of course, you
> > > should also follow my suggestion to RM that he set -DPLD_epsqt=OFF to
> > > exclude PostScript-relevant code that is not supported by Qt5.
> > 
> > P.S.
> > 
> > If you still cannot get as far as RM for the dynamic drivers case,
> > then there are two other possibilities to watch out for that are not
> > an issue for RM.
> > 
> > (1) On Linux distributions, Qt5 has to find a way to coexist with the
> > Qt4 installation within the same Unix file system hierarchy, and it is
> > pretty clear from my reading that the Qt developers prefer two
> > completely separate install prefixes for Qt4 and Qt5 instead.  So you
> > may have to take some extra measures (say by specifying
> > CMAKE_INCLUDE_PATH or by using some of the methods recommended in
> > <http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html> ) to
> > be sure the Qt5 headers are found for whatever location Debian has
> > decided to install those headers.
> > 
> > (2) The Debian 5.2.0 version of Qt may have some bugs in the
> > qt5_use_modules CMake function it provides.  Since our Qt5
> > build-system logic relies on completely on that function, using
> > Qt-5.2.1 (the version that was discussed on the CMake list in answer
> > to my Qt5 questions there) might be essential.  While waiting for
> > Qt-5.2.1 to propagate to Linux distros, a possible fallback is to
> > build it ourselves using epa_build. Therefore, I might try
> > implementing that epa_build in the next few days to see how far I get.
> 
> Alan,
> 
> I'd not spotted the static drivers - this was an oversight on my part 
> when installing packages on the pbuilder chroot.
> 
> Turns out the problem wasn't related to that though. In Qt5 the QPrinter
> class is in the QtPrintSupport module, which was not being used. Adding 
> this to the list of required modules fixed the include problems. 
> 
> I then encountered the problem with the shared code between eps and pdf
> drivers that RM encountered. Turns out the only problem is that there
> is a mention of QPrinter::PostScriptFormat which does not exist any more
> with Qt5. Wrapping this with #ifndef PLPLOT_USE_QT5 avoids the problem.
> 
> I'll commit these two fixes.
> 
> So I can now compile all the qt drivers statically, but test-drv-info fails
> with a file not found error, even though the qt.so driver is there and looks
> ok. Clearly there is something odd about this, so I will investigate further.
> So far this is promising though.

OK. So the file not found error is a slight read herring. Following some 
googling I tried

LD_DEBUG=all test-drv-info qt

and came up with the following error

31836: 
/home/andrew/software/plplot/build_qt5/bindings/qt_gui/libplplotqtd.so.1: 
error: symbol lookup error: undefined symbol: _ZTV11QtExtWidget (fatal)

so it is actually a problem with linking to libplplotqtd. 

Looking further this turns out to be because moc is not being run on 
include/qt.h.  There is a new automoc facility in CMake (which I assume 
is what Alan's comment in include/CMakeLists.txt was referring to as the 
"different method in Qt5". Our file usage doesn't appear to meet the 
conditions for this though, and also we weren't actually setting the 
automoc property! Anyway, you can still use the old method, but the cmake 
is now qt5_wrap_cpp. I've changed back to using this and all works fine.

With this final change I can now compile and run plplot and the examples
with qt5. 

RM, how do you get on with these latest changes?

Andrew

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is Qt5 supported?

[Andrew Ross]

On Thu, Mar 13, 2014 at 07:15:07PM -0700, Alan Irwin wrote:
> On 2014-03-13 16:24-0700 Alan W. Irwin wrote:
> 
> > On 2014-03-13 22:30- Andrew Ross wrote:
> >> [...]Commenting
> >> out the call to this function for QT5 leads to the build failing since it
> >> can't find the Qt5 header files.
> >
> > I don't understand that result (which for the Qt5 case is equivalent
> > to my fix) since RM got a lot further, but he apparently used the
> > default dynamic devices while you have specifically requested static
> > devices for some reason with -DENABLE_DYNDRIVERS=OFF which triggered
> > the bad call to set_qt_target_properties for the Qt5 case which has
> > now been fixed. Since static devices are always a bit tricky, could
> > you use the dynamic devices to start with at least? Of course, you
> > should also follow my suggestion to RM that he set -DPLD_epsqt=OFF to
> > exclude PostScript-relevant code that is not supported by Qt5.
> 
> P.S.
> 
> If you still cannot get as far as RM for the dynamic drivers case,
> then there are two other possibilities to watch out for that are not
> an issue for RM.
> 
> (1) On Linux distributions, Qt5 has to find a way to coexist with the
> Qt4 installation within the same Unix file system hierarchy, and it is
> pretty clear from my reading that the Qt developers prefer two
> completely separate install prefixes for Qt4 and Qt5 instead.  So you
> may have to take some extra measures (say by specifying
> CMAKE_INCLUDE_PATH or by using some of the methods recommended in
> <http://doc-snapshot.qt-project.org/qt5-stable/cmake-manual.html> ) to
> be sure the Qt5 headers are found for whatever location Debian has
> decided to install those headers.
> 
> (2) The Debian 5.2.0 version of Qt may have some bugs in the
> qt5_use_modules CMake function it provides.  Since our Qt5
> build-system logic relies on completely on that function, using
> Qt-5.2.1 (the version that was discussed on the CMake list in answer
> to my Qt5 questions there) might be essential.  While waiting for
> Qt-5.2.1 to propagate to Linux distros, a possible fallback is to
> build it ourselves using epa_build. Therefore, I might try
> implementing that epa_build in the next few days to see how far I get.

Alan,

I'd not spotted the static drivers - this was an oversight on my part 
when installing packages on the pbuilder chroot.

Turns out the problem wasn't related to that though. In Qt5 the QPrinter
class is in the QtPrintSupport module, which was not being used. Adding 
this to the list of required modules fixed the include problems. 

I then encountered the problem with the shared code between eps and pdf
drivers that RM encountered. Turns out the only problem is that there
is a mention of QPrinter::PostScriptFormat which does not exist any more
with Qt5. Wrapping this with #ifndef PLPLOT_USE_QT5 avoids the problem.

I'll commit these two fixes.

So I can now compile all the qt drivers statically, but test-drv-info fails
with a file not found error, even though the qt.so driver is there and looks
ok. Clearly there is something odd about this, so I will investigate further.
So far this is promising though.

Andrew

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is Qt5 supported?

[Andrew Ross]

On Wed, Mar 12, 2014 at 02:28:16PM -0700, Alan Irwin wrote:
> On 2014-03-12 19:48-0000 Andrew Ross wrote:
> 
> > On Wed, Mar 12, 2014 at 11:10:07AM -0700, Alan Irwin wrote:
> >> On 2014-03-11 11:22-0700 Alan W. Irwin wrote:
> >>
> >>> Therefore, my conclusion is we should wait for something like another
> >>> year before we attempt to make PLplot work with Qt5.  There
> >>> are several benefits to such a substantial delay.
> >>>
> >>> (1) A delay will allow us to bump our minimum CMake version (currently
> >>> 2.8.9) to 2.8.11 which is currently required to take advantage of the
> >>> latest CMake infrastructure support for finding Qt5 components.
> >>> Typically we wait to bump that minimum version until Debian stable
> >>> includes that minimum version of CMake as a signal that most modern
> >>> Linux distributions are likely to carry at least that minimum version
> >>> of CMake.  The release date of the next Debian stable version is still
> >>> TBA, but it should roughly be a year or so from now if the Debian
> >>> track record for the length of previous release cycles continues for
> >>> this Debian release cycle.
> >>>
> >>> (2) Assuming CMake-2.8.11 constitutes the last big change in
> >>> infrastructure support, a delay also allows the Qt5 part of the find
> >>> methods to completely settle down to take advantage of that new
> >>> infrastructure.
> >>>
> >>> (3) A delay allows the Qt5 software itself to settle down.  PLplot
> >>> triggered a number of bugs that existed for Qt4.x before Qt4.5 was
> >>> released, and the same type of bug issues are likely to occur for
> >>> early Qt5.x versions as well.
> >>>
> >>> (4) A delay gives me a chance to get access to a well-debugged version
> >>> of Qt5.x myself.  For example, I am likely to move to Debian testing
> >>> (which allows Qt5 to be installed) within the next year or else that
> >>> version will be released as the next Debian stable release. Such
> >>> access will allow me to implement (as de facto chief maintainer for
> >>> our build system) the build-system changes needed to allow users
> >>> access to Qt5.
> >>>
> >>
> >> RM, despite all those caveats, I have changed my mind about delaying
> >> this since I have been recently most encouraged by the helpful
> >> comments on the CMake mailing list concerning finding Qt5.  So later
> >> today I will try to implement an experimental option for the PLplot
> >> build system so that it will be able to find Qt5.  Of course, it will
> >> all be blind development on my part since I don't currently have
> >> access to Qt5, but it turns out finding Qt5 is actually pretty simple
> >> so there is a reasonable chance this experimental option will work for you
> >> immediately or after one iteration when I deal with any build-system
> >> issues that you find with Qt5.
> >>
> >> Once that build-system option works for you, it should allow you to
> >> see whether there are any API changes between Qt4 and Qt5 that you
> >> have to be concerned with.
> >
> > Alan,
> >
> > If you are able to implement this I'll try using my Debian unstable
> > pbuilder environment. Should give fairly easy access to Qt5.
> 
> To Andrew and RM:
> 
> I have implemented an experimental version of Qt5 find support as of
> revision 13050 in our svn trunk version.  This support defaults to OFF
> so to turn it ON you must specify the cmake command-line option
> -DPLPLOT_USE_QT5=ON.
> 
> I have tested the -DPLPLOT_USE_QT5=ON case for my strictly Qt4
> platform.  As expected it warned me that it could not find Qt5 and
> then it fell back to looking for Qt4 (just as I designed it).  I also
> tried the test_qt_all target which does what its name implies. All was
> well there indicating my fairly extensive Qt5-related build system
> changes hadn't screwed up anything with our current Qt4 support.
> 
> Anyhow, for those here like you guys with access to Qt5, please give
> -DPLPLOT_USE_QT5=ON a try.  Note this Qt5 support is only bare bones
> at this stage (certain things like pyqt and pkg-config Qt support are
> disabled for this case as denoted by a FIXME comment).  But we can add
> all the bells and whistles later once the fundamental question (does
> the qt device driver build and run properly with Qt5) is answered.
> 
> Note if your Qt5 installation is in a non-standard loca

Re: [Plplot-devel] Is Qt5 supported?

[Andrew Ross]

On Wed, Mar 12, 2014 at 11:10:07AM -0700, Alan Irwin wrote:
> On 2014-03-11 11:22-0700 Alan W. Irwin wrote:
> 
> > Therefore, my conclusion is we should wait for something like another
> > year before we attempt to make PLplot work with Qt5.  There
> > are several benefits to such a substantial delay.
> >
> > (1) A delay will allow us to bump our minimum CMake version (currently
> > 2.8.9) to 2.8.11 which is currently required to take advantage of the
> > latest CMake infrastructure support for finding Qt5 components.
> > Typically we wait to bump that minimum version until Debian stable
> > includes that minimum version of CMake as a signal that most modern
> > Linux distributions are likely to carry at least that minimum version
> > of CMake.  The release date of the next Debian stable version is still
> > TBA, but it should roughly be a year or so from now if the Debian
> > track record for the length of previous release cycles continues for
> > this Debian release cycle.
> >
> > (2) Assuming CMake-2.8.11 constitutes the last big change in
> > infrastructure support, a delay also allows the Qt5 part of the find
> > methods to completely settle down to take advantage of that new
> > infrastructure.
> >
> > (3) A delay allows the Qt5 software itself to settle down.  PLplot
> > triggered a number of bugs that existed for Qt4.x before Qt4.5 was
> > released, and the same type of bug issues are likely to occur for
> > early Qt5.x versions as well.
> >
> > (4) A delay gives me a chance to get access to a well-debugged version
> > of Qt5.x myself.  For example, I am likely to move to Debian testing
> > (which allows Qt5 to be installed) within the next year or else that
> > version will be released as the next Debian stable release. Such
> > access will allow me to implement (as de facto chief maintainer for
> > our build system) the build-system changes needed to allow users
> > access to Qt5.
> >
> 
> RM, despite all those caveats, I have changed my mind about delaying
> this since I have been recently most encouraged by the helpful
> comments on the CMake mailing list concerning finding Qt5.  So later
> today I will try to implement an experimental option for the PLplot
> build system so that it will be able to find Qt5.  Of course, it will
> all be blind development on my part since I don't currently have
> access to Qt5, but it turns out finding Qt5 is actually pretty simple
> so there is a reasonable chance this experimental option will work for you
> immediately or after one iteration when I deal with any build-system
> issues that you find with Qt5.
> 
> Once that build-system option works for you, it should allow you to
> see whether there are any API changes between Qt4 and Qt5 that you
> have to be concerned with.

Alan,

If you are able to implement this I'll try using my Debian unstable 
pbuilder environment. Should give fairly easy access to Qt5.

Andrew

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Boolean command line arguments

[Andrew Ross]

On Fri, Mar 07, 2014 at 05:46:05PM -0800, Alan Irwin wrote:
> On 2014-03-07 10:06-0000 Andrew Ross wrote:
> 
> >
> >I was just going to go ahead and change example 8 to use
> >the sombrero function by default. This reminded me of a
> >long running "feature" of plplot which I have found irksome
> >in the past, namely that boolean command options can only
> >set an option to true (1) not false (0).
> 
> Perhaps I am missing something, but wouldn't it be straightforward to
> implement such options exactly like we implement driver options,
> where, for example, we can set -drvopt text_clipping=0 or -drvopt
> text_clipping=1 for the xcairo device?

You could do in this way, but that would require more recoding. It is as 
much a matter of principle that it seems perverse to have a boolean flag
which you can switch on, but not off.

Andrew

--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Boolean command line arguments

[Andrew Ross]

I was just going to go ahead and change example 8 to use
the sombrero function by default. This reminded me of a
long running "feature" of plplot which I have found irksome
in the past, namely that boolean command options can only 
set an option to true (1) not false (0).

So for example in example 8, we have a variable sombrero 
which is set to zero by default, but I can set to one by
using the command line option -sombrero. Suppose I want to
change the default to sombrero = 1, but still have the
option to turn off this feature from the command line.
Currently I can't do this without rewriting the example and
changing the command line option. What I'd like is to be
able to have an option like -nosombrero which sets the
variable to 0. 

I've got two ways to do this
1) Automatically add a command line option -noopt for every
boolean command line option -opt. This is simple, requires
no action on the part of the end user, BUT it might upset
any existing codes which already had -opt and -noopt
options. I think I could work around this so the existing
options took precedence, but it might still be slightly
confusing.
2) Add in different versions of PL_OPT_BOOL, say PL_BOOL_T,
PL_OPT_BOOL_F and PL_OPT_BOOL_TF. PL_OPT_BOOL_T be the same
as the current PL_OPT_BOOL so would leave existing codes
unchanged. PL_BOOL_F would be similar, but would always set
the variable to false (0). PL_BOOL_TF would be like option
1) above and would automatically create a -opt and -noopt
version of every bool command line option. This is
completely backwards compatible, but is definitely more
complicated (unnecessarily so?) and would require code
changes to take advantage of the new feature.

Does anyone have any strong feelings on this?

Andrew


--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Additional "plsurf3dl" pages for standard example 8

[Andrew Ross]

On Wed, Mar 05, 2014 at 08:18:59AM -0800, Alan Irwin wrote:
> [This was originally sent to plplot-general in error.  Please reply
> on this list, plplot-devel.]
> In my research I use the plsurf3dl function quite a lot to plot
> FreeEOS results as a function of density and temperature since those
> results typically are only defined for an irregular X,Y region where
> the Y index limits are a function of the X index. The reason why I
> have non-constant Y limits is because for certain densities the
> FreeEOS calculation that models stellar conditions fails at
> temperatures that are too low or temperatures that are too high, and
> those failure limits do not follow a nice smooth curve.
> 
> The plsurf3dl function has long been part of the PLplot API. I
> recently (just before the release) documented it in api.xml and now I
> have also decided to include it in standard example 8.  For this case
> (revision 13039), I have chosen indexymin and indexymax limits that
> follow an ellipse (subject, of course, to index quantization errors).
> I have attached the result for the -sombrero case for the fourth page
> of the revised example 8 so you can get a feel for what the plotted
> results look like.  The edges are definitely not smooth since that is
> the nature of the beast when index limits are imposed.  However, that
> is why plsurf3dl is ideal for plotting results from scientific
> calculations of some model function representing the real universe
> (e.g., pressure as a function of density and temperature) with two
> independent variables which typically do have Y index limits which are
> functions of the X index rather than constants.
> 
> Frankly, the elliptical limits look better with the -sombrero version
> of the function so I am thinking of a further change to this example
> such that the sombrero variant of the function is always used for the
> fourth and eighth pages.  But further suggestions to make these extra
> pages pleasing to the eyes would be welcome before we propagate this
> change for standard example 8 to the rest of our languages.

Alan,

I agree this is a useful addition to the example, and it is certainly 
good to ensure the API is as fully tested by the examples as possible.
I also agree that the sombrero variant looks better (for all the pages
and not just for the new ones) so I'd go ahead and make that change 
unless anyone else objects.

Andrew

--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Phil Rosenberg joins the developers team

[Andrew Ross]

we're delighted that Phil Rosenberg has agreed to join the
PLplot developers team. Phil has been an active user for a
number of years and a regular contributor on this list. His
testing and improvement of PLplot on windows has been
invaluable. He has also contributed his expertise to
improving the wxwidget driver and the support for shapefile
maps amongst other areas. I'm sure Phil's skills and
experience will make a valuable addition to the PLplot
team.

Thanks!

Andrew


--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Octave 3.8 support

[Andrew Ross]

Following some testing on Debian sid, I've managed to get plplot svn working 
properly with octave 3.8. This requires swig 2.0.12 to work. I've also had to 
fix our examples and scripts due to some changes in octave 3.8. These changes 
are all backwards compatible with octave 3.6.


--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Test summaries for README.release need editing

[Andrew Ross]

On Thu, Dec 19, 2013 at 06:26:48PM -0800, Alan Irwin wrote:
> On 2013-12-19 16:11-0800 Alan W. Irwin wrote:
> 
> > On 2013-12-19 22:50- Andrew Ross wrote:
> >> Eventually I managed to get through almost all the tests though. The
> >> only issue I encountered was a segfault with the C++ qt_example for the
> >> nondyndriver case. Valgrind shows an invalid call to free / delete and
> >> a memory access violation. The shared case is fine with valgrind so I
> >> assume it is something about the static drivers.
> >
> >>
> >> For the fully static case I do not get a segfault, but valgrind shows a
> >> load or invalid reads in wx libraries ?!?
> >>
> >> Alan, do your tests reproduce this? I'll try a debug build to see if I
> >> can get to the bottom of it.
> >
> > qt_example has had a severe memory management issue in the recent past
> > (say over the last year or so)
> > which I worked around by not permitting qt_example to be built for the
> > static drivers case (e.g., for the PLplot-5.9.10 release).  But my
> > recent build-system changes for the Qt4-related parts of the PLplot
> > build solved that issue (as confirmed by valgrind) so I enabled
> > qt_example again for the static drivers case.
> >
> > But in light of your seeing more symptoms, I will check that again
> > with valgrind runs for my system version of Qt4 and also the epa_build
> > version of Qt4 and get back to you with those results. Please keep in
> > touch on what your further investigation finds as well. It's possible
> > the qt_example memory management trouble only occurs for certain
> > versions of Qt4.
> 
> Here is the build-tree result for the system version of Qt4 (i.e.,
> 
> -- Found Qt4: /usr/bin/qmake (found suitable version "4.8.2", minimum
> required is "4.8.2") 
> -- NP_QT_COMPILE_DEFINITIONS = QT_SVG_LIB;QT_GUI_LIB;QT_CORE_LIB
> -- QT_COMPILE_DEFINITIONS = -DQT_SVG_LIB;-DQT_GUI_LIB;-DQT_CORE_LIB
> -- NP_QT_INCLUDE_DIRECTORIES = 
> /usr/include/qt4;/usr/include/qt4/QtSvg;/usr/include/qt4/QtGui;/usr/include/qt4/QtCore
> -- QT_INCLUDE_DIRECTORIES = -isystem /usr/include/qt4;-isystem 
> /usr/include/qt4/QtSvg;-isystem /usr/include/qt4/QtGui;-isystem 
> /usr/include/qt4/QtCore
> ) for the -DENABLE_DYNDRIVERS=OFF case and after
> running "make test_qt_example" to build all the dependencies of
> qt_example:
> 
> ==31199== Memcheck, a memory error detector
> ==31199== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==31199== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==31199== Command: examples/c++/qt_example
> ==31199== 
> ==31199== 
> ==31199== HEAP SUMMARY:
> ==31199== in use at exit: 275,941 bytes in 2,457 blocks
> ==31199==   total heap usage: 44,202 allocs, 41,745 frees, 15,616,431 bytes 
> allocated
> ==31199== 
> ==31199== LEAK SUMMARY:
> ==31199==definitely lost: 3,888 bytes in 37 blocks
> ==31199==indirectly lost: 11,082 bytes in 223 blocks
> ==31199==  possibly lost: 2,448 bytes in 7 blocks
> ==31199==still reachable: 258,523 bytes in 2,190 blocks
> ==31199== suppressed: 0 bytes in 0 blocks
> ==31199== Rerun with --leak-check=full to see details of leaked memory
> ==31199== 
> ==31199== For counts of detected and suppressed errors, rerun with: -v
> ==31199== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 8)
> 
> Here is the equivalent -DENABLE_DYNDRIVERS=OFF build-tree results for the 
> epa_build version of Qt4 (which I
> obtained by running "make build_qt4_lite" under epa_build
> and simply changing the PATH prior to my ordinary PLplot build
> so that qmake version was found (which sucks in the rest of that
> version of Qt4).
> 
> -- Found Qt4: /home/wine/newstart/build_script/install-linux/bin/qmake (found 
> suitable version "4.8.5", minimum required is "4.8.2") 
> -- NP_QT_COMPILE_DEFINITIONS = QT_SVG_LIB;QT_GUI_LIB;QT_CORE_LIB
> -- QT_COMPILE_DEFINITIONS = -DQT_SVG_LIB;-DQT_GUI_LIB;-DQT_CORE_LIB
> -- NP_QT_INCLUDE_DIRECTORIES = 
> /home/wine/newstart/build_script/install-linux/include;/home/wine/newstart/build_script/install-linux/include/QtSvg;/home/wine/newstart/build_script/install-linux/include/QtGui;/home/wine/newstart/build_script/install-linux/include/QtCore
> -- QT_INCLUDE_DIRECTORIES = -isystem 
> /home/wine/newstart/build_script/install-linux/include;-isystem 
> /home/wine/newstart/build_script/install-linux/include/QtSvg;-isystem 
> /home/wine/newstart/build_script/install-linux/include/QtGui;-isystem 
> /home/wine/newstart/build_script/install-linux/include/QtCore
> 
> ==51

Re: [Plplot-devel] Test summaries for README.release need editing

[Andrew Ross]

On Thu, Dec 19, 2013 at 02:52:55PM -0800, Alan Irwin wrote:
> On 2013-12-19 22:26-0000 Andrew Ross wrote:
> 
> > Cmake chose to build a static library, not me, so I assume something was
> > missing for building shared versions.
> 
> I assume you are discussing just the PLplot part of the epa_build.  Just
> like for ordinary PLplot builds the default should be shared
> libraries, see
> 
> option(BUILD_SHARED_LIBS "Build shared libraries" ON)
> 
> in cmake/modules/plplot.cmake.
> 
> What does your cache file say about that option?  I don't know of any
> logic in our build system that would turn it to OFF unless the user
> explicitly uses -DBUILD_SHARED_LIBS=OFF as a cmake option for an
> ordinary build or that variable was set for an epa_build of PLplot
> (which it isn't as far as I can tell).  So I hope you can figure out
> what is going on here.

I've probably not been clear. The problem arose with libharu not plplot. By 
default this builds both shared and static versions. The problem arose with
the static build.

For plplot I have libltdl missing so I end up with 
ENABLE_DYNDRIVERS:BOOL=OFF
BUILD_SHARED_LIBS:BOOL=ON
but that is an aside.

> >> [...]when I follow those directions here, I get the following RPATH 
> >> results:
> >>
> >> -- TCL_RPATH = 
> >> /home/wine/newstart/build_script/install-linux_buildtools/lib
> >> -- TCL_TK_RPATH = 
> >> /home/wine/newstart/build_script/install-linux_buildtools/lib
> >> -- TCL_TK_ITCL_ITK_RPATH = 
> >> /home/wine/newstart/build_script/install-linux_buildtools/lib;/home/wine/newstart/build_script/install-linux_buildtools/lib/itcl3.4;/home/wine/newstart/build_script/install-linux_buildtools/lib/itk3.3
> >>
> >> If you don't get lines similar to the above, then those variables have
> >> been emptied because they point to the system locations as explained
> >> above. The above variables are used appropriately in the PLplot build
> >> system so at least for my case is not necessary for me to set
> >> LD_LIBRARY_PATH.
> >
> > I get just this, so cmake is setting the RPATH variables correctly. ldd
> > on libplplotd.so in the build directory looks fine, but ldd in the
> > install directory can't find itcl or itk. The tcl and tk libraries are
> > found fine in their epa install location. This is most odd...
> 
> I just discovered the other day that
> 
> readelf -d  |grep -i rpath
> 
> could help confirm what rpath values were actually being set for a library.
> Of course, "make VERBOSE=1" does that as well but buried so deep in
> details it is tough to figure out.

In the install tree

readelf -d libitcl3.4.so 
shows rpath is not set. On the other hand
readelf -d libtcl8.6.so 
correctly sets rpath. 

Andrew

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Test summaries for README.release need editing

[Andrew Ross]

On Thu, Dec 19, 2013 at 10:29:00PM +, Andrew Ross wrote:
> On Thu, Dec 19, 2013 at 11:19:59AM -0800, Alan Irwin wrote:
> > I believe I have now fixed that issue with revision 12888.
> > 
> > And since you are currently failing on yelp-xsl, that implies that
> > build_plplot_lite (which does not depend on yelp) finished without
> > issues for you, and you went on to try build_plplot (which does
> > depend on yelp indirectly via the pango dependencies).
> > 
> > Your results for epa_build on CentOS are extremely encouraging so far,
> > and I am glad to hear they have already been a practical help for you
> > on that platform.
> 
> I'll give this a go and let you know how I get on.

I can confirm using cmake -E tar rather than tar directly works fine.
I've run into other problems though and run out of time for more 
testing. I'll focus on the qt_example problem.

Andrew

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Test summaries for README.release need editing

[Andrew Ross]

On Thu, Dec 19, 2013 at 01:48:31PM -0700, Jerry wrote:
> 
> On Dec 19, 2013, at 6:10 AM, Andrew Ross  
> wrote:
> 
> > 
> > I plan to try the comprehensive test script for my Debian based 
> > configurations 
> > later. In the meantime I've been trying to build plplot on a CentOS 5.10 
> > machine at work. This is old software now and I expected problems. I also
> > have no root access so have to work with what's there.
> > 
> > I build only cmake from scratch then tried to build plplot.
> > 
> > Many drivers / bindings were disabled anyway since components were missing 
> > from the system. Bugs I encountered were
> > 
> > [ 18%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o
> > plplot.ads:24:05: "Ada.Numerics.Long_Real_Arrays" is not a predefined 
> > library unit
> > plplot.ads:24:05: "Plplot (body)" depends on "Plplot (spec)"
> > plplot.ads:24:05: "Plplot (spec)" depends on "Plplot_Thin (spec)"
> > plplot.ads:24:05: "Plplot_Thin (spec)" depends on "Plplot_Auxiliary (spec)"
> > plplot.ads:24:05: "Plplot_Auxiliary (spec)" depends on 
> > "Ada.Numerics.Long_Real_Arrays (spec)"
> > make[2]: *** [bindings/ada/CMakeFiles/plplotadad.dir/plplot.o] Error 1
> > make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2
> > 
> > Old version of gnat (4.1.2) probably the cause. I disabled Ada and continued
> 
> This is my bad. In Ada 2005 (which I have in the distant past incorrectly 
> called Ada 2007), there was a new numerics annex added which includes type 
> declarations for vectors and matrices along with operations on them, in 
> Ada.Numerics.Long_Real_Arrays. For the PLplot bindings, I did not want to 
> force users to use Ada 2005 but to get by with Ada 95. However, I wanted to 
> make using the new feature available as an option. Since Ada has no switches, 
> the only way to do this that I could figure out was to do some minor 
> commenting in PLplot_Auxiliary.ads. For my personal use, I always edit this 
> file to use the new numerics annex, so obviously I forgot to revert this file 
> before some recent commit. It was bound to happen sometime. So I've corrected 
> the file and now the Ada bindings should compile once again on older Ada 
> compilers.
> 
> Sorry for the problem.

Jerry,

Thanks for the quick fix!

Andrew

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Test summaries for README.release need editing

[Andrew Ross]

On Wed, Dec 18, 2013 at 09:35:52PM +, Andrew Ross wrote:
> On Wed, Dec 18, 2013 at 09:06:53AM -0800, Alan Irwin wrote:
> > To Andrew, Jerry, Arjen, and Phil:
> > 
> > There are some important questions below for you. I need those
> > questions answered for the release notes (README.release) for the
> > forthcoming release.
> > 
> > For example, when I am done with my testing, my test summary
> > in README.release will read
> > 
> > Comprehensive tests for a complete system build environment were run
> > on 64-bit Debian Wheezy Linux on AMD-64 hardware.
> > 
> > Comprehensive tests for a limited (qt, cairo, and wxwidgets PLplot
> > components were dropped) epa_build environment were run on 64-bit
> > Debian Wheezy Linux on AMD-64 hardware.
> > 
> > Comprehensive tests for a complete epa_build environment were run
> > on 64-bit Debian Wheezy Linux on AMD-64 hardware.
> > 
> > Comprehensive tests for a limited (qt, cairo, and wxwidgets PLplot
> > components were dropped) epa_build environment were run for 32-bit
> > MinGW/MSYS/Wine on AMD-64 hardware.
> > 
> > I need similar tests summaries from all of you that have run tests for
> > this release.  I give preliminary (and quite uncertain, see all the
> > question marks) versions below.  Please send back the corrected
> > versions of these test summaries.  In most cases the question marks
> > should be quite easy to replace with your actual test data.  However,
> > the phrase "Limited tests??" is a bit of a special case.  It should be
> > replaced by one of "Comprehensive tests" (if you actually ran the
> > scripts/comprehensive_test.sh script), a phrase summarizing the exact
> > test you ran such as "ctest + the test_noninteractive target in the
> > build tree" for intermediate testing, or "Limited tests" for those
> > cases where you actually only did a few tests by hand.
> > 
> > @Andrew:
> > 
> > Limited tests?? for a complete system build environment were run
> > on 64-bit?? Debian unstable on AMD-64 hardware??
> 
> I ran make test_noninteractive and test_interactive for a complete system 
> build environment on a 64-bit Debian unstable system on AMD-64 hardware. 
>  
> > Limited tests?? for a complete system build environment were run
> > on 64-bit Ubuntu version?? on AMD-64 hardware?
> 
> I ran make test_noninteractive and test_interactive for a complete system
> build environment on a 64-bit Ubuntu Saucy (13.10) system on AMD-64 
> hardware.
> 
> I did not get chance to run the tests on 32-bit Debian unstable with 
> AMD-64 hardware (though I can using the same pbuilder setup used to test 
> Debian 64 bit)

I've now also run the scripts/comprehensive_test.sh test on my Ubuntu 
system. I encountered some problems in that on several occasions, 
without warning, by kde session died. It was not reproducible, but in 
each case it was while running the test_interactive tests, mostly in 
the install tree. I've never seen this when running the test 
individually in serial so I don't know whether it is a parallel build 
problem or some hardware problem.

Eventually I managed to get through almost all the tests though. The 
only issue I encountered was a segfault with the C++ qt_example for the
nondyndriver case. Valgrind shows an invalid call to free / delete and
a memory access violation. The shared case is fine with valgrind so I 
assume it is something about the static drivers.

For the fully static case I do not get a segfault, but valgrind shows a 
load or invalid reads in wx libraries ?!?

Alan, do your tests reproduce this? I'll try a debug build to see if I 
can get to the bottom of it.

Andrew

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Test summaries for README.release need editing

[Andrew Ross]

On Thu, Dec 19, 2013 at 11:19:59AM -0800, Alan Irwin wrote:
> On 2013-12-19 13:44-0000 Andrew Ross wrote:
> 
> >On Thu, Dec 19, 2013 at 01:10:25PM +0000, Andrew Ross wrote:
> >>
> >>Tried to run build_plplot which fails straight away with
> >>
> >>  1%] Performing download step (verify and extract) for 'build_qt4_lite'
> >>cd /tmp/build_plplot/build_dir-linux/epa_build/Source && 
> >>/nfs/see-archive-15_a58/l
> >>ecanr/software/plplot/build_script/install-linux_buildtools/bin/cmake -P 
> >>/tmp/buil
> >>d_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/verify-build_qt4_lite.cmak
> >>e
> >>-- verifying file...
> >> 
> >> file='/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz'
> >>CMake Error at 
> >>/tmp/build_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/ve
> >>rify-build_qt4_lite.cmake:5 (file):
> >>  file MD5 failed to read file
> >>  "/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz": No
> >>  such file or directory
> >>
> >>Looks like this points to a file on Alan's hard disk rather than trying
> >>to download. You probably want to comment out the temporary debugging line
> >>before the release. I'll commit that change myself now. Having done that the
> >>build is now chugging away. More later...
> >>
> >
> >OK. So this fails for yelp-xsl because the source is compressed as a .xh
> >file and my version of tar doesn't support this option. Looks like this
> >will rule out the gnome stuff. I'm not sure how to fix / disable this so
> >this is likely to be the extent of my epa testing for now, unless I find
> >time to build a new version of tar.
> 
> I believe I have now fixed that issue with revision 12888.
> 
> And since you are currently failing on yelp-xsl, that implies that
> build_plplot_lite (which does not depend on yelp) finished without
> issues for you, and you went on to try build_plplot (which does
> depend on yelp indirectly via the pango dependencies).
> 
> Your results for epa_build on CentOS are extremely encouraging so far,
> and I am glad to hear they have already been a practical help for you
> on that platform.

I'll give this a go and let you know how I get on.

Andrew

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Test summaries for README.release need editing

[Andrew Ross]

More responses below.

On Thu, Dec 19, 2013 at 10:25:19AM -0800, Alan Irwin wrote:
> Hi Andrew:
> 
> Thanks for this very interesting test.  More below.
> 
> On 2013-12-19 13:10-0000 Andrew Ross wrote:
> 
> >
> > I plan to try the comprehensive test script for my Debian based 
> > configurations
> > later. In the meantime I've been trying to build plplot on a CentOS 5.10
> > machine at work. This is old software now and I expected problems. I also
> > have no root access so have to work with what's there.
> >
> > I build only cmake from scratch then tried to build plplot.
> >
> > Many drivers / bindings were disabled anyway since components were missing
> > from the system. Bugs I encountered were
> >
> > [ 18%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o
> > plplot.ads:24:05: "Ada.Numerics.Long_Real_Arrays" is not a predefined 
> > library unit
> > plplot.ads:24:05: "Plplot (body)" depends on "Plplot (spec)"
> > plplot.ads:24:05: "Plplot (spec)" depends on "Plplot_Thin (spec)"
> > plplot.ads:24:05: "Plplot_Thin (spec)" depends on "Plplot_Auxiliary (spec)"
> > plplot.ads:24:05: "Plplot_Auxiliary (spec)" depends on 
> > "Ada.Numerics.Long_Real_Arrays (spec)"
> > make[2]: *** [bindings/ada/CMakeFiles/plplotadad.dir/plplot.o] Error 1
> > make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2
> >
> > Old version of gnat (4.1.2) probably the cause. I disabled Ada and continued
> >
> > 25%] Building C object utils/CMakeFiles/pltek.dir/pltek.c.o
> > Linking C executable pltek
> > ../src/libplplotd.so.12.0.0: undefined reference to 
> > `cairo_ps_surface_set_eps'
> > ../src/libplplotd.so.12.0.0: undefined reference to 
> > `pango_layout_get_baseline'
> > collect2: ld returned 1 exit status
> > make[2]: *** [utils/pltek] Error 1
> > make[1]: *** [utils/CMakeFiles/pltek.dir/all] Error 2
> >
> > This was built without dynamic drivers (relevant lib missing) and so
> > cairo driver was compiled into plplot. This looks to me like a linking
> > issue in plplot, possible due to old version of linker since Alan hasn't
> > reported it for his test?
> 
> I am pretty sure the problem is the old version of cairo.  libplplotd needs
> cairo_ps_surface_set_eps, etc., but it looks like the old version of
> cairo on that system does not supply it.

That sounds plausible. It may be worth a version check somewhere, but given this
is a pretty old version of cairo, I suspect not.
 
> > Anyway, I disabled the cairo drivers and proceeded.
> >
> > [ 32%] Generating plplot/examples/x00.class
> > --
> > 1. ERROR in 
> > /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java
> > (at line 29)
> >import static plplot.core.plplotjavacConstants.*;
> >^
> > Syntax error, static imports are only available if source level is 5.0
> > --
> > 2. ERROR in 
> > /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java
> > (at line 56)
> >pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM );
> > ^
> > PL_PARSE_FULL cannot be resolved
> > --
> > 3. ERROR in 
> > /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java
> > (at line 56)
> >pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM );
> > ^^
> > PL_PARSE_NOPROGRAM cannot be resolved
> > --
> > 3 problems (3 errors)make[3]: *** [examples/java/plplot/examples/x00.class] 
> > Error 255
> > make[2]: *** [examples/java/CMakeFiles/plplot_examples.dir/all] Error 2
> > make[1]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
> >
> > This looks like a problem with an old version of javac. I might be able
> > to fix this by setting the source level, but I just disabled java and
> > continued.
> >
> > After all this I ended up with just C / C++ / F95 bindings and with a
> > minimal set of drivers (mem, null, psc, svg, xfig, xwin). It did however
> > pass make test_interactive and make test_noninteractive.
> 
> That's an extremely useful test result for enterprise Linux.  Can you
> write it up in the same style as the rest of the test results in
> README.release?

Will do.
 
> > On the plus side I spotted a bug with

Re: [Plplot-devel] Test summaries for README.release need editing

[Andrew Ross]

On Thu, Dec 19, 2013 at 01:10:25PM +, Andrew Ross wrote:
> 
> Tried to run build_plplot which fails straight away with
> 
>   1%] Performing download step (verify and extract) for 'build_qt4_lite'
> cd /tmp/build_plplot/build_dir-linux/epa_build/Source && 
> /nfs/see-archive-15_a58/l
> ecanr/software/plplot/build_script/install-linux_buildtools/bin/cmake -P 
> /tmp/buil
> d_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/verify-build_qt4_lite.cmak
> e
> -- verifying file...
>  file='/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz'
> CMake Error at 
> /tmp/build_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/ve
> rify-build_qt4_lite.cmake:5 (file):
>   file MD5 failed to read file
>   "/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz": No
>   such file or directory
> 
> Looks like this points to a file on Alan's hard disk rather than trying 
> to download. You probably want to comment out the temporary debugging line
> before the release. I'll commit that change myself now. Having done that the 
> build is now chugging away. More later...
> 

OK. So this fails for yelp-xsl because the source is compressed as a .xh 
file and my version of tar doesn't support this option. Looks like this 
will rule out the gnome stuff. I'm not sure how to fix / disable this so 
this is likely to be the extent of my epa testing for now, unless I find 
time to build a new version of tar.

Andrew

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Test summaries for README.release need editing

[Andrew Ross]

I plan to try the comprehensive test script for my Debian based configurations 
later. In the meantime I've been trying to build plplot on a CentOS 5.10 
machine at work. This is old software now and I expected problems. I also
have no root access so have to work with what's there.

I build only cmake from scratch then tried to build plplot.

Many drivers / bindings were disabled anyway since components were missing 
from the system. Bugs I encountered were

[ 18%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o
plplot.ads:24:05: "Ada.Numerics.Long_Real_Arrays" is not a predefined library 
unit
plplot.ads:24:05: "Plplot (body)" depends on "Plplot (spec)"
plplot.ads:24:05: "Plplot (spec)" depends on "Plplot_Thin (spec)"
plplot.ads:24:05: "Plplot_Thin (spec)" depends on "Plplot_Auxiliary (spec)"
plplot.ads:24:05: "Plplot_Auxiliary (spec)" depends on 
"Ada.Numerics.Long_Real_Arrays (spec)"
make[2]: *** [bindings/ada/CMakeFiles/plplotadad.dir/plplot.o] Error 1
make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2

Old version of gnat (4.1.2) probably the cause. I disabled Ada and continued

 25%] Building C object utils/CMakeFiles/pltek.dir/pltek.c.o
Linking C executable pltek
../src/libplplotd.so.12.0.0: undefined reference to `cairo_ps_surface_set_eps'
../src/libplplotd.so.12.0.0: undefined reference to `pango_layout_get_baseline'
collect2: ld returned 1 exit status
make[2]: *** [utils/pltek] Error 1
make[1]: *** [utils/CMakeFiles/pltek.dir/all] Error 2

This was built without dynamic drivers (relevant lib missing) and so 
cairo driver was compiled into plplot. This looks to me like a linking
issue in plplot, possible due to old version of linker since Alan hasn't
reported it for his test? 

Anyway, I disabled the cairo drivers and proceeded.

[ 32%] Generating plplot/examples/x00.class
--
1. ERROR in 
/nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java
 (at line 29)
import static plplot.core.plplotjavacConstants.*;
^
Syntax error, static imports are only available if source level is 5.0
--
2. ERROR in 
/nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java
 (at line 56)
pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM );
 ^
PL_PARSE_FULL cannot be resolved
--
3. ERROR in 
/nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java
 (at line 56)
pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM );
 ^^
PL_PARSE_NOPROGRAM cannot be resolved
--
3 problems (3 errors)make[3]: *** [examples/java/plplot/examples/x00.class] 
Error 255
make[2]: *** [examples/java/CMakeFiles/plplot_examples.dir/all] Error 2
make[1]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2

This looks like a problem with an old version of javac. I might be able 
to fix this by setting the source level, but I just disabled java and 
continued.

After all this I ended up with just C / C++ / F95 bindings and with a 
minimal set of drivers (mem, null, psc, svg, xfig, xwin). It did however
pass make test_interactive and make test_noninteractive.

On the plus side I spotted a bug with plcolorbar in the C++ bindings. 
Not sure why this hadn't been triggered with newer versions of gcc.

I have also tried epa_build_lite. I got as far as building libharu and 
the build failed with 

Building C object src/CMakeFiles/hpdf_static.dir/hpdf_string.o
cd /tmp/build_plplot/build_dir-linux/epa_build/Build/build_libharu/src && 
/usr/bin
/cc   -O3 -fvisibility=hidden -Wuninitialized  
-I/tmp/build_plplot/build_dir-linux
/epa_build/Source/build_libharu/include 
-I/tmp/build_plplot/build_dir-linux/epa_bu
ild/Build/build_libharu/include-o CMakeFiles/hpdf_static.dir/hpdf_string.o  
 -
c 
/tmp/build_plplot/build_dir-linux/epa_build/Source/build_libharu/src/hpdf_string
.c
/usr/local/lib/libz.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
gmake[6]: *** [src/libhpdf.so.0.0.0] Error 1 

Note this is a static build, but trying to link in the shared version of 
libz. I think this is because there is no libz.a installed, however 
cmake didn't spot this corner case. Manually massaging the linker 
options allowed me to continue, however for some reason the header file
hpdf_pdfa.h is not installed (this is only required in the static case)
and so any code using hpdf.h will fail. Copying the header into the 
install tree got me a bit further.

I then had to muck about to disable ada and java to get the build to complete 
and to install (p.s. Alan: How do I pass cmake options to the plplot build when
using epa? I went in and reran cmake by hand - not ideal).

I then tried the cmake based tests in the install tree. 

make test_noninteractive failed becaua

Re: [Plplot-devel] [Post-release] Memory management issues with -dev tk

[Andrew Ross]

On Wed, Dec 18, 2013 at 03:27:28PM -0800, Alan Irwin wrote:
> Hi Andrew:
> 
> In reply to your previous post, thanks for confirming those segfault
> issues when the recommended stubs versions of the Tcl/Tk libraries are
> used.  It will be most interesting if those issues disappear if Arjen
> replaces (post-release) our use of the non-recommended versions of the
>  Tcl/Tk API with the recommended versions.

Certainly, although I think we've already weeded out a lot of the really 
old style tcl (e.g. accessing the internals of the interp structure). 
This crash happens early on in the driver initialisation and I don't 
think we've had time to do too much wrong at that point.
 
> More below.
> 
> On 2013-12-18 22:01- Andrew Ross wrote:
> 
> >
> > P.S. Fixing the fifo bug had no impact on the segfault with
> > USE_TCL_TK_STUBS=ON.
> >
> > One other issue I encountered was that detecting of the various tcl
> > components is not entirely robust. I had tcl8.5 and tcl8.6 installed.
> > On Ubuntu the default is tcl8.5 so tclsh points to tclsh8.5. This
> > means that most of the tcl-related variables were set to point to 8.5,
> > however the code setting TCL_INCLUDE_PATH ended up pointing to tcl8.6.
> > This is probably a cmake issue rather than a plplot issue, but I
> > thought I'd flag it up.
> 
> Did our build system warn about those version inconsistencies?  And if
> so, could you straighten out CMake finding Tcl/Tk library versions
> that were inconsistent with tclsh by using CMAKE_INCLUDE_PATH and
> CMAKE_LIBRARY_PATH?

No - the build system didn't warn of the inconsistencies. Well at least 
cmake didn't. I spotted it by eye and to fix it I actually used 
update-alternatives to make tclsh point to tclsh8.6 since that seemed
easiest. I didn't actually try running make. One could get the version 
using tclsh and then only look for include files for that version, but 
cmake doesn't do that. I've run into similar issues with python in the 
past. 
 
> If the answers to both questions are "yes", then I think that is
> probably the best we can do unless we completely replace the
> CMake Tcl/Tk find module with our own.

I agree that is the only proper solution, and not one I'm particularly 
keen to adopt. This might serve as a warning to others though with 
multiple tcl versions installed.
 
Andrew

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [Post-release] Memory management issues with -dev tk

[Andrew Ross]

P.S. Fixing the fifo bug had no impact on the segfault with 
USE_TCL_TK_STUBS=ON.

One other issue I encountered was that detecting of the various tcl 
components is not entirely robust. I had tcl8.5 and tcl8.6 installed.
On Ubuntu the default is tcl8.5 so tclsh points to tclsh8.5. This 
means that most of the tcl-related variables were set to point to 8.5,
however the code setting TCL_INCLUDE_PATH ended up pointing to tcl8.6. 
This is probably a cmake issue rather than a plplot issue, but I
thought I'd flag it up.

Andrew 

On Wed, Dec 18, 2013 at 09:54:48PM +0000, Andrew Ross wrote:
> Alan,
> 
> Out of interest I tried installing tcl / tk 8.6 from Ubuntu and 
> building with that using -DUSE_TCL_TK_STUBS=ON. I can confirm the bug 
> exists in that case too. No need to use epa_build. I've not (yet) 
> gone back to check on 8.5
> 
> I tried running the example through valgrind and with gdb, but there 
> is nothing very helpful beyond what you've already identified. It is
> definitely a stubs related issue. Without -DUSE_TCL_TK_STUBS=ON I see no 
> segfault.
> 
> I also tried adding -fstack-protector-all to CFLAGS, but nothing 
> showed up.
> 
> This is something of a mystery, and I must admit I don't know enough 
> about tcl / tk to speculate on that.
> 
> Incidentally you are right about the first two entries in the valgrind 
> log. This is a result of my recent changes to clean up the fifo creation
> code. I've fixed this particular bug anyway.
> 
> Andrew
> 
> 
> On Thu, Dec 12, 2013 at 10:13:26PM -0800, Alan Irwin wrote:
> > I have tagged the subject line with [Post-release] because I think it
> > is too late for for any but the most obvious and simple changes in
> > this release cycle, but I hope some of the memory management issues
> > that I am discovering right now for the tk device driver will be
> > addressed right away in the next release cycle.
> > 
> > I have discovered through the comprehensive tests of epa_build results
> > that I just implemented that examples/c/x01c -dev tk (and presumably
> > the rest of the C examples) segfault under a certain combination of
> > circumstances.
> > 
> > (1) Must be using the version of Tcl/Tk(8.6) built by epa_build.
> > 
> > (2) Must have -DUSE_TCL_TK_STUBS=ON
> > 
> > I know I did tests for this exact combination of circumstances in the
> > very recent past (via the test_interactive target which definitely
> > runs examples/c/x01c -dev tk and a lot of other tests) without a
> > segfault.  However, that is the nature of memory management issues;
> > some times you get segfaults and sometimes you don't.
> > 
> > When I ran valgrind on examples/c/x01c -dev tk for the above
> > combination of circumstances it showed an invalid read followed by a
> > segfault occurred at line 712 of bindings/tcl/tclAPI.c;
> > 
> > Tcl_SetVar( interp, "dir", TCL_DIR, TCL_GLOBAL_ONLY );
> > 
> > The TCL_DIR macro has not been clobbered according to the debug
> > 
> > fprintf( stderr, "adding %s to auto_path\n", TCL_DIR );
> > 
> > that occurs (now) just before that statement, and everything else
> > about this statement is pretty simple and benign so I don't understand
> > at all what is causing this segfault.  But it is a virtual certainty
> > it is caused by something being overwritten either in the heap or
> > stack.
> > 
> > Since -DUSE_TCL_TK_STUBS=ON is a new innovation that is not as well
> > tested as our traditional Tcl, etc., results which did not
> > use the stubs Tcl/Tk libraries, I have decided to work around
> > this issue for the default case by adopting -DUSE_TCL_TK_STUBS=OFF for
> > that case.
> > 
> > I then looked carefully at the -DUSE_TCL_TK_STUBS=OFF case with a
> > valgrind run on examples/c/x01c -dev tk.  For this non-stubs case
> > there were no obvious issues like invalid reads, but there were a fair
> > number of fouled up memory allocations by the time the example was
> > done as you can see from the attached valgrind report. Some of those
> > (such as at least the first two) are definitely due to PLplot code and
> > should be addressed by us post release just in case one of those is
> > the culprit that indirectly causes the invalid read and segfault
> > issues for the stubs case.
> > 
> > Of course, the issue might also be that PLplot can reliably use the
> > Tcl/Tk stubs libraries for Tcl/Tk version 8.5, but not 8.6 because of
> > our extensive use of of Tcl/Tk library API which has been deprecated
> > for many releases of Tcl/Tk and which therefore might not be reliably
&