plplot-devel

Re: [Plplot-devel] PLPlot 6 and C++

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

>
> On 2015-05-22 13:00+0100 Phil Rosenberg wrote:
>
>> Hi All
>> I mentioned this briefly during the previous release cycle, but we all
>> had more pressing things to deal with. Dealing with errors is
>> something we really  need to get a hold on for PLPlot 6 and one of the
>> big drivers for considering a major API change. However, I am certain
>> that the reason why this has been a problem s that propagating those
>> errors back up through many layers of function calls is tedious and
>> error prone so it has been much simpler to simply call exit().
>>
>> Here is one possible solution. We switch the core code to C++ with a C frontend.
>>
>
> However, let's be clear here the cost of that benefit is
> likely to be considerably higher than you are estimating now.
> For example, there is going to be substantial costs in terms of
> doxygen and DocBook documentation, and also the domestic bindings and
> foreign bindings (e.g., the PDL and Lisp bindings for PLplot) are of
> some concern.  Of course, in theory you could write a perfect C wrapper
> library for the C++ core so bindings on that C wrapper work just as
> well as they do for PLplot 5.  But that C wrapper would really
> have to be perfect and would make the bindings less efficient.  Note,
> I don't want to emphasize that last point too much since reliability
> is much more important to me than speed.  But at some point, I assume
> you will want to address that issue (e.g., for the swig-generated
> bindings) by ignoring the C wrapper and binding directly to the C++
> core instead which adds to the cost of this change.

I agree with Alan that it is not immediately obvious that this approach 
will save a lot of effort. All the API functions are going to have to be 
modified anyway, even if only to return some sort of no error code. This 
in turn will mean updating all the examples and a lot of the 
documentation. So the additional saving might be something like 10% on 
top of this? A C++ solution would also involve adding "extern" to every 
part of the API that we want to expose.

It could be argued that the exercise of dealing with the propagation 
issues might help to clean up issues that were otherwise just papered 
over. I think we'd have to do this anyway in order to take advantage of 
your proposal to use the out of scope array deletion feature of C++, as 
every array in PLplot is now going to have to be a C++ object. This is 
also going to be a lot of work, though we'd face similar cleanup issues 
in C. By my count there are currently 146 calls to plexit() in PLplot 
core, most of which are related to memory allocation.

So I lean slightly towards staying with C, but if others think that C++ 
is the way to go, then that is ok with me and I'll try to help with 
things like updating the examples, documentation, etc.

Some questions:
1. C++ compilers are universal? Are there any major platforms that we 
want to support that do not have readily available C++ support?

2. In my readings on this subject some have mentioned that a C++ 
compiler can be substantially slower? Is this true? Significant?

-Hazen

Re: [Plplot-devel] PLPlot 6 and C++

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

Hi everyone,



An issue related to the use of C++ that has not been raised yet, but which surfaced recently in my comprehensive testing efforts is the fact that linking a C++ program requires a C++-enabled linker. Thus introducing C++ as the language in which PLplot is to be implemented would complicate the use of static builds. That may not be the most common option nowadays, but I think we need to take a conscious decision: do we want to continue to support static builds or not? One pro for static builds is that they make deployment, especially of binary-only distributions much easier (and safer).



Regards,



Arjen



> -----Original Message-----
> From: Hazen Babcock [mailto:hba...@ma...]
> Sent: Monday, May 25, 2015 7:18 PM
> To: plp...@li...
> Subject: Re: [Plplot-devel] PLPlot 6 and C++
>
> >
> > On 2015-05-22 13:00+0100 Phil Rosenberg wrote:
> >
> >> Hi All
> >> I mentioned this briefly during the previous release cycle, but we
> >> all had more pressing things to deal with. Dealing with errors is
> >> something we really  need to get a hold on for PLPlot 6 and one of
> >> the big drivers for considering a major API change. However, I am
> >> certain that the reason why this has been a problem s that
> >> propagating those errors back up through many layers of function
> >> calls is tedious and error prone so it has been much simpler to simply call exit().
> >>
> >> Here is one possible solution. We switch the core code to C++ with a C frontend.
> >>
> >
> > However, let's be clear here the cost of that benefit is likely to be
> > considerably higher than you are estimating now.
> > For example, there is going to be substantial costs in terms of
> > doxygen and DocBook documentation, and also the domestic bindings and
> > foreign bindings (e.g., the PDL and Lisp bindings for PLplot) are of
> > some concern.  Of course, in theory you could write a perfect C
> > wrapper library for the C++ core so bindings on that C wrapper work
> > just as well as they do for PLplot 5.  But that C wrapper would really
> > have to be perfect and would make the bindings less efficient.  Note,
> > I don't want to emphasize that last point too much since reliability
> > is much more important to me than speed.  But at some point, I assume
> > you will want to address that issue (e.g., for the swig-generated
> > bindings) by ignoring the C wrapper and binding directly to the C++
> > core instead which adds to the cost of this change.
>
> I agree with Alan that it is not immediately obvious that this approach will save a lot
> of effort. All the API functions are going to have to be modified anyway, even if only
> to return some sort of no error code. This in turn will mean updating all the examples
> and a lot of the documentation. So the additional saving might be something like 10%
> on top of this? A C++ solution would also involve adding "extern" to every part of the
> API that we want to expose.
>
> It could be argued that the exercise of dealing with the propagation issues might help
> to clean up issues that were otherwise just papered over. I think we'd have to do this
> anyway in order to take advantage of your proposal to use the out of scope array
> deletion feature of C++, as every array in PLplot is now going to have to be a C++
> object. This is also going to be a lot of work, though we'd face similar cleanup issues
> in C. By my count there are currently 146 calls to plexit() in PLplot core, most of
> which are related to memory allocation.
>
> So I lean slightly towards staying with C, but if others think that C++ is the way to go,
> then that is ok with me and I'll try to help with things like updating the examples,
> documentation, etc.
>
> Some questions:
> 1. C++ compilers are universal? Are there any major platforms that we want to
> support that do not have readily available C++ support?
>
> 2. In my readings on this subject some have mentioned that a C++ compiler can be
> substantially slower? Is this true? Significant?
>
> -Hazen
>
>
> ------------------------------------------------------------------------------
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] PLPlot 6 and C++

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

> On May 25, 2015, at 1:29 PM, Arjen Markus <Arj...@de...> wrote:
> 
> Hi everyone,
>  
> An issue related to the use of C++ that has not been raised yet, but which surfaced recently in my comprehensive testing efforts is the fact that linking a C++ program requires a C++-enabled linker. Thus introducing C++ as the language in which PLplot is to be implemented would complicate the use of static builds. That may not be the most common option nowadays, but I think we need to take a conscious decision: do we want to continue to support static builds or not? One pro for static builds is that they make deployment, especially of binary-only distributions much easier (and safer).
>  
> Regards,
>  
> Arjen
> 
> 

I don’t have a strong opinion either way on the C++ vs C and I think we can achieve design objectives with either language.  I do think we run the risk of breaking compatibility with some percentage of the current uses of PLplot.

My biggest concern, however, is that switching to C++ will consume a big chunk of time.  If we are going to make that investment, then a good scrub of the API should be done to make sure we do not handicap ourselves.

My top recommendation is that we appoint a manager of the legacy PLplot to support the users during the transition.  My gut feeling PLplot 5 will be around for quite awhile.
> > -----Original Message-----
> > From: Hazen Babcock [mailto:hba...@ma... <mailto:hba...@ma...>]
> > Sent: Monday, May 25, 2015 7:18 PM
> > To: plp...@li... <mailto:plp...@li...>
> > Subject: Re: [Plplot-devel] PLPlot 6 and C++
> >
> > >
> > > On 2015-05-22 13:00+0100 Phil Rosenberg wrote:
> > >
> > >> Hi All
> > >> I mentioned this briefly during the previous release cycle, but we
> > >> all had more pressing things to deal with. Dealing with errors is
> > >> something we really  need to get a hold on for PLPlot 6 and one of
> > >> the big drivers for considering a major API change. However, I am
> > >> certain that the reason why this has been a problem s that
> > >> propagating those errors back up through many layers of function
> > >> calls is tedious and error prone so it has been much simpler to simply call exit().
> > >>
> > >> Here is one possible solution. We switch the core code to C++ with a C frontend.
> > >>
> > >
> > > However, let's be clear here the cost of that benefit is likely to be
> > > considerably higher than you are estimating now.
> > > For example, there is going to be substantial costs in terms of
> > > doxygen and DocBook documentation, and also the domestic bindings and
> > > foreign bindings (e.g., the PDL and Lisp bindings for PLplot) are of
> > > some concern.  Of course, in theory you could write a perfect C
> > > wrapper library for the C++ core so bindings on that C wrapper work
> > > just as well as they do for PLplot 5.  But that C wrapper would really
> > > have to be perfect and would make the bindings less efficient.  Note,
> > > I don't want to emphasize that last point too much since reliability
> > > is much more important to me than speed.  But at some point, I assume
> > > you will want to address that issue (e.g., for the swig-generated
> > > bindings) by ignoring the C wrapper and binding directly to the C++
> > > core instead which adds to the cost of this change.
> >
> > I agree with Alan that it is not immediately obvious that this approach will save a lot
> > of effort. All the API functions are going to have to be modified anyway, even if only
> > to return some sort of no error code. This in turn will mean updating all the examples
> > and a lot of the documentation. So the additional saving might be something like 10%
> > on top of this? A C++ solution would also involve adding "extern" to every part of the
> > API that we want to expose.
> >
> > It could be argued that the exercise of dealing with the propagation issues might help
> > to clean up issues that were otherwise just papered over. I think we'd have to do this
> > anyway in order to take advantage of your proposal to use the out of scope array
> > deletion feature of C++, as every array in PLplot is now going to have to be a C++
> > object. This is also going to be a lot of work, though we'd face similar cleanup issues
> > in C. By my count there are currently 146 calls to plexit() in PLplot core, most of
> > which are related to memory allocation.
> >
> > So I lean slightly towards staying with C, but if others think that C++ is the way to go,
> > then that is ok with me and I'll try to help with things like updating the examples,
> > documentation, etc.
> >
> > Some questions:
> > 1. C++ compilers are universal? Are there any major platforms that we want to
> > support that do not have readily available C++ support?
> >
> > 2. In my readings on this subject some have mentioned that a C++ compiler can be
> > substantially slower? Is this true? Significant?
> >
> > -Hazen
> >
> >
> > ------------------------------------------------------------------------------
> > 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 <http://ad.doubleclick.net/ddm/clk/290420510;117567292;y>
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel <https://lists.sourceforge.net/lists/listinfo/plplot-devel>DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. ------------------------------------------------------------------------------
> 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_______________________________________________ <http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________>
> Plplot-devel mailing list
> Plp...@li... <mailto:Plp...@li...>
> https://lists.sourceforge.net/lists/listinfo/plplot-devel <https://lists.sourceforge.net/lists/listinfo/plplot-devel>

Re: [Plplot-devel] PLPlot 6 and C++

[Chris M. <dev...@gm...>]

The biggest problem I've had with C++ is the compiler/linker lock-in.  
Since there is no standard for name mangling... you are basically 
required to use the same compiler to link with as was compiled with.  In 
principle, this can be avoided by exposing an extern C API---only.  That 
seems to take more discipline than I have seen.  The place where this is 
a pain is for MS Visual C++ version mingw on windows systems.

--Chris

On 5/25/2015 15:11, Jim Dishaw wrote:
>
>> On May 25, 2015, at 1:29 PM, Arjen Markus <Arj...@de... 
>> <mailto:Arj...@de...>> wrote:
>>
>> Hi everyone,
>> An issue related to the use of C++ that has not been raised yet, but 
>> which surfaced recently in my comprehensive testing efforts is the 
>> fact that linking a C++ program requires a C++-enabled linker. Thus 
>> introducing C++ as the language in which PLplot is to be implemented 
>> would complicate the use of static builds. That may not be the most 
>> common option nowadays, but I think we need to take a conscious 
>> decision: do we want to continue to support static builds or not? One 
>> pro for static builds is that they make deployment, especially of 
>> binary-only distributions much easier (and safer).
>> Regards,
>> Arjen
>>
>>
>
> I don’t have a strong opinion either way on the C++ vs C and I think 
> we can achieve design objectives with either language.  I do think we 
> run the risk of breaking compatibility with some percentage of the 
> current uses of PLplot.
>
> My biggest concern, however, is that switching to C++ will consume a 
> big chunk of time.  If we are going to make that investment, then a 
> good scrub of the API should be done to make sure we do not handicap 
> ourselves.
>
> My top recommendation is that we appoint a manager of the legacy 
> PLplot to support the users during the transition.  My gut feeling 
> PLplot 5 will be around for quite awhile.
>>
>> > -----Original Message-----
>> > From: Hazen Babcock [mailto:hba...@ma...]
>> > Sent: Monday, May 25, 2015 7:18 PM
>> > To:plp...@li... 
>> <mailto:plp...@li...>
>> > Subject: Re: [Plplot-devel] PLPlot 6 and C++
>> >
>> > >
>> > > On 2015-05-22 13:00+0100 Phil Rosenberg wrote:
>> > >
>> > >> Hi All
>> > >> I mentioned this briefly during the previous release cycle, but we
>> > >> all had more pressing things to deal with. Dealing with errors is
>> > >> something we really  need to get a hold on for PLPlot 6 and one of
>> > >> the big drivers for considering a major API change. However, I am
>> > >> certain that the reason why this has been a problem s that
>> > >> propagating those errors back up through many layers of function
>> > >> calls is tedious and error prone so it has been much simpler to 
>> simply call exit().
>> > >>
>> > >> Here is one possible solution. We switch the core code to C++ 
>> with a C frontend.
>> > >>
>> > >
>> > > However, let's be clear here the cost of that benefit is likely to be
>> > > considerably higher than you are estimating now.
>> > > For example, there is going to be substantial costs in terms of
>> > > doxygen and DocBook documentation, and also the domestic bindings and
>> > > foreign bindings (e.g., the PDL and Lisp bindings for PLplot) are of
>> > > some concern.  Of course, in theory you could write a perfect C
>> > > wrapper library for the C++ core so bindings on that C wrapper work
>> > > just as well as they do for PLplot 5.  But that C wrapper would 
>> really
>> > > have to be perfect and would make the bindings less efficient.  Note,
>> > > I don't want to emphasize that last point too much since reliability
>> > > is much more important to me than speed. But at some point, I assume
>> > > you will want to address that issue (e.g., for the swig-generated
>> > > bindings) by ignoring the C wrapper and binding directly to the C++
>> > > core instead which adds to the cost of this change.
>> >
>> > I agree with Alan that it is not immediately obvious that this 
>> approach will save a lot
>> > of effort. All the API functions are going to have to be modified 
>> anyway, even if only
>> > to return some sort of no error code. This in turn will mean 
>> updating all the examples
>> > and a lot of the documentation. So the additional saving might be 
>> something like 10%
>> > on top of this? A C++ solution would also involve adding "extern" 
>> to every part of the
>> > API that we want to expose.
>> >
>> > It could be argued that the exercise of dealing with the 
>> propagation issues might help
>> > to clean up issues that were otherwise just papered over. I think 
>> we'd have to do this
>> > anyway in order to take advantage of your proposal to use the out 
>> of scope array
>> > deletion feature of C++, as every array in PLplot is now going to 
>> have to be a C++
>> > object. This is also going to be a lot of work, though we'd face 
>> similar cleanup issues
>> > in C. By my count there are currently 146 calls to plexit() in 
>> PLplot core, most of
>> > which are related to memory allocation.
>> >
>> > So I lean slightly towards staying with C, but if others think that 
>> C++ is the way to go,
>> > then that is ok with me and I'll try to help with things like 
>> updating the examples,
>> > documentation, etc.
>> >
>> > Some questions:
>> > 1. C++ compilers are universal? Are there any major platforms that 
>> we want to
>> > support that do not have readily available C++ support?
>> >
>> > 2. In my readings on this subject some have mentioned that a C++ 
>> compiler can be
>> > substantially slower? Is this true? Significant?
>> >
>> > -Hazen
>> >
>> >
>> > 
>> ------------------------------------------------------------------------------
>> > 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
>> > Plp...@li... 
>> <mailto:Plp...@li...>
>> >https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>> DISCLAIMER: This message is intended exclusively for the addressee(s) 
>> and may contain confidential and privileged information. If you are 
>> not the intended recipient please notify the sender immediately and 
>> destroy this message. Unauthorized use, disclosure or copying of this 
>> message is strictly prohibited. The foundation 'Stichting Deltares', 
>> which has its seat at Delft, The Netherlands, Commercial Registration 
>> Number 41146461, is not liable in any way whatsoever for consequences 
>> and/or damages resulting from the improper, incomplete and untimely 
>> dispatch, receipt and/or content of this e-mail. 
>> ------------------------------------------------------------------------------
>> 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
>> Plp...@li... 
>> <mailto:Plp...@li...>
>> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLPlot 6 and C++

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

On 2015-05-25 17:29-0000 Arjen Markus wrote:

> An issue related to the use of C++ that has not been raised yet, but
which surfaced recently in my comprehensive testing efforts is the
fact that linking a C++ program requires a C++-enabled linker. Thus
introducing C++ as the language in which PLplot is to be implemented
would complicate the use of static builds. That may not be the most
common option nowadays, but I think we need to take a conscious
decision: do we want to continue to support static builds or not? One
pro for static builds is that they make deployment, especially of
binary-only distributions much easier (and safer).

Hi Arjen:

Yes, I think we should keep supporting static builds which work
virtually perfectly now with our CMake-based build systems for the
build of PLplot from source and the build of the installed examples.

I assume what you mean by a C++-enabled linker is that extra libraries
have to be linked in for that case.  Our CMake build handles this
situation with ease both for the core build and installed examples
build.  So static linking is already completely supported in that case.

Of course, there is currently a limitation on our traditional
(Makefile + pkg-config) build for e.g., Fortran examples where
pkg-config does not automatically know the name/location of the
special C++ library that needs to be linked in for a given C++
compiler so the user would have to add that link himself to the
pkg-config results to successfully build the Fortran examples using
our traditional build system for the installed examples.

Currently this problem occurs if C++ code is included in libplplot
from our C++ device drivers, psttf, qt, and wxwidgets. But that is a
very common case (or should be) to have those device drivers enabled
so if we adopt C++ for the core library this limitation in our
traditional build will essentially just stay the same in most cases.
So I don't see this limitation of our traditional build system for the
installed examples as a big concern with switching our core library to
C++ in all cases.

Don't get me wrong, I would like this limitation to be resolved so
that our traditional build of the installed examples works as well as
the CMake build of those.  When discussing this with Andrew I
mentioned one possibility for implementing a fix for this issue, but
that is a lot of work which I am going to leave to others if they want
to make our Makefile+pkg-config approach as high quality as the
CMake-based one for building our installed examples.

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLPlot 6 and C++

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

Okay, well it was an option I thought I would put out there as I think
it was worth considering. I will try to answer the questions people
had anyway in case people are interested.

Regarding domestic bindings, the C front end would remain. Although
the API would have to change if we wanted to return an error code. but
this is about plplot internal code. What is the maximum number of
levels back which we might need to pass an error code? A dozen or more
probably. The idea is to avoid all that internal book keeping.
Especially if 10 layers down a memory allocation fails. Every layer up
from this needs to have code to deal with checking error codes for
every function it calls and then free resources and propagate that
error code. With the C++ model a throw does all that automatically.

Regarding efficiency. There would almost certainly be no change. The
compiler would probably optimise away anything superfluous.

As far as I know C++ is ubiquitous. The earliest C++ compilers
actually rewrote the C++ to C and passed it to a C compiler!

Compilation speed for C++ can be slower if there is a lot of use of
Templates. Templates are functions or classes which can have a version
for any variable type, so instead of writing
int round( int var, int basis);
float round( float var, float basis);
double round( double var, doublebasis);
...

you have
template<class T>
T round( T var, T basis);

Then the user can call round with any type and it will work, providing
the code is compilable when you replace T with your type or class. But
there is a compiletime cost associated with the extra work required by
the compiler to do this.

Regarding name mangling we can use extern C to give C name mangling to
the API, then the library, both static and dynamic as I understand it,
behaves just like a C library.

As far as using a C++ compiler is concerned I am afraid that is
something I have never worried about as I only write C++ programs so I
always link against C runtimes. But as Alan says we already use C++
code in PLPlot so this should already be taken care of.

If we are not interested in moving to C++ then we still need a method
to propagate errors up through the multiple layers of code in the
PLPlot library and do so in a way which minimises the risk of memory
or other resource leaks. Because I work in C++ I'm not necessarily the
best person to know best practice for this. But here are some ideas. I
would be very interested to hear comments and more suggestions.

1) We make every internal function in PLPlot return an error code and
check these codes religiously at every call. Even simple functions
would probably have to do this because in the future simple functions
may grow to more complex ones and changing a function that previously
returned a meaningful value to one which returns an error code is
likely to be error prone so best get them all out of the way.

2) We include an error code in the PLStream struct. We then check this
after every function call to check if it has changed. Again this just
requires us to be religious about checking the current error code.

3)I just found out about setjmp and longjmp. These are C macros. As
far as I can tell setjmp saves the state of the program stack and
creates a jump point. Calling longjump jumps back to the jump point
and restores the state. However, any memory malloc'd in the meantime
will leak, unless we have some way to free it later. This might be
conceivable by having an array of pointers in the PLStream to all
memory allocated (maybe create a function plmalloc and plfree to deal
with this?) which we can deal with at the end. Does anyone have any
experience with setjmp and longjmp or  any advice? I also don't know
how it deals with re-entrancy or nesting of setjmp calls. Or how to
deal with our C++ code calling our C code - does our C++ code only
call the public API or does it have access to internal routines?

4) Any other suggestions?

All these methods require us to have some strategy for dealing with
freeing memory although it is often trivial, in some cases this can be
complex and a strong candidate for future bugs and memory leaks.

I'm really keen to hear people's thoughts on this. As I said I work in
C++, so I don't know best practice in C for dealing with this, but we
definitely need to make a call and have a definite strategy for this
otherwise it will be a nightmare.

Phil


On 25 May 2015 at 21:06, Alan W. Irwin <ir...@be...> wrote:
> On 2015-05-25 17:29-0000 Arjen Markus wrote:
>
>> An issue related to the use of C++ that has not been raised yet, but
> which surfaced recently in my comprehensive testing efforts is the
> fact that linking a C++ program requires a C++-enabled linker. Thus
> introducing C++ as the language in which PLplot is to be implemented
> would complicate the use of static builds. That may not be the most
> common option nowadays, but I think we need to take a conscious
> decision: do we want to continue to support static builds or not? One
> pro for static builds is that they make deployment, especially of
> binary-only distributions much easier (and safer).
>
> Hi Arjen:
>
> Yes, I think we should keep supporting static builds which work
> virtually perfectly now with our CMake-based build systems for the
> build of PLplot from source and the build of the installed examples.
>
> I assume what you mean by a C++-enabled linker is that extra libraries
> have to be linked in for that case.  Our CMake build handles this
> situation with ease both for the core build and installed examples
> build.  So static linking is already completely supported in that case.
>
> Of course, there is currently a limitation on our traditional
> (Makefile + pkg-config) build for e.g., Fortran examples where
> pkg-config does not automatically know the name/location of the
> special C++ library that needs to be linked in for a given C++
> compiler so the user would have to add that link himself to the
> pkg-config results to successfully build the Fortran examples using
> our traditional build system for the installed examples.
>
> Currently this problem occurs if C++ code is included in libplplot
> from our C++ device drivers, psttf, qt, and wxwidgets. But that is a
> very common case (or should be) to have those device drivers enabled
> so if we adopt C++ for the core library this limitation in our
> traditional build will essentially just stay the same in most cases.
> So I don't see this limitation of our traditional build system for the
> installed examples as a big concern with switching our core library to
> C++ in all cases.
>
> Don't get me wrong, I would like this limitation to be resolved so
> that our traditional build of the installed examples works as well as
> the CMake build of those.  When discussing this with Andrew I
> mentioned one possibility for implementing a fix for this issue, but
> that is a lot of work which I am going to leave to others if they want
> to make our Makefile+pkg-config approach as high quality as the
> CMake-based one for building our installed examples.
>
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLPlot 6 and C++

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

> On May 26, 2015, at 3:53 PM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Okay, well it was an option I thought I would put out there as I think
> it was worth considering. I will try to answer the questions people
> had anyway in case people are interested.
> 
> Regarding domestic bindings, the C front end would remain. Although
> the API would have to change if we wanted to return an error code. but
> this is about plplot internal code. What is the maximum number of
> levels back which we might need to pass an error code? A dozen or more
> probably. The idea is to avoid all that internal book keeping.
> Especially if 10 layers down a memory allocation fails. Every layer up
> from this needs to have code to deal with checking error codes for
> every function it calls and then free resources and propagate that
> error code. With the C++ model a throw does all that automatically.
> 

I was looking at consolidating all the error/warning messages routines into one or two functions and create a new file in the src directory. One of the motivations was to cleanup some of the mallocs and static char array allocations that are scattered throughout the code. I have some code that I have been using for awhile that I was going to offer. The other advantage is that it makes is easier to implement different translations. 

> Regarding efficiency. There would almost certainly be no change. The
> compiler would probably optimise away anything superfluous.
> 
> As far as I know C++ is ubiquitous. The earliest C++ compilers
> actually rewrote the C++ to C and passed it to a C compiler!
> 
> Compilation speed for C++ can be slower if there is a lot of use of
> Templates. Templates are functions or classes which can have a version
> for any variable type, so instead of writing
> int round( int var, int basis);
> float round( float var, float basis);
> double round( double var, doublebasis);
> ...
> 
> you have
> template<class T>
> T round( T var, T basis);
> 
> Then the user can call round with any type and it will work, providing
> the code is compilable when you replace T with your type or class. But
> there is a compiletime cost associated with the extra work required by
> the compiler to do this.
> 
> Regarding name mangling we can use extern C to give C name mangling to
> the API, then the library, both static and dynamic as I understand it,
> behaves just like a C library.
> 
> As far as using a C++ compiler is concerned I am afraid that is
> something I have never worried about as I only write C++ programs so I
> always link against C runtimes. But as Alan says we already use C++
> code in PLPlot so this should already be taken care of.
> 
> If we are not interested in moving to C++ then we still need a method
> to propagate errors up through the multiple layers of code in the
> PLPlot library and do so in a way which minimises the risk of memory
> or other resource leaks. Because I work in C++ I'm not necessarily the
> best person to know best practice for this. But here are some ideas. I
> would be very interested to hear comments and more suggestions.
> 
> 1) We make every internal function in PLPlot return an error code and
> check these codes religiously at every call. Even simple functions
> would probably have to do this because in the future simple functions
> may grow to more complex ones and changing a function that previously
> returned a meaningful value to one which returns an error code is
> likely to be error prone so best get them all out of the way.
> 
> 2) We include an error code in the PLStream struct. We then check this
> after every function call to check if it has changed. Again this just
> requires us to be religious about checking the current error code.
> 
> 3)I just found out about setjmp and longjmp. These are C macros. As
> far as I can tell setjmp saves the state of the program stack and
> creates a jump point. Calling longjump jumps back to the jump point
> and restores the state. However, any memory malloc'd in the meantime
> will leak, unless we have some way to free it later. This might be
> conceivable by having an array of pointers in the PLStream to all
> memory allocated (maybe create a function plmalloc and plfree to deal
> with this?) which we can deal with at the end. Does anyone have any
> experience with setjmp and longjmp or  any advice? I also don't know
> how it deals with re-entrancy or nesting of setjmp calls. Or how to
> deal with our C++ code calling our C code - does our C++ code only
> call the public API or does it have access to internal routines?
> 

I have used the setjmp/longjmp approach. You definitely want to minimize the mallocs and the "distance" you jump. I prefer to do big mallocs and then partition the chunk of memory as needed rather than calling malloc multiple times. That helps when unwinding to cleanup on an error condition. Wrapping malloc/free with a plmalloc/plfree approach can be useful if the intent is to help cleanup. I do not recommend trying to manage memory because it is hard job to do correctly. 

> 4) Any other suggestions?
> 
> All these methods require us to have some strategy for dealing with
> freeing memory although it is often trivial, in some cases this can be
> complex and a strong candidate for future bugs and memory leaks.
> 
> I'm really keen to hear people's thoughts on this. As I said I work in
> C++, so I don't know best practice in C for dealing with this, but we
> definitely need to make a call and have a definite strategy for this
> otherwise it will be a nightmare.
> 
> Phil
> 
> 
>> On 25 May 2015 at 21:06, Alan W. Irwin <ir...@be...> wrote:
>>> On 2015-05-25 17:29-0000 Arjen Markus wrote:
>>> 
>>> An issue related to the use of C++ that has not been raised yet, but
>> which surfaced recently in my comprehensive testing efforts is the
>> fact that linking a C++ program requires a C++-enabled linker. Thus
>> introducing C++ as the language in which PLplot is to be implemented
>> would complicate the use of static builds. That may not be the most
>> common option nowadays, but I think we need to take a conscious
>> decision: do we want to continue to support static builds or not? One
>> pro for static builds is that they make deployment, especially of
>> binary-only distributions much easier (and safer).
>> 
>> Hi Arjen:
>> 
>> Yes, I think we should keep supporting static builds which work
>> virtually perfectly now with our CMake-based build systems for the
>> build of PLplot from source and the build of the installed examples.
>> 
>> I assume what you mean by a C++-enabled linker is that extra libraries
>> have to be linked in for that case.  Our CMake build handles this
>> situation with ease both for the core build and installed examples
>> build.  So static linking is already completely supported in that case.
>> 
>> Of course, there is currently a limitation on our traditional
>> (Makefile + pkg-config) build for e.g., Fortran examples where
>> pkg-config does not automatically know the name/location of the
>> special C++ library that needs to be linked in for a given C++
>> compiler so the user would have to add that link himself to the
>> pkg-config results to successfully build the Fortran examples using
>> our traditional build system for the installed examples.
>> 
>> Currently this problem occurs if C++ code is included in libplplot
>> from our C++ device drivers, psttf, qt, and wxwidgets. But that is a
>> very common case (or should be) to have those device drivers enabled
>> so if we adopt C++ for the core library this limitation in our
>> traditional build will essentially just stay the same in most cases.
>> So I don't see this limitation of our traditional build system for the
>> installed examples as a big concern with switching our core library to
>> C++ in all cases.
>> 
>> Don't get me wrong, I would like this limitation to be resolved so
>> that our traditional build of the installed examples works as well as
>> the CMake build of those.  When discussing this with Andrew I
>> mentioned one possibility for implementing a fix for this issue, but
>> that is a lot of work which I am going to leave to others if they want
>> to make our Makefile+pkg-config approach as high quality as the
>> CMake-based one for building our installed examples.
>> 
>> 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
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] PLplot and C++

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

On 2015-05-25 13:06-0700 Alan W. Irwin wrote:

> Don't get me wrong, I would like this limitation to be resolved so
> that our traditional build of the installed examples works as well as
> the CMake build of those.  When discussing this with Andrew I
> mentioned one possibility for implementing a fix for this issue, but
> that is a lot of work which I am going to leave to others if they want
> to make our Makefile+pkg-config approach as high quality as the
> CMake-based one for building our installed examples.

There was a question about CMake and C++ this morning on the CMake list
where the reply contained this very useful bit of information:

"Look at CMakeFiles/${CMAKE_VERSION}/CMake*Compiler.cmake for details
of the compiler detected for each language.  Look for these variables:

  CMAKE_C_COMPILER
  CMAKE_C_IMPLICIT_LINK_LIBRARIES

  CMAKE_CXX_COMPILER
  CMAKE_CXX_IMPLICIT_LINK_LIBRARIES

"

So I did that for my latest build and found

software@raven> grep CMAKE_CXX_IMPLICIT_LINK_ CMakeFiles/3.0.2/CMakeCXXCompiler.cmake
set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "stdc++;m;c")
set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.7;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib")
set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")

So it appears to me that CMake has collected all of its knowledge
about the special libraries associated with any given C++ compiler in
this file.  Therefore, I plan to remove the current restriction on our
traditional build system for the installed examples by finding and
parsing this file for the values of CMAKE_CXX_IMPLICIT_LINK_LIBRARIES
and CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES; doing the appropriate
find_library commands to find exact special library locations, and
transforming this information into the -L and -l format required by
our configured pkg-config files.

Anyhow, once I have implemented this change there should be no further
traditional build system concern over linking issues with C++ either
for PLplot 5 or PLplot 6 unless the user is using some exotic C++
compiler that CMake has never heard of.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,



That sounds interesting indeed - as for exotic C++ compilers: I guess Cmake would have difficulty finding them in the first place. Main thing is that knowledge of all these libraries is easily accessible.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> There was a question about CMake and C++ this morning on the CMake list where
> the reply contained this very useful bit of information:
>

...
> So it appears to me that CMake has collected all of its knowledge about the special
> libraries associated with any given C++ compiler in this file

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] PLPlot 6 and C++

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

Hi Jim
Sorry, when I suggested a plmalloc and plfree I meant for these to
call free and malloc, plus do some extra bookkeeping for us to keep
track of our garbage collection needs, not as functions to interact
directly with the OS to bypass free and malloc

I think the following could be a useful model. If in plstream we have
variables something like
void **tempMem;
PLINT nTempMemArrays;
void **nextTempMemArray;

then a function plmalloc, which would malloc the needed memory, assign
it to nextTempMemArray, increment nextTempMemArray ready for the next
allocation and if needed increase the size of tempMem.
plfree would free the memory, search tempMem and set that element to
NULL, possibly rolling back nextTempMemArray to the point after the
last non-null pointer.
Then when we return from an API function we can call a function
something like plCleanMem which would free all memory from the tempMem
array.
In fact there would really be little need to call plfree unless the
memory used is large and we are worried about resources - before
returning to the calling program everything would be cleaned up
anyway.

Even without a setjmp/longjmp error handling mechanism, this seems
like a useful way for us to manage memory in plplot and avoid memory
leaks. I have heard about using memory pools before, but what happens
when the pool runs out, does the whole pool need reallocating? I think
the method above does what we need with minimal fuss, but am very open
to other suggestions - this is all new to me in a C context. Comments
anyone?

The only issue I can think of is rentrancy. If we call an API function
internally then it will free all the memory before returning, some of
which is likely to still be in use. So something like this would need
us to separate out the public API from internal functions which do the
same job - the public API would just call the internal function. Does
anyone know if this would affect the other language bindings?

With this in place, using setjmp/longjmp seems to give us a trivial
way to remove all our plexit calls.

Phil

On 26 May 2015 at 21:17, Jim Dishaw <ji...@di...> wrote:
>
>
>
>
>> On May 26, 2015, at 3:53 PM, Phil Rosenberg <p.d...@gm...> wrote:
>>
>> Okay, well it was an option I thought I would put out there as I think
>> it was worth considering. I will try to answer the questions people
>> had anyway in case people are interested.
>>
>> Regarding domestic bindings, the C front end would remain. Although
>> the API would have to change if we wanted to return an error code. but
>> this is about plplot internal code. What is the maximum number of
>> levels back which we might need to pass an error code? A dozen or more
>> probably. The idea is to avoid all that internal book keeping.
>> Especially if 10 layers down a memory allocation fails. Every layer up
>> from this needs to have code to deal with checking error codes for
>> every function it calls and then free resources and propagate that
>> error code. With the C++ model a throw does all that automatically.
>>
>
> I was looking at consolidating all the error/warning messages routines into one or two functions and create a new file in the src directory. One of the motivations was to cleanup some of the mallocs and static char array allocations that are scattered throughout the code. I have some code that I have been using for awhile that I was going to offer. The other advantage is that it makes is easier to implement different translations.
>
>> Regarding efficiency. There would almost certainly be no change. The
>> compiler would probably optimise away anything superfluous.
>>
>> As far as I know C++ is ubiquitous. The earliest C++ compilers
>> actually rewrote the C++ to C and passed it to a C compiler!
>>
>> Compilation speed for C++ can be slower if there is a lot of use of
>> Templates. Templates are functions or classes which can have a version
>> for any variable type, so instead of writing
>> int round( int var, int basis);
>> float round( float var, float basis);
>> double round( double var, doublebasis);
>> ...
>>
>> you have
>> template<class T>
>> T round( T var, T basis);
>>
>> Then the user can call round with any type and it will work, providing
>> the code is compilable when you replace T with your type or class. But
>> there is a compiletime cost associated with the extra work required by
>> the compiler to do this.
>>
>> Regarding name mangling we can use extern C to give C name mangling to
>> the API, then the library, both static and dynamic as I understand it,
>> behaves just like a C library.
>>
>> As far as using a C++ compiler is concerned I am afraid that is
>> something I have never worried about as I only write C++ programs so I
>> always link against C runtimes. But as Alan says we already use C++
>> code in PLPlot so this should already be taken care of.
>>
>> If we are not interested in moving to C++ then we still need a method
>> to propagate errors up through the multiple layers of code in the
>> PLPlot library and do so in a way which minimises the risk of memory
>> or other resource leaks. Because I work in C++ I'm not necessarily the
>> best person to know best practice for this. But here are some ideas. I
>> would be very interested to hear comments and more suggestions.
>>
>> 1) We make every internal function in PLPlot return an error code and
>> check these codes religiously at every call. Even simple functions
>> would probably have to do this because in the future simple functions
>> may grow to more complex ones and changing a function that previously
>> returned a meaningful value to one which returns an error code is
>> likely to be error prone so best get them all out of the way.
>>
>> 2) We include an error code in the PLStream struct. We then check this
>> after every function call to check if it has changed. Again this just
>> requires us to be religious about checking the current error code.
>>
>> 3)I just found out about setjmp and longjmp. These are C macros. As
>> far as I can tell setjmp saves the state of the program stack and
>> creates a jump point. Calling longjump jumps back to the jump point
>> and restores the state. However, any memory malloc'd in the meantime
>> will leak, unless we have some way to free it later. This might be
>> conceivable by having an array of pointers in the PLStream to all
>> memory allocated (maybe create a function plmalloc and plfree to deal
>> with this?) which we can deal with at the end. Does anyone have any
>> experience with setjmp and longjmp or  any advice? I also don't know
>> how it deals with re-entrancy or nesting of setjmp calls. Or how to
>> deal with our C++ code calling our C code - does our C++ code only
>> call the public API or does it have access to internal routines?
>>
>
> I have used the setjmp/longjmp approach. You definitely want to minimize the mallocs and the "distance" you jump. I prefer to do big mallocs and then partition the chunk of memory as needed rather than calling malloc multiple times. That helps when unwinding to cleanup on an error condition. Wrapping malloc/free with a plmalloc/plfree approach can be useful if the intent is to help cleanup. I do not recommend trying to manage memory because it is hard job to do correctly.
>
>> 4) Any other suggestions?
>>
>> All these methods require us to have some strategy for dealing with
>> freeing memory although it is often trivial, in some cases this can be
>> complex and a strong candidate for future bugs and memory leaks.
>>
>> I'm really keen to hear people's thoughts on this. As I said I work in
>> C++, so I don't know best practice in C for dealing with this, but we
>> definitely need to make a call and have a definite strategy for this
>> otherwise it will be a nightmare.
>>
>> Phil
>>
>>
>>> On 25 May 2015 at 21:06, Alan W. Irwin <ir...@be...> wrote:
>>>> On 2015-05-25 17:29-0000 Arjen Markus wrote:
>>>>
>>>> An issue related to the use of C++ that has not been raised yet, but
>>> which surfaced recently in my comprehensive testing efforts is the
>>> fact that linking a C++ program requires a C++-enabled linker. Thus
>>> introducing C++ as the language in which PLplot is to be implemented
>>> would complicate the use of static builds. That may not be the most
>>> common option nowadays, but I think we need to take a conscious
>>> decision: do we want to continue to support static builds or not? One
>>> pro for static builds is that they make deployment, especially of
>>> binary-only distributions much easier (and safer).
>>>
>>> Hi Arjen:
>>>
>>> Yes, I think we should keep supporting static builds which work
>>> virtually perfectly now with our CMake-based build systems for the
>>> build of PLplot from source and the build of the installed examples.
>>>
>>> I assume what you mean by a C++-enabled linker is that extra libraries
>>> have to be linked in for that case.  Our CMake build handles this
>>> situation with ease both for the core build and installed examples
>>> build.  So static linking is already completely supported in that case.
>>>
>>> Of course, there is currently a limitation on our traditional
>>> (Makefile + pkg-config) build for e.g., Fortran examples where
>>> pkg-config does not automatically know the name/location of the
>>> special C++ library that needs to be linked in for a given C++
>>> compiler so the user would have to add that link himself to the
>>> pkg-config results to successfully build the Fortran examples using
>>> our traditional build system for the installed examples.
>>>
>>> Currently this problem occurs if C++ code is included in libplplot
>>> from our C++ device drivers, psttf, qt, and wxwidgets. But that is a
>>> very common case (or should be) to have those device drivers enabled
>>> so if we adopt C++ for the core library this limitation in our
>>> traditional build will essentially just stay the same in most cases.
>>> So I don't see this limitation of our traditional build system for the
>>> installed examples as a big concern with switching our core library to
>>> C++ in all cases.
>>>
>>> Don't get me wrong, I would like this limitation to be resolved so
>>> that our traditional build of the installed examples works as well as
>>> the CMake build of those.  When discussing this with Andrew I
>>> mentioned one possibility for implementing a fix for this issue, but
>>> that is a lot of work which I am going to leave to others if they want
>>> to make our Makefile+pkg-config approach as high quality as the
>>> CMake-based one for building our installed examples.
>>>
>>> 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
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLPlot 6 and C++

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

> On May 28, 2015, at 5:50 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Hi Jim
> Sorry, when I suggested a plmalloc and plfree I meant for these to
> call free and malloc, plus do some extra bookkeeping for us to keep
> track of our garbage collection needs, not as functions to interact
> directly with the OS to bypass free and malloc
> 
> I think the following could be a useful model. If in plstream we have
> variables something like
> void **tempMem;
> PLINT nTempMemArrays;
> void **nextTempMemArray;
> 
> then a function plmalloc, which would malloc the needed memory, assign
> it to nextTempMemArray, increment nextTempMemArray ready for the next
> allocation and if needed increase the size of tempMem.
> plfree would free the memory, search tempMem and set that element to
> NULL, possibly rolling back nextTempMemArray to the point after the
> last non-null pointer.
> Then when we return from an API function we can call a function
> something like plCleanMem which would free all memory from the tempMem
> array.
> In fact there would really be little need to call plfree unless the
> memory used is large and we are worried about resources - before
> returning to the calling program everything would be cleaned up
> anyway.
> 
> Even without a setjmp/longjmp error handling mechanism, this seems
> like a useful way for us to manage memory in plplot and avoid memory
> leaks. I have heard about using memory pools before, but what happens
> when the pool runs out, does the whole pool need reallocating? I think
> the method above does what we need with minimal fuss, but am very open
> to other suggestions - this is all new to me in a C context. Comments
> anyone?
> 
> The only issue I can think of is rentrancy. If we call an API function
> internally then it will free all the memory before returning, some of
> which is likely to still be in use. So something like this would need
> us to separate out the public API from internal functions which do the
> same job - the public API would just call the internal function. Does
> anyone know if this would affect the other language bindings?
> 

I would caution against this approach on rolling our own garbage collection.  It really is a hard problem to do correctly (let alone in a thread safe fashion).  We are far better off calling free() when the memory is not utilized. 

I would advocate using the atexit() function, which appears to be available on many (if not all) the platforms we support.

> With this in place, using setjmp/longjmp seems to give us a trivial
> way to remove all our plexit calls.
> 


> Phil
> 
> On 26 May 2015 at 21:17, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>> 
>> 
>>> On May 26, 2015, at 3:53 PM, Phil Rosenberg <p.d...@gm...> wrote:
>>> 
>>> Okay, well it was an option I thought I would put out there as I think
>>> it was worth considering. I will try to answer the questions people
>>> had anyway in case people are interested.
>>> 
>>> Regarding domestic bindings, the C front end would remain. Although
>>> the API would have to change if we wanted to return an error code. but
>>> this is about plplot internal code. What is the maximum number of
>>> levels back which we might need to pass an error code? A dozen or more
>>> probably. The idea is to avoid all that internal book keeping.
>>> Especially if 10 layers down a memory allocation fails. Every layer up
>>> from this needs to have code to deal with checking error codes for
>>> every function it calls and then free resources and propagate that
>>> error code. With the C++ model a throw does all that automatically.
>>> 
>> 
>> I was looking at consolidating all the error/warning messages routines into one or two functions and create a new file in the src directory. One of the motivations was to cleanup some of the mallocs and static char array allocations that are scattered throughout the code. I have some code that I have been using for awhile that I was going to offer. The other advantage is that it makes is easier to implement different translations.
>> 
>>> Regarding efficiency. There would almost certainly be no change. The
>>> compiler would probably optimise away anything superfluous.
>>> 
>>> As far as I know C++ is ubiquitous. The earliest C++ compilers
>>> actually rewrote the C++ to C and passed it to a C compiler!
>>> 
>>> Compilation speed for C++ can be slower if there is a lot of use of
>>> Templates. Templates are functions or classes which can have a version
>>> for any variable type, so instead of writing
>>> int round( int var, int basis);
>>> float round( float var, float basis);
>>> double round( double var, doublebasis);
>>> ...
>>> 
>>> you have
>>> template<class T>
>>> T round( T var, T basis);
>>> 
>>> Then the user can call round with any type and it will work, providing
>>> the code is compilable when you replace T with your type or class. But
>>> there is a compiletime cost associated with the extra work required by
>>> the compiler to do this.
>>> 
>>> Regarding name mangling we can use extern C to give C name mangling to
>>> the API, then the library, both static and dynamic as I understand it,
>>> behaves just like a C library.
>>> 
>>> As far as using a C++ compiler is concerned I am afraid that is
>>> something I have never worried about as I only write C++ programs so I
>>> always link against C runtimes. But as Alan says we already use C++
>>> code in PLPlot so this should already be taken care of.
>>> 
>>> If we are not interested in moving to C++ then we still need a method
>>> to propagate errors up through the multiple layers of code in the
>>> PLPlot library and do so in a way which minimises the risk of memory
>>> or other resource leaks. Because I work in C++ I'm not necessarily the
>>> best person to know best practice for this. But here are some ideas. I
>>> would be very interested to hear comments and more suggestions.
>>> 
>>> 1) We make every internal function in PLPlot return an error code and
>>> check these codes religiously at every call. Even simple functions
>>> would probably have to do this because in the future simple functions
>>> may grow to more complex ones and changing a function that previously
>>> returned a meaningful value to one which returns an error code is
>>> likely to be error prone so best get them all out of the way.
>>> 
>>> 2) We include an error code in the PLStream struct. We then check this
>>> after every function call to check if it has changed. Again this just
>>> requires us to be religious about checking the current error code.
>>> 
>>> 3)I just found out about setjmp and longjmp. These are C macros. As
>>> far as I can tell setjmp saves the state of the program stack and
>>> creates a jump point. Calling longjump jumps back to the jump point
>>> and restores the state. However, any memory malloc'd in the meantime
>>> will leak, unless we have some way to free it later. This might be
>>> conceivable by having an array of pointers in the PLStream to all
>>> memory allocated (maybe create a function plmalloc and plfree to deal
>>> with this?) which we can deal with at the end. Does anyone have any
>>> experience with setjmp and longjmp or  any advice? I also don't know
>>> how it deals with re-entrancy or nesting of setjmp calls. Or how to
>>> deal with our C++ code calling our C code - does our C++ code only
>>> call the public API or does it have access to internal routines?
>>> 
>> 
>> I have used the setjmp/longjmp approach. You definitely want to minimize the mallocs and the "distance" you jump. I prefer to do big mallocs and then partition the chunk of memory as needed rather than calling malloc multiple times. That helps when unwinding to cleanup on an error condition. Wrapping malloc/free with a plmalloc/plfree approach can be useful if the intent is to help cleanup. I do not recommend trying to manage memory because it is hard job to do correctly.
>> 
>>> 4) Any other suggestions?
>>> 
>>> All these methods require us to have some strategy for dealing with
>>> freeing memory although it is often trivial, in some cases this can be
>>> complex and a strong candidate for future bugs and memory leaks.
>>> 
>>> I'm really keen to hear people's thoughts on this. As I said I work in
>>> C++, so I don't know best practice in C for dealing with this, but we
>>> definitely need to make a call and have a definite strategy for this
>>> otherwise it will be a nightmare.
>>> 
>>> Phil
>>> 
>>> 
>>>> On 25 May 2015 at 21:06, Alan W. Irwin <ir...@be...> wrote:
>>>>> On 2015-05-25 17:29-0000 Arjen Markus wrote:
>>>>> 
>>>>> An issue related to the use of C++ that has not been raised yet, but
>>>> which surfaced recently in my comprehensive testing efforts is the
>>>> fact that linking a C++ program requires a C++-enabled linker. Thus
>>>> introducing C++ as the language in which PLplot is to be implemented
>>>> would complicate the use of static builds. That may not be the most
>>>> common option nowadays, but I think we need to take a conscious
>>>> decision: do we want to continue to support static builds or not? One
>>>> pro for static builds is that they make deployment, especially of
>>>> binary-only distributions much easier (and safer).
>>>> 
>>>> Hi Arjen:
>>>> 
>>>> Yes, I think we should keep supporting static builds which work
>>>> virtually perfectly now with our CMake-based build systems for the
>>>> build of PLplot from source and the build of the installed examples.
>>>> 
>>>> I assume what you mean by a C++-enabled linker is that extra libraries
>>>> have to be linked in for that case.  Our CMake build handles this
>>>> situation with ease both for the core build and installed examples
>>>> build.  So static linking is already completely supported in that case.
>>>> 
>>>> Of course, there is currently a limitation on our traditional
>>>> (Makefile + pkg-config) build for e.g., Fortran examples where
>>>> pkg-config does not automatically know the name/location of the
>>>> special C++ library that needs to be linked in for a given C++
>>>> compiler so the user would have to add that link himself to the
>>>> pkg-config results to successfully build the Fortran examples using
>>>> our traditional build system for the installed examples.
>>>> 
>>>> Currently this problem occurs if C++ code is included in libplplot
>>>> from our C++ device drivers, psttf, qt, and wxwidgets. But that is a
>>>> very common case (or should be) to have those device drivers enabled
>>>> so if we adopt C++ for the core library this limitation in our
>>>> traditional build will essentially just stay the same in most cases.
>>>> So I don't see this limitation of our traditional build system for the
>>>> installed examples as a big concern with switching our core library to
>>>> C++ in all cases.
>>>> 
>>>> Don't get me wrong, I would like this limitation to be resolved so
>>>> that our traditional build of the installed examples works as well as
>>>> the CMake build of those.  When discussing this with Andrew I
>>>> mentioned one possibility for implementing a fix for this issue, but
>>>> that is a lot of work which I am going to leave to others if they want
>>>> to make our Makefile+pkg-config approach as high quality as the
>>>> CMake-based one for building our installed examples.
>>>> 
>>>> 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
>>>> Plp...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot and C++

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

On 2015-05-27 14:50-0700 Alan W. Irwin wrote:

> [.... F]or my latest build [on Linux I found]
>
> software@raven> grep CMAKE_CXX_IMPLICIT_LINK_ CMakeFiles/3.0.2/CMakeCXXCompiler.cmake
> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "stdc++;m;c")
> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.7;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib")
> set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")

To Arjen and Phil:

Today I plan to tackle the job of parsing this information so that our
traditional build system for the static case will have the same C++
compiler library information as our CMake-based build, and I
will ask you both to test the result on Cygwin and MSVC.

Meanwhile, would both of you guys please let me know the exact results
for CMAKE_CXX_IMPLICIT_LINK_LIBRARIES and
CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES from
CMakeFiles/<VERSION>/CMakeCXXCompiler.cmake in your build trees for
both the Cygwin and MSVC platforms?

I would appreciate you sharing that knowledge (especially if you don't
have to do anything special other than to look it up in an old build
directory) since it should help me to figure out in advance if I have
to do anything special to deal with drive letters, etc., for the
various Cygwin and MSVC cases.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Meanwhile, would both of you guys please let me know the exact results for
> CMAKE_CXX_IMPLICIT_LINK_LIBRARIES and
> CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES from
> CMakeFiles/<VERSION>/CMakeCXXCompiler.cmake in your build trees for both
> the Cygwin and MSVC platforms?
>
For the Cygwin 64bits build I see the following (CMake 3.1.2):

set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "stdc++;cygwin;advapi32;shell32;user32;kernel32")

set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-pc-cygwin/4.9.2;/usr/x86_64-pc-cygwin/lib;/usr/lib;/lib")

set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")



For MinGW/MSYS I get this (CMake 3.2.1, no typo):

set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "stdc++;mingw32;moldname;mingwex;msvcrt;advapi32;shell32;user32;kernel32;mingw32;moldname;mingwex;msvcrt")

set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "d:/mingwnew/lib/gcc/mingw32/4.8.1;d:/mingwnew/lib/gcc;d:/mingwnew/mingw32/lib;d:/mingwnew/lib")



And for MSVC (32 bits, CMake 2.8.12.2):

set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "")

set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "")

I have no idea why these are empty - maybe the linker itself takes care of all of the required libraries?



Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] PLplot and C++

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

 I have the same empty variable for my visual studio 64 bit plplot build.

Looking at https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

" If you include one of the C++ Standard Library Header Files in your
code, a Standard C++ Library will be linked in automatically by Visual
C++ at compile time."

So as Arjen suggested. Visual Studio is clever enough to detect
whether or not to link in the C++ runtime library.

Note however, if you have not selected the static runtime option in
cmake then to deploy your plplot application you must also install the
(freely available) version of the c/c++ runtime for the visual studio
version you compiled on. Not that this makes any difference for
building and running on the same machine.

On 1 June 2015 at 08:09, Arjen Markus <Arj...@de...> wrote:
> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Meanwhile, would both of you guys please let me know the exact results for
>> CMAKE_CXX_IMPLICIT_LINK_LIBRARIES and
>> CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES from
>> CMakeFiles/<VERSION>/CMakeCXXCompiler.cmake in your build trees for both
>> the Cygwin and MSVC platforms?
>>
> For the Cygwin 64bits build I see the following (CMake 3.1.2):
>
> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES
> "stdc++;cygwin;advapi32;shell32;user32;kernel32")
>
> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
> "/usr/lib/gcc/x86_64-pc-cygwin/4.9.2;/usr/x86_64-pc-cygwin/lib;/usr/lib;/lib")
>
> set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")
>
>
>
> For MinGW/MSYS I get this (CMake 3.2.1, no typo):
>
> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES
> "stdc++;mingw32;moldname;mingwex;msvcrt;advapi32;shell32;user32;kernel32;mingw32;moldname;mingwex;msvcrt")
>
> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
> "d:/mingwnew/lib/gcc/mingw32/4.8.1;d:/mingwnew/lib/gcc;d:/mingwnew/mingw32/lib;d:/mingwnew/lib")
>
>
>
> And for MSVC (32 bits, CMake 2.8.12.2):
>
> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "")
>
> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "")
>
> I have no idea why these are empty – maybe the linker itself takes care of
> all of the required libraries?
>
>
>
> Regards,
>
> Arjen
>
>
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.

Re: [Plplot-devel] PLplot and C++

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

To Phil and Arjen:

Thanks to both of you for the useful information below which should
help me to sort out the C++ linking issue for the traditional build.

Alan


On 2015-06-01 10:59+0100 Phil Rosenberg wrote:

> I have the same empty variable for my visual studio 64 bit plplot build.
>
> Looking at https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
>
> " If you include one of the C++ Standard Library Header Files in your
> code, a Standard C++ Library will be linked in automatically by Visual
> C++ at compile time."
>
> So as Arjen suggested. Visual Studio is clever enough to detect
> whether or not to link in the C++ runtime library.
>
> Note however, if you have not selected the static runtime option in
> cmake then to deploy your plplot application you must also install the
> (freely available) version of the c/c++ runtime for the visual studio
> version you compiled on. Not that this makes any difference for
> building and running on the same machine.
>
> On 1 June 2015 at 08:09, Arjen Markus <Arj...@de...> wrote:
>> Hi Alan,
>>
>>
>>
>>> -----Original Message-----
>>> From: Alan W. Irwin [mailto:ir...@be...]
>>> Meanwhile, would both of you guys please let me know the exact results for
>>> CMAKE_CXX_IMPLICIT_LINK_LIBRARIES and
>>> CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES from
>>> CMakeFiles/<VERSION>/CMakeCXXCompiler.cmake in your build trees for both
>>> the Cygwin and MSVC platforms?
>>>
>> For the Cygwin 64bits build I see the following (CMake 3.1.2):
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES
>> "stdc++;cygwin;advapi32;shell32;user32;kernel32")
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
>> "/usr/lib/gcc/x86_64-pc-cygwin/4.9.2;/usr/x86_64-pc-cygwin/lib;/usr/lib;/lib")
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")
>>
>>
>>
>> For MinGW/MSYS I get this (CMake 3.2.1, no typo):
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES
>> "stdc++;mingw32;moldname;mingwex;msvcrt;advapi32;shell32;user32;kernel32;mingw32;moldname;mingwex;msvcrt")
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
>> "d:/mingwnew/lib/gcc/mingw32/4.8.1;d:/mingwnew/lib/gcc;d:/mingwnew/mingw32/lib;d:/mingwnew/lib")
>>
>>
>>
>> And for MSVC (32 bits, CMake 2.8.12.2):
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "")
>>
>> set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "")
>>
>> I have no idea why these are empty – maybe the linker itself takes care of
>> all of the required libraries?

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot and C++

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

On 2015-06-01 10:48-0700 Alan W. Irwin wrote:

> To Phil and Arjen:
>
> Thanks to both of you for the useful information below which should
> help me to sort out the C++ linking issue for the traditional build.

The solution I came up with (commit ID e23628e) turned out to be quite
elegant if I do say so myself.  The previous poor workaround (drop
f95, Ada, D, etc., for traditional examples build in the static case)
are now gone, and this new solution passed a test that failed before
that previous poor workaround was implemented.

Of course, all my testing of this new solution is on Linux so I
specifically ask for testing of the traditional build of the
installed examples in the static case for all Windows platforms.

The easiest way to do that, of course, is to run the
comprehensive_test.sh script.

@Arjen: you have kindly been running that script a lot for me recently
with excellent success on Cygwin, but there is a small backlog now
with a number of things to check (my prior build system changes after
your last run of the script, checking the case where you have
installed the addtional software packages I suggested for Cygwin, and
now this change).  I suggest you try doing just one comprehensive test
of all changes in the backlog, but if you run into any trouble with
the traditional build you may want to back away from the current
commit and test instead the rest of the backlog for the parent of
e23628e = e23628e^).

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> The easiest way to do that, of course, is to run the comprehensive_test.sh script.
>
> @Arjen: you have kindly been running that script a lot for me recently with excellent
> success on Cygwin, but there is a small backlog now with a number of things to
> check (my prior build system changes after your last run of the script, checking the
> case where you have installed the addtional software packages I suggested for
> Cygwin, and now this change).  I suggest you try doing just one comprehensive test
> of all changes in the backlog, but if you run into any trouble with the traditional build
> you may want to back away from the current commit and test instead the rest of the
> backlog for the parent of e23628e = e23628e^).
>
I have not had an opportunity yet to update my Cygwin distribution with all the extras, but that should not be a big problem. Then running comprehensive_test.sh ought to reveal whether things are working out vis-à-vis the C++ libraries. I think I will be able to do this today.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,



Please find the report of the comprehensive test in the attached tarball.



Notes regarding the installation of the various Cygwin packages:

-        There are several HDF5 packages and what you really need is the "libdh5-devel" one (turned out to be version 1.8.15-1)

-        I had two versions of Ada installed. I removed the wrong one, but that has not resolved the issue. Cmake still can't find the gnat library, while that package is installed. The location for the library libgnat.a seems to be: C:\cygwin64\lib\gcc\x86_64-pc-cygwin\4.9.2\adalib\

-        Allowing Octave gave Cmake errors about two versus four arguments. I turned that off.



I saw that the Tcl examples cannot find the plplot.tcl file for some reason. I will check where that is coming from. Other than the above I saw no obvious problems - that is, the traditional build now does work.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> @Arjen: you have kindly been running that script a lot for me recently with excellent
> success on Cygwin, but there is a small backlog now with a number of things to
> check (my prior build system changes after your last run of the script, checking the
> case where you have installed the addtional software packages I suggested for
> Cygwin, and now this change).  I suggest you try doing just one comprehensive test
> of all changes in the backlog, but if you run into any trouble with the traditional build
> you may want to back away from the current commit and test instead the rest of the
> backlog for the parent of e23628e = e23628e^).
>


DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] PLplot and C++

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

Hi Arjen:

On 2015-06-03 11:13-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> Please find the report of the comprehensive test in the attached tarball.

Thanks for this test!

>
>
>
> Notes regarding the installation of the various Cygwin packages:
>
> -        There are several HDF5 packages and what you really need is the "libdh5-devel" one (turned out to be version 1.8.15-1)
>

> - I had two versions of Ada installed. I removed the wrong one, but
that has not resolved the issue. Cmake still can't find the gnat
library, while that package is installed. The location for the library
libgnat.a seems to be:
C:\cygwin64\lib\gcc\x86_64-pc-cygwin\4.9.2\adalib\

See below.

>
> -        Allowing Octave gave Cmake errors about two versus four arguments. I turned that off.
>
>
>

We should revisit this build-system issue later, but I agree it is a
good move to turn it off for now to more quickly reach the goal of
having all required Cygwin packages installed and environment
variables properly configured to test all PLplot components that are
possible on Cygwin.

> I saw that the Tcl examples cannot find the plplot.tcl file for some
reason. I will check where that is coming from. Other than the above I
saw no obvious problems - that is, the traditional build now does
work.

See below.

General remark:

It was really good to see that positive Fortran 95 result for the
traditional test_noninteractive results; it looks like my recent fix
for that issue is working at least on Linux and Cygwin.

Now on to my analysis of the remaining warning messages in, e.g., 
shared/output_tree/cmake.out concerning missing PLplot prerequisites
where I believe there is still something you can do to get access
to the prerequisite on Cygwin.

1. Tcl/Tk/Itcl/Itk

It appears from your remarks above you plan to look further into this.
When you do that I suggest you look carefully at every message in
shared/output_tree/cmake.out in the following range of messages:

-- Start determining consistent system data for Tcl and friends
[...]
-- Finished determining consistent system data for Tcl and friends

Those messages should be very clear concerning the issues.  For
example, the first messages in the series are

-- Found Tclsh: /bin/tclsh (found version "8.5") 
-- Found TCL: /usr/local/lib/libtcl86.a

which shows immediately an inconsistency issue not only in
8.5 version versus 8.6 but also in Cygwin version in /usr or /bin versus non-Cygwin version
in /usr/local.

It is important to solve that inconsistency before attempting to fix
any other issue (which may just disappear once that fundamental
inconsistency is resolved).  My guess as to what is happening here is
that Cygwin goes out of its way to find newer versions of all software
by default so by default it finds version 8.6 libraries in
/usr/local/lib rather than the system version 8.5 libraries in
/usr/lib. And contrary to what I said before, setting the environment
variables CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH will not help in
this case since CMake always searches for the higher versions of everything
everywhere (including CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH)
before it checks for lesser versions.

I believe your best choice is to move the non-Cygwin installation of
Tcl, etc., in /usr/local to some non-official location (e.g.,
/tcl/usr/local if everything in your current /usr/local tree is Tcl
related) which CMake does not know about.  That should allow
CMake to then find all the system versions of the Tcl-related
components.

Another alternative would be to set a large number of Tcl-related
variables to force CMake to find the Cygwin version of every
Tcl-related component. But I think this approach is more problematic
than simply renaming the non-Cygwin version of Tcl-related software to
a location other than /usr/local is the correct way to deal with
this issue.

2. Ada

You have made a lot of progress there.  For example, thanks to your
updated installation, the primitive test of the Ada compiler now works
for the first time, and the only issue left is

-- WARNING: gnat library not found. Disabling ada bindings

For this case, you should set the CMAKE_LIBRARY_PATH environment
variable from bash to help CMake find the gnat library.  And this
location most likely should be specified in Unix (forward slash) form
e.g.,

export CMAKE_LIBRARY_PATH=C:/cygwin64/lib/gcc/x86_64-pc-cygwin/4.9.2/adalib

or even

export CMAKE_LIBRARY_PATH=/C/cygwin64/lib/gcc/x86_64-pc-cygwin/4.9.2/adalib

3. pyqt4

You have made good progress here as well (thanks to your additional
installation) so it is like unpeeling an onion.  :-)

The messages are now reduced to

ImportError: No module named PyQt4
-- WARNING: could not find sip directory so setting ENABLE_pyqt4 to OFF.

These messages come from cmake/modules/qt.cmake, and to me the cure
would be simply to install the PyQt4 module.  I therefore used the
search term pyqt4 for the 64-bit version of the Cygwin package search
GUI, and my educated guess (from similar packaging results on Linux)
for your best choice among those possible packages is that
python-pyqt4-4.11.3-1 is the package you should install.

4. wxwidgets

-- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to OFF.
-- WARNING: PLD_wxwidgets is OFF so setting ENABLE_wxwidgets to OFF.

I have now (commit id 4e99275) made this message more verbose.  But I
think the problem here is you have not installed the required
wxwidgets package yet which according to my previous post
is libwx_gtk2u2.8-devel-2.8.12.1-5.

In sum, moving the /usr/local version of Tcl-related software to a
different location; setting CMAKE_LIBRARY_PATH so that gnatlib can be
found; and installing two further packages should (with luck) solve
the 4 issues above.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> 1. Tcl/Tk/Itcl/Itk
>
>
> I believe your best choice is to move the non-Cygwin installation of Tcl, etc., in
> /usr/local to some non-official location (e.g., /tcl/usr/local if everything in your current
> /usr/local tree is Tcl
> related) which CMake does not know about.  That should allow CMake to then find
> all the system versions of the Tcl-related components.
>
That is definitely the simplest step. I will try that.

>
> 2. Ada
>
> You have made a lot of progress there.  For example, thanks to your updated
> installation, the primitive test of the Ada compiler now works for the first time, and the
> only issue left is
>
> -- WARNING: gnat library not found. Disabling ada bindings
>
> For this case, you should set the CMAKE_LIBRARY_PATH environment variable
> from bash to help CMake find the gnat library.  And this location most likely should
> be specified in Unix (forward slash) form e.g.,
>
> export CMAKE_LIBRARY_PATH=C:/cygwin64/lib/gcc/x86_64-pc-
> cygwin/4.9.2/adalib
>
> or even
>
> export CMAKE_LIBRARY_PATH=/C/cygwin64/lib/gcc/x86_64-pc-
> cygwin/4.9.2/adalib
>

Just FYI, that should be /cygdrive/c/... - at least that is what I do for the PATH variable. The colon will definitely get in the way. Trying that should be easy enough :).

> 3. pyqt4
>
> You have made good progress here as well (thanks to your additional
> installation) so it is like unpeeling an onion.  :-)
>
> The messages are now reduced to
>
> ImportError: No module named PyQt4
> -- WARNING: could not find sip directory so setting ENABLE_pyqt4 to OFF.
>
> These messages come from cmake/modules/qt.cmake, and to me the cure would be
> simply to install the PyQt4 module.  I therefore used the search term pyqt4 for the
> 64-bit version of the Cygwin package search GUI, and my educated guess (from
> similar packaging results on Linux) for your best choice among those possible
> packages is that
> python-pyqt4-4.11.3-1 is the package you should install.
>

Ah, indeed, that was missing. I will install it and try again.

> 4. wxwidgets
>
> -- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to
> OFF.
> -- WARNING: PLD_wxwidgets is OFF so setting ENABLE_wxwidgets to OFF.
>
> I have now (commit id 4e99275) made this message more verbose.  But I think the
> problem here is you have not installed the required wxwidgets package yet which
> according to my previous post is libwx_gtk2u2.8-devel-2.8.12.1-5.

Something else must be wrong, as I definitely have that package installed already. I will try and dig a bit further.

>
> In sum, moving the /usr/local version of Tcl-related software to a different location;
> setting CMAKE_LIBRARY_PATH so that gnatlib can be found; and installing two
> further packages should (with luck) solve the 4 issues above.
>
Okay, the report from these new tests is coming up.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,



I followed your advice and the result is that now PyQt4 is accepted. However, the build fails on Ada:



cd /cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/dll && /usr/bin/cmake.exe -E copy_if_different libplplotada.dll libplplotada.dll.a

Error copying file (if different) from "libplplotada.dll" to "libplplotada.dll.a".

bindings/ada/CMakeFiles/plplotada.dir/build.make:142: recipe for target 'dll/cygplplotada-2.dll' failed

make[2]: *** [dll/cygplplotada-2.dll] Error 1



There is in fact no file libplotada.dll. No idea why not, but this is the first time I have ever seen much of Ada in the context of PLplot. For details: the attached tarball.

Somewhere along the line the Tcl installation as Cmake understands it has gone wrong - that may be something with my environment or my installation, though tchsh is running fine. Well, this requires some investigation from me (I had a small disaster the other day with the installation of some package destroying my PATH variable).

I will turn Ada off for now and try again.

Regards,

Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> In sum, moving the /usr/local version of Tcl-related software to a different location;
> setting CMAKE_LIBRARY_PATH so that gnatlib can be found; and installing two
> further packages should (with luck) solve the 4 issues above.
>


DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,



Here is the result (I had to switch off Ada and I need to reinstall Tcl as bits and pieces required for the development of extensions are missing), but PyQt4 worked now. The various components are getting fairly complete.



Regards,



Arjen



From: Arjen Markus [mailto:Arj...@de...]
Sent: Friday, June 05, 2015 11:21 AM
To: Alan W. Irwin
Cc: plp...@li...
Subject: Re: [Plplot-devel] PLplot and C++


Hi Alan,



I followed your advice and the result is that now PyQt4 is accepted. However, the build fails on Ada:



cd /cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/dll && /usr/bin/cmake.exe -E copy_if_different libplplotada.dll libplplotada.dll.a

Error copying file (if different) from "libplplotada.dll" to "libplplotada.dll.a".

bindings/ada/CMakeFiles/plplotada.dir/build.make:142: recipe for target 'dll/cygplplotada-2.dll' failed

make[2]: *** [dll/cygplplotada-2.dll] Error 1



There is in fact no file libplotada.dll. No idea why not, but this is the first time I have ever seen much of Ada in the context of PLplot. For details: the attached tarball.

Somewhere along the line the Tcl installation as Cmake understands it has gone wrong - that may be something with my environment or my installation, though tchsh is running fine. Well, this requires some investigation from me (I had a small disaster the other day with the installation of some package destroying my PATH variable).

I will turn Ada off for now and try again.

Regards,

Arjen


DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] PLplot and C++

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

On 2015-06-05 12:08-0000 Arjen Markus wrote:

> Here is the result (I had to switch off Ada and I need to reinstall
Tcl as bits and pieces required for the development of extensions are
missing), but PyQt4 worked now. The various components are getting
fairly complete.

Hi Arjen:

Thanks for the two comprehensive_test.tar.gz tarballs you sent me to
analyze. Let me designate the first one (the one that failed for Ada)
as I, and the one that succeeded as II.

===========================
Remarks concerning I alone:
===========================

1. Ada

I think I have now fixed that issue (commit id = 63bdf93) so please
try again.  There is a library naming inconsistency issue for Ada on
MinGW which I previously fixed in a way that screws up Ada on Cygwin.
>From your report there is no such naming convention inconsistency for
Ada on Cygwin so the fix was simply to exclude Cygwin from the
previous library naming convention inconsistency fix.

=================================
Remarks concerning both I and II:
=================================

1. Lua

Two days ago your Lua result in cmake.out was

-- LUA_VERSION = 5.1
-- LUA_INCLUDE_DIR = /usr/include
-- LUA_LIBRARIES = /usr/lib/liblua5.1.dll.a;/usr/lib/libm.a
-- Found Lua: /usr/bin/lua.exe

Now for both I and  II you have

-- LUA_VERSION = 5.2
-- LUA_INCLUDE_DIR = LUA_INCLUDE_DIR-NOTFOUND
-- LUA_LIBRARIES = 
-- Could NOT find Lua (missing:  LUA_LIBRARIES LUA_INCLUDE_DIR) 
-- WARNING: Lua library and/or header not found. Disabling Lua bindings

I suspect what is going on here is you removed lua-5.1 and tried to
replace it with lua-5.2.  But the package name scheme is a little
different for 5.2.  For example, I did a search for the regex "include.*/lua\.h"
and the result was

lua-devel-5.2.4-1 - lua-devel: Lua programming language interpreter (installed binaries and support files)
lua-5.1.5-1 - lua: Lua programming language interpreter (installed binaries and support files)

A search for "bin/luac" found (amongst other packages)

lua-5.1.5-1 - lua: Lua programming language interpreter (installed binaries and support files)
lua-5.2.4-1 - lua: Lua programming language interpreter (installed binaries and support files)

So for 5.2.4 you need to install two separate packages.  If the
dependencies of the packages are set correctly, then an attempt to
install lua-devel-5.2.4-1 should also automatically install
lua-5.2.4-1, but you should check that to reduce the minimal list of
PLplot prerequisite packages on Cygwin that I hope you are still
maintaining. (Once you are done with this process, that list should be
copied to our Wiki so others building PLplot on Cygwin can take
advantage of it.)

By the way, my package searches the other day did not find the 5.2
version of lua at all, and other evidence (i.e., the dates on the
files which are 2015-06-04) also indicate 5.2 is very new. So if you
requested packaging that version on the Cygwin mailing list, I have to
congratulate you for getting really fast action!

2. wxwidgets

The only information is
-- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to OFF.
-- WARNING: PLD_wxwidgets is OFF so setting ENABLE_wxwidgets to OFF.

In the master tip version there should have been more information.  So
please remember to update to master tip before your next try.

Also, you have remarked you have already installed
libwx_gtk2u2.8-devel-2.8.12.1-5.  And
<https://www.cygwin.com/cygwin-ug-net/setup-net.html#setup-packages>
says "setup.exe automatically selects dependencies".  However, there
could be a packaging error (we already encountered that for one
package whose name I have forgotten where the package dependencies
were not specified correctly).  So I searched using the term "libwx"
and came up with the following 2.8.12.1-5 results:

libwx_baseu2.8-devel-2.8.12.1-5 - libwx_baseu2.8-devel: Obsolete package (installed binaries and support files)
libwx_baseu2.8_0-2.8.12.1-5 - libwx_baseu2.8_0: wxWidgets C++ application framework (base unicode runtime) (installed binaries and support files)
libwx_gtk2u2.8-devel-2.8.12.1-5 - libwx_gtk2u2.8-devel: wxWidgets C++ application framework (development) (installed binaries and support files)
libwx_gtk2u2.8-doc-2.8.12.1-5 - libwx_gtk2u2.8-doc: wxWidgets C++ application framework (documentation) (installed binaries and support files)
libwx_gtk2u2.8_0-2.8.12.1-5 - libwx_gtk2u2.8_0: wxWidgets C++ application framework (GTK+ unicode runtime) (installed binaries and support files)

The first of those is described as obsolete so I assume you should not
have it installed, and you may not have the doc package installed
either, but installation of libwx_gtk2u2.8-devel-2.8.12.1-5 should
pull in the rest of those, and if not you are going to have to follow up
by installing the missing ones individually.

I also did the same search for libwx and came up with the following
3.0.2.0-1 results:

libwx_baseu3.0_0-3.0.2.0-1 - libwx_baseu3.0_0: wxWidgets C++ application framework (base unicode runtime) (installed binaries and support files)
libwx_gtk2u3.0-devel-3.0.2.0-1 - libwx_gtk2u3.0-devel: wxWidgets C++ application framework (development) (installed binaries and support files)
libwx_gtk2u3.0-doc-3.0.2.0-1 - libwx_gtk2u3.0-doc: wxWidgets C++ application framework (documentation) (installed binaries and support files)
libwx_gtk2u3.0_0-3.0.2.0-1 - libwx_gtk2u3.0_0: wxWidgets C++ application framework (GTK+ unicode runtime) (installed binaries and support files)

So if you cannot get 2.8.12.1-5 to work, I would remove all the above
2.8.12.1-5 packages and instead install libwx_gtk2u3.0-devel-3.0.2.0-1
(which should pull in the rest of the 3.0.2.0-1 packages other than
the doc one unless there is a dependency issue in the packaging).

3. Tcl and friends:

With the rename of your /usr/local version you are obviously not finding any Tcl/Tk/Itcl/Itk library now, but I
think that is simply a matter of installing the Cygwin packages I recommended
before, i.e., "the consistent set of Cygwin development packages, e.g.,
tcl-devel-8.5.18-1, tcl-tk-devel-8.5.18-1, tcl-itcl-3.4.1-1, and
tcl-itk-3.3-2 (found respectively by using the search strings
"tcl-devel", "tk-devel", itcl.h, and itk.h)."  You might have to dig
deeper if there is a dependency issue in the packaging of any of these
packages.


============================
Remarks concerning II alone:
============================

Ada.

The result for II was

-- WARNING: gnat library not found. Disabling ada bindings

which is a package install regression compared to I.  Thus, apparently
you dropped Ada by uninstalling a package.  But, of course, a much
superior way to drop Ada temporarily is simply to use the CMake option
-DENABLE_ada=OFF.  In any case, Ada should get further now (and might
even work) with my recent change (commit id = 63bdf93) so please
reinstall the package you dropped, do not specify -DENABLE_ada=OFF,
and try again.  The result should error out quickly if there are
additional Ada issues, but of course I would like to see the
report if that happens.

========
Summary:
========

The following components still need additional installation
changes by you in order to test them on Cygwin

ENABLE_ada:             OFF
ENABLE_lua:             OFF
ENABLE_tcl:             OFF
ENABLE_itcl:            OFF
ENABLE_tk:              OFF
ENABLE_itk:             OFF
ENABLE_wxwidgets:       OFF

Ada requires you to install a package that you just removed, and that
combined with my recent fix may be all that is required in that case.
Lua; Tcl/Tk, Itcl, Itk; and wxwidgets are likely simply a matter of
installing the packages noted above.  So I think you are getting
pretty close to an installed Cygwin platform that finally has all
the PLplot prerequisites that have been packaged under 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
__________________________

Re: [Plplot-devel] PLplot and C++

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

On 2015-06-05 12:59-0700 Alan W. Irwin wrote:

> ============================
> Remarks concerning II alone:
> ============================
>
> Ada.
>
> The result for II was
>
> -- WARNING: gnat library not found. Disabling ada bindings
>
> which is a package install regression compared to I.  Thus, apparently
> you dropped Ada by uninstalling a package.  But, of course, a much
> superior way to drop Ada temporarily is simply to use the CMake option
> -DENABLE_ada=OFF.  In any case, Ada should get further now (and might
> even work) with my recent change (commit id = 63bdf93) so please
> reinstall the package you dropped, do not specify -DENABLE_ada=OFF,
> and try again.  The result should error out quickly if there are
> additional Ada issues, but of course I would like to see the
> report if that happens.

Please ignore the remarks above about a dropped package.  Instead, I
now realize from looking at comprehensive_test_env.out results you simply dropped the environment variable
CMAKE_LIBRARY_PATH=/cygdrive/c/cygwin64/lib/gcc/x86_64-pc-cygwin/4.9.2/adalib.
And, of course, you should obviously reinstate that to test my fix.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot and C++

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

On 2015-06-05 12:59-0700 Alan W. Irwin wrote:

> ========
> Summary:
> ========
>
> The following components still need additional installation
> changes by you in order to test them on Cygwin
>
> ENABLE_ada:             OFF
> ENABLE_lua:             OFF
> ENABLE_tcl:             OFF
> ENABLE_itcl:            OFF
> ENABLE_tk:              OFF
> ENABLE_itk:             OFF
> ENABLE_wxwidgets:       OFF
>
> Ada requires you to install a package that you just removed, and that
> combined with my recent fix may be all that is required in that case.
> Lua; Tcl/Tk, Itcl, Itk; and wxwidgets are likely simply a matter of
> installing the packages noted above.  So I think you are getting
> pretty close to an installed Cygwin platform that finally has all
> the PLplot prerequisites that have been packaged under Cygwin.

Hi Arjen:

As I am sure you are aware, there are some recently introduced build
and run-time issues with wxwidgets.  So I would first concentrate on
getting perfect results for everything else above, and by that time
hopefully Phil will have figured out the fix that is required for
wxwidgets so we can set PLD_wxwidgets ON by default again, and you can
perfect the Cygwin test results for that final component in
the above list as well.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________